重點匯總-python-相關(guān)問題-網(wǎng)絡(luò)協(xié)議安全

寫個快速排序熱熱身，分析一下復(fù)雜度队丝，如果不使用額外的空間靡馁，應(yīng)該怎么寫？

def quick_sort(lists, left, right):
    # 快速排序
    if left >= right:
        return lists
    key = lists[left]
    low = left
    high = right
    while left < right:
        while left < right and lists[right] >= key:
            right -= 1
        lists[left] = lists[right]
        while left < right and lists[left] <= key:
            left += 1
        lists[right] = lists[left]
    lists[right] = key
    quick_sort(lists, low, left - 1)
    quick_sort(lists, left + 1, high)
    return lists      # 遞歸

參考算法圖解机久，使用遞歸臭墨，分而治之，重要點是找到基線條件和
遞歸條件膘盖，然后編寫快速排序胧弛。
八大排序算法的 Python 實現(xiàn)
python快速排序的兩種方法

說一下Flask中g(shù)是怎么實現(xiàn)的，原理是什么侠畔？

解釋一
這個問題我也遇到了结缚，樓上的各位大牛都說得很抽象，但應(yīng)該是正確理解這個問題的方向践图。我談?wù)勛约旱睦斫獍伞?. app context 和 request contextrequest context很好理解掺冠，看名字就知道是請求上下文。而 app context卻有點誤導(dǎo)性码党，它的字面意思是應(yīng)用上下文德崭，但它不是一直存在的，它只是request context中的一個對 app 的代理(人)揖盘，所謂local proxy眉厨。它的作用主要是幫助 request 獲取當(dāng)前的應(yīng)用，它是伴 request而生兽狭，隨request而滅的憾股。為什么需要這個代理？因為 flask 支持同時運行多個 app箕慧，所以需要為每個 request 綁定到具體的app context服球。舉例說request A 要改變 app A 的屬性，就要把request A綁定到app A的 context下颠焦。(這里我是猜的斩熊，因為我的水平還不涉及到多應(yīng)用……)

g 和 session從第一點可以明白app context 的生命周期其實也只有一個 request 那么長。既然這樣伐庭，那么像g這樣的屬于app context 的變量當(dāng)然也是只有一個request那么長的生命周期了粉渠。這就是為什么你的代碼在另一個 request 中讀取 g.count會報錯的原因。要達(dá)到你想要的效果圾另，你可以使用其session霸株。稍微讀一下源碼你就會發(fā)現(xiàn) session 也是一個 request context 的變量，但它把數(shù)據(jù)保存到了 cookie 中并發(fā)送到了客戶端集乔，客戶端再次請求的時候又帶上了cookie去件。

解釋二
Flask本身代碼很簡單，所以扰路，了解Thread local context是最大的難點把尤溜。 Local對象的作用就是，它是一個全局對象幼衰，你可以往里面保存東西靴跛，a線程保存到local對象的，只有a線程能取到渡嚣，b線程的只有b線程能取到梢睛，如果，a识椰，b保存了名字相同的東西绝葡，比如x，a取到的值是自己保存的腹鹉，不會和b保存的混淆藏畅，修改操作也一樣。 request，session愉阎，g都是用相同的原理實現(xiàn)的绞蹦，都是保存在local對象里的線程（包括greenlet協(xié)程）安全的變量。 flask自己實現(xiàn)了local對象而不是使用標(biāo)準(zhǔn)庫的threading.Local對象榜旦。仔細(xì)讀下werkzueg的local代碼和docstring

解釋三
《Flask 0.7中文手冊》P37頁提到幽七，g保存一個request的全局變量（譯者：g保存的是當(dāng)前請求的全局變量，不同的請求會有不同的全局變量溅呢，通過不同的thread id區(qū)別）
Flask 的 Context 機(jī)制
官方文檔使用Dash查找 g

說一下瀏覽器從輸入url到頁面渲染的過程澡屡，越詳細(xì)越好；

參考我之前文章

TCP/UDP協(xié)議區(qū)別 ?

TCP (Transmission Control Protocol 傳輸控制協(xié)議) 和 UDP(User Datagram Protocol用戶數(shù)據(jù)報協(xié)議) 協(xié)議屬于傳輸層協(xié)議(端口與端口之間)

面向連接的TCP
“面向連接”就是在正式通信前必須要與對方建立起連接咐旧。比如你給別人打電話驶鹉，必須等線路接通了、對方拿起話筒才能相互通話铣墨。
個TCP連接必須要經(jīng)過三次“對話”才能建立起來室埋，其中的過程非常復(fù)雜，我們這里只做簡單踏兜、形象的介紹：
主機(jī)A向主機(jī)B發(fā)出連接請求數(shù)據(jù)包：“我想給你發(fā)數(shù)據(jù)词顾，可以嗎？”碱妆，這是第一次對話肉盹；
主機(jī)B主機(jī)A發(fā)送同意連接和要求同步（同步就是兩臺主機(jī)一個在發(fā)送，一個在接收疹尾，協(xié)調(diào)工作）的數(shù)據(jù)包：“可以上忍，你什么時候發(fā)？”纳本，這是第二次對話窍蓝；
主機(jī)A再發(fā)出一個數(shù)據(jù)包確認(rèn)主機(jī)B的要求同步：“我現(xiàn)在就發(fā)，你接著吧繁成！”吓笙，這是第三次對話。三次“對話”的目的是使數(shù)據(jù)包的發(fā)送和接收同步巾腕，經(jīng)過三次“對話”之后面睛，A才向B正式發(fā)送數(shù)據(jù)。

面向非連接的UDP協(xié)議
“面向非連接”就是在正式通信前不必與對方先建立連接尊搬，不管對方狀態(tài)就直接發(fā)送叁鉴。與手機(jī)短信非常相似：你在發(fā)短信的時候，只需要輸入對方手機(jī)號就OK了佛寿。

TCP與UDP基本區(qū)別
1.基于連接與無連接
2.TCP要求系統(tǒng)資源較多幌墓，UDP較少；
3.UDP程序結(jié)構(gòu)較簡單
4.流模式（TCP）與數(shù)據(jù)報模式(UDP);
5.TCP保證數(shù)據(jù)正確性，UDP可能丟包
6.TCP保證數(shù)據(jù)順序常侣，UDP不保證
　　
UDP應(yīng)用場景：
1.面向數(shù)據(jù)報方式
2.網(wǎng)絡(luò)數(shù)據(jù)大多為短消息
3.擁有大量Client
4.對數(shù)據(jù)安全性無特殊要求
5.網(wǎng)絡(luò)負(fù)擔(dān)非常重蜡饵，但對響應(yīng)速度要求高

具體編程時的區(qū)別：

socket()的參數(shù)不同
UDP Server不需要調(diào)用listen和accept
UDP收發(fā)數(shù)據(jù)用sendto/recvfrom函數(shù)
TCP：地址信息在connect/accept時確定
UDP：在sendto/recvfrom函數(shù)中每次均需指定地址信息
UDP：shutdown函數(shù)無效
參考

了解web安全嗎？說一下XSS原理

如果把瀏覽器看作WEB2.0后時代的操作系統(tǒng)袭祟，那么客戶端腳本就相當(dāng)于傳統(tǒng)的應(yīng)用程序验残，而XSS的攻擊方式其實就相當(dāng)于在被攻擊者的系統(tǒng)上執(zhí)行了一個木馬程序捞附。但這種“木馬”有個很大的缺點巾乳，就是無法像傳統(tǒng)木馬那樣在操作系統(tǒng)中安家，以后還能自動執(zhí)行鸟召。
XSS又叫CSS (Cross Site Script) 胆绊，跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼欧募，當(dāng)用戶瀏覽該頁之時压状，嵌入其中Web里面的html代碼會被執(zhí)行，從而達(dá)到惡意攻擊用戶的特殊目的跟继。
為什么會出現(xiàn)XSS呢种冬，這個沒什么好說的，肯定是過濾不嚴(yán)舔糖，或者就是程序猿認(rèn)為XSS并沒有什么實際的用途娱两，從而忽略了XSS攻擊的產(chǎn)生。

圖解HTTP的解釋：
跨站腳本攻擊(Cross-Site Scripting金吗，XSS)是指通過存在安全漏洞的 Web 網(wǎng)站注冊用戶的瀏覽器內(nèi)運行非法的 HTML 標(biāo)簽或 JavaScript 進(jìn)行的一種攻擊十兢。動態(tài)創(chuàng)建的 HTML 部分有可能隱藏著安全漏洞。就這樣摇庙，攻擊者編寫腳本設(shè)下陷阱旱物，用戶在自己的瀏覽器上運行時，一不小心就會受到被動攻擊卫袒。
跨站腳本攻擊有可能造成以下影響宵呛。
● 利用虛假輸入表單騙取用戶個人信息。
● 利用腳本竊取用戶的 Cookie 值夕凝，被害者在不知情的情況下宝穗，幫助攻擊者發(fā)送惡意請求。
● 顯示偽造的文章或圖片迹冤。

其他常見的攻擊方式：
針對WEB的攻擊技術(shù)：

HTTP 不具備必要的安全功能
在客戶端即可篡改請求
針對 Web 應(yīng)用的攻擊模式主動被動

因輸出值轉(zhuǎn)義不完全引發(fā)的安全漏洞：

跨站腳本攻擊
SQL 注入攻擊
OS 命令注入攻擊
HTTP 或郵件首部注入攻擊
目錄遍歷攻擊
遠(yuǎn)程文件包含漏洞

因設(shè)置或設(shè)計上的缺陷引發(fā)的安全漏洞：

強(qiáng)制瀏覽
不正確的錯誤消息處理
開放重定向

因會話管理疏忽引發(fā)的安全漏洞：

會話劫持
會話固定攻擊
跨站點請求偽造

說一下 CSRF 的理解讽营；

跨站點請求偽造(Cross-Site Request Forgeries，CSRF)攻擊是指攻擊者通過設(shè)置好的陷阱泡徙，強(qiáng)制對已完成認(rèn)證的用戶進(jìn)行非預(yù)期的個人信息或設(shè)定信息等某些狀態(tài)更新橱鹏，屬于被動攻擊。
跨站點請求偽造有可能會造成以下等影響:
● 利用已通過認(rèn)證的用戶權(quán)限更新設(shè)定信息等
● 利用已通過認(rèn)證的用戶權(quán)限購買商品
● 利用已通過認(rèn)證的用戶權(quán)限在留言板上發(fā)表言論
百科

session和cookie的區(qū)別

由于HTTP協(xié)議是無狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶的狀態(tài)時莉兰，就需要用某種機(jī)制來識具體的用戶挑围，這個機(jī)制就是Session.典型的場景比如購物車，當(dāng)你點擊下單按鈕時糖荒，由于HTTP協(xié)議無狀態(tài)杉辙，所以并不知道是哪個用戶操作的，所以服務(wù)端要為特定的用戶創(chuàng)建了特定的Session捶朵，用用于標(biāo)識這個用戶蜘矢，并且跟蹤用戶，這樣才知道購物車?yán)锩嬗袔妆緯劭础＿@個Session是保存在服務(wù)端的品腹，有一個唯一標(biāo)識。在服務(wù)端保存Session的方法很多红碑，內(nèi)存舞吭、數(shù)據(jù)庫、文件都有析珊。集群的時候也要考慮Session的轉(zhuǎn)移羡鸥，在大型的網(wǎng)站，一般會有專門的Session服務(wù)器集群忠寻，用來保存用戶會話潘懊，這個時候 Session 信息都是放在內(nèi)存的艺智，使用一些緩存服務(wù)比如Memcached之類的來放 Session疤苹。
思考一下服務(wù)端如何識別特定的客戶信峻？這個時候Cookie就登場了。每次HTTP請求的時候祭饭，客戶端都會發(fā)送相應(yīng)的Cookie信息到服務(wù)端芜茵。實際上大多數(shù)的應(yīng)用都是用 Cookie 來實現(xiàn)Session跟蹤的，第一次創(chuàng)建Session的時候倡蝙，服務(wù)端會在HTTP協(xié)議中告訴客戶端九串，需要在 Cookie 里面記錄一個Session ID，以后每次請求把這個會話ID發(fā)送到服務(wù)器寺鸥，我就知道你是誰了猪钮。有人問，如果客戶端的瀏覽器禁用了 Cookie 怎么辦胆建？一般這種情況下烤低，會使用一種叫做URL重寫的技術(shù)來進(jìn)行會話跟蹤，即每次HTTP交互笆载，URL后面都會被附加上一個諸如 sid=xxxxx 這樣的參數(shù)扑馁，服務(wù)端據(jù)此來識別用戶涯呻。
Cookie其實還可以用在一些方便用戶的場景下，設(shè)想你某次登陸過一個網(wǎng)站腻要，下次登錄的時候不想再次輸入賬號了复罐，怎么辦？這個信息可以寫到Cookie里面雄家，訪問網(wǎng)站的時候效诅，網(wǎng)站頁面的腳本可以讀取這個信息，就自動幫你把用戶名給填了趟济，能夠方便一下用戶乱投。這也是Cookie名稱的由來，給用戶的一點甜頭咙好。

所以篡腌，總結(jié)一下：
Session是在服務(wù)端保存的一個數(shù)據(jù)結(jié)構(gòu)，用來跟蹤用戶的狀態(tài)勾效，這個數(shù)據(jù)可以保存在集群、數(shù)據(jù)庫叛甫、文件中层宫；

Cookie是客戶端保存用戶信息的一種機(jī)制，用來記錄用戶的一些信息其监，也是實現(xiàn)Session的一種方式萌腿。

數(shù)據(jù)庫的索引，說一下非主鍵索引是怎么實現(xiàn)的抖苦？

數(shù)據(jù)庫索引毁菱，是數(shù)據(jù)庫管理系統(tǒng)中一個排序的數(shù)據(jù)結(jié)構(gòu)，以協(xié)助快速查詢锌历、更新數(shù)據(jù)庫表中數(shù)據(jù)贮庞。索引的實現(xiàn)通常使用B樹及其變種B+樹。

在數(shù)據(jù)之外究西，數(shù)據(jù)庫系統(tǒng)還維護(hù)著滿足特定查找算法的數(shù)據(jù)結(jié)構(gòu)窗慎，這些數(shù)據(jù)結(jié)構(gòu)以某種方式引用（指向）數(shù)據(jù)，這樣就可以在這些數(shù)據(jù)結(jié)構(gòu)上實現(xiàn)高級查找算法卤材。這種數(shù)據(jù)結(jié)構(gòu)遮斥，就是索引。
參考文章里面詳細(xì)些

說一下你最近看的三本書扇丛，介紹一下

盡量要說計算機(jī)相關(guān)的术吗，一定要熟悉，否則打臉

tcp粘包是什么帆精，怎么辦较屿？

1. 什么是粘包現(xiàn)象
TCP粘包是指發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時粘成一包材蹬，從接收緩沖區(qū)看，后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾吝镣。

2. 為什么出現(xiàn)粘包現(xiàn)象
　〉唐鳌（1）發(fā)送方原因
　　我們知道，TCP默認(rèn)會使用Nagle算法末贾。而Nagle算法主要做兩件事：1）只有上一個分組得到確認(rèn)闸溃，才會發(fā)送下一個分組；2）收集多個小分組拱撵，在一個確認(rèn)到來時一起發(fā)送辉川。
　　所以，正是Nagle算法造成了發(fā)送方有可能造成粘包現(xiàn)象拴测。

（2）接收方原因
　　TCP接收到分組時乓旗，并不會立刻送至應(yīng)用層處理，或者說集索，應(yīng)用層并不一定會立即處理屿愚；實際上，TCP將收到的分組保存至接收緩存里务荆，然后應(yīng)用程序主動從緩存里讀收到的分組妆距。這樣一來，如果TCP接收分組的速度大于應(yīng)用程序讀分組的速度函匕，多個包就會被存至緩存娱据，應(yīng)用程序讀時，就會讀到多個首尾相接粘到一起的包盅惜。

3. 什么時候需要處理粘包現(xiàn)象
　≈惺！（1）如果發(fā)送方發(fā)送的多個分組本來就是同一個數(shù)據(jù)的不同部分，比如一個很大的文件被分成多個分組發(fā)送抒寂，這時结啼，當(dāng)然不需要處理粘包的現(xiàn)象；

（2）但如果多個分組本毫不相干蓬推，甚至是并列的關(guān)系妆棒，我們就一定要處理粘包問題了。比如沸伏，我當(dāng)時要接收的每個分組都是一個有固定格式的商品信息糕珊，如果不處理粘包問題，每個讀進(jìn)來的分組我只會處理最前邊的那個商品毅糟，后邊的就會被丟棄红选。這顯然不是我要的結(jié)果。

4. 如何處理粘包現(xiàn)象
（1）發(fā)送方
　　對于發(fā)送方造成的粘包現(xiàn)象姆另，我們可以通過關(guān)閉Nagle算法來解決喇肋，使用TCP_NODELAY選項來關(guān)閉Nagle算法坟乾。

（2）接收方
　　遺憾的是TCP并沒有處理接收方粘包現(xiàn)象的機(jī)制，我們只能在應(yīng)用層進(jìn)行處理蝶防。

（3）應(yīng)用層處理
　　應(yīng)用層的處理簡單易行甚侣！并且不僅可以解決接收方造成的粘包問題，還能解決發(fā)送方造成的粘包問題间学。

解決方法就是循環(huán)處理：應(yīng)用程序在處理從緩存讀來的分組時殷费，讀完一條數(shù)據(jù)時，就應(yīng)該循環(huán)讀下一條數(shù)據(jù)低葫，直到所有的數(shù)據(jù)都被處理详羡；但是如何判斷每條數(shù)據(jù)的長度呢？

兩種途徑：

1）格式化數(shù)據(jù)：每條數(shù)據(jù)有固定的格式（開始符嘿悬、結(jié)束符）实柠，這種方法簡單易行，但選擇開始符和結(jié)束符的時候一定要注意每條數(shù)據(jù)的內(nèi)部一定不能出現(xiàn)開始符或結(jié)束符善涨；

2）發(fā)送長度：發(fā)送每條數(shù)據(jù)的時候窒盐，將數(shù)據(jù)的長度一并發(fā)送，比如可以選擇每條數(shù)據(jù)的前4位是數(shù)據(jù)的長度躯概，應(yīng)用層處理時可以根據(jù)長度來判斷每條數(shù)據(jù)的開始和結(jié)束登钥。

當(dāng)時在做購物車的時候，我最開始的做法是設(shè)置開始符（0x7e）和結(jié)束符（0xe7）娶靡，但在測試大量數(shù)據(jù)的時候，發(fā)現(xiàn)了數(shù)據(jù)異常看锉。正如我所猜測姿锭，在調(diào)試過程中發(fā)現(xiàn)某些數(shù)據(jù)內(nèi)部包含了它們。因為要處理的數(shù)據(jù)是量非常龐大伯铣，為做到萬無一失呻此，最后我采用了發(fā)送長度的方式。再也沒有因為粘包而出過問題腔寡。

正常情況下UDP不會粘包
UDP有明確的結(jié)束標(biāo)志,不會有粘包的,UDP本身有對數(shù)據(jù)完整性的校驗,不完整的包會被丟棄,所以也不會不完整焚鲜。
更多詳解