海康威視面試python後端題

1. 請簡述三次握手和四次揮手：

　答：首先TCP是傳輸控制協議，提供可靠的鏈接服務，採用三次握手確認創建一個鏈接，在創建TCP鏈接時，須要客戶端和服務器總共發送3個包。

　　　

　　　三次握手的目的是鏈接服務器的指定端口、創建TCP鏈接、同步雙方的序列號和確認號、交換TCP窗口大小信息，在socket編程中，客戶端在執行connect()時將觸發三次握手。

　　

　　第一次握手：創建鏈接時，客戶端發送syn包到服務器，並進入SYN_SENT狀態，等待服務器確認。  SYN：同步序列編號

　　第二次握手：服務器收到客戶端的syn包，必須向客戶端發送確認信號（ack ），而且向客戶端頁發送一個syn包，此時服務器進入SYN_RECV狀態

　　第三次握手：客戶端收到服務器syn+ack，向服務器發送確認包ack，此包發送完畢，客戶端和服務器端進入ESTABLISHED(tcp鏈接成功)， 完成三次握手。

 

　　四次揮手： TCP鏈接的斷開須要發送四次包，因此稱之爲四次揮手， 且Client端和服務器端都可主動發出斷開請求，在socket中，任何一方執行close()操做皆可產收揮手操做。

　　

　　·第一次揮手：Cilent端中止發送報文，併發出斷開請求FIN，並將序列號置爲X，此時客戶端進入（終止等待1）狀態。

　　·第二次揮手：Server端接收到FIN包後當即向Client端發送確認包ACK = X+1,並置序列號爲Y，此時服務器進入關閉等待狀態。

　　·第三次揮手：Server端在發送確認信號後也向Client端發送了關閉信號FIN和確認信號ACK，並將序列號置爲Y,此時服務器進入（最後確認）狀態。

　　·第四次揮手：Client端接收到服務器發來的斷開請求報文後，必須發出確認信號ACK = Y, 並置序列號爲Z+1, 並進入（時間等待）狀態，且此時鏈接尚未斷，客戶端須要等待2MSL時間纔會斷開

2.　爲何握手三次且揮手四次？

　　答：由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，

　　因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

 

3. 　爲何第四次握手後要等待2MSL(最大報文生存時間)時間纔會返回close狀態？

　　答：假象網絡不可靠，當客戶端發送ack後ack卻丟失了，那麼服務器端收不到確認信號，就會一直髮送FIN請求，因此這時客戶端不能當即關閉，必須等待2MSL時間才行(由於客戶端發送ack須要MSL， 服務端發送FIN也須要MSL時間)，

　　若是在2MSL時間內沒收到服務器端發來的FIN，就表明服務器端已經接收到了客戶端的ack，詞彙客戶端纔會關閉。

4。get和post請求的區別？

　　答：首先定性：get和post並無什麼本質的區別。

　　　　w3schools的說法：

　　　　　　GET在瀏覽器回退時是無害的，而POST會再次提交請求

　　　　　　GET產生的URL地址能夠被Bookmark，而POST不能夠。

　　　　　　GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。

　　　　　　GET請求只能進行url編碼，而POST支持多種編碼方式。

　　　　　　GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。

　　　　　　GET請求在URL中傳送的參數是有長度限制的，而POST麼有。

　　　　　　對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。

　　　　　　GET比POST更不安全，由於參數直接暴露在URL上，因此不能用來傳遞敏感信息。

　　　　　　GET參數經過URL傳遞，POST放在Request body中。

　　然而這不是本質，本質是：

　　　　get和post是什麼？ 他們倆是http協議中的兩種請求方式。

　　　　http是什麼呢？http是基於tip/ip的關於數據如何在萬維網中通訊的協議

　　　　http的底層是TCP/IP，那就是說get和post底層也是TCP/IP，也就是說，get和pos請求本質都是TCP鏈接，get請求和post請求能作的事兒是同樣的。你要給get請求加上request body，給post請求帶上url參數，技術上徹底行得通。

　　　　可是不一樣的瀏覽器和服務器對此作出了一些限制，如url長度不超過2k個字節等等。

　　不過get和post請求仍是有一個重大區別的：GET產生一個TCP數據包；POST產生兩個TCP數據包。

　　　　get請求會將header和data一併發過去，服務器相應200

　　　　可是post請求：瀏覽器先發送header， 服務器響應100 continue, 瀏覽器再發送data，服務器響應200.

　　　　也就是說，GET只須要汽車跑一趟就把貨送到了，而POST得跑兩趟，第一趟，先去和服務器打個招呼「嗨，我等下要送一批貨來，大家打開門迎接我」，而後再回頭把貨送過去。

5. 簡述python 主流web框架特性。

　　答：

　　　　Django：Python 界最全能的 web 開發框架，battery-include 各類功能完備，可維護性和開發速度一級棒。常有人說 Django 慢，其實主要慢在 Django ORM 與數據庫的交互上，因此是否選用 Django，

　　取決於項目對數據庫交互的要求以及各類優化。而對於 Django 的同步特性致使吞吐量小的問題，其實能夠經過 Celery 等解決，倒不是一個根本問題。Django 的項目表明：Instagram，Guardian。

　　　　Tornado：天生異步，性能強悍是 Tornado 的名片，然而 Tornado 相比 Django 是較爲原始的框架，諸多內容須要本身去處理。固然，隨着項目愈來愈大，框架可以提供的功能佔比愈來愈小，更多的內容須要團隊本身實現，

　　而大項目每每須要性能的保證，這時候 Tornado 就是比較好的選擇。Tornado項目表明：知乎。

　　　　Flask：微框架的典範，號稱 Python 代碼寫得最好的項目之一。Flask 的靈活性，也是雙刃劍：能用好 Flask 的，能夠作成 Pinterest，用很差就是災難（顯然對任何框架都是這樣）。

　　Flask 雖然是微框架，可是也能夠作成規模化的 Flask。加上 Flask 能夠自由選擇本身的數據庫交互組件（一般是 Flask-SQLAlchemy），並且加上 celery +redis 等異步特性之後，Flask 的性能相對 Tornado 也不逞多讓，也許Flask 的靈活性多是某些團隊更須要的。

6. 解釋GIL

　　答：(Global Interpreter Lock)全局解釋器鎖，是計算機程序設計語言解釋器用於同步線程的一種機制，它使得任什麼時候刻僅會有一個線程在執行，即便在多核處理器上，使用GIL的解釋器也只容許同一時間執行一個程序，常見的使用GIL的解釋器有CPython和Ruby MRI.

　　CPython解釋器的線程使用的是操做系統的原生線程，在linux下是pthread, 在windows下是Win thread，徹底由操做系統調度線程的執行。

　　在討論普通的GIL以前，有一點要強調的是GIL只會影響到那些嚴重依賴CPU的程序（好比計算型的）。 若是你的程序大部分只會涉及到I/O，好比網絡交互，那麼使用多線程就很合適， 由於它們大部分時間都在等待。

　　實際上，你徹底能夠放心的建立幾千個Python線程， 現代操做系統運行這麼多線程沒有任何壓力，沒啥可擔憂的。

　　Python的多線程在多核CPU上，只對於IO密集型計算產生正面效果；而當有至少有一個CPU密集型線程存在，那麼多線程效率會因爲GIL而大幅降低。

 7. 死鎖的產生、避免、解決

　　答：死鎖的產生緣由：

　　　　　　（1）由於系統資源不足。

　　　　　　（2）進程運行推動的順序不合適。

　　　　　　（3）資源分配不當

　　　　若是系統自資源充足，進程的請求均可以獲得知足，死鎖出現的可能就會很是低，不然就會因競爭有限的資源而陷入死鎖，其次，進程運行推動順序和速度不一樣，也會產生死鎖。

　　　　產生死鎖的四個必要條件：

　　　　　　（1）互斥條件：一個資源每次只能被一個進程調用。

　　　　　　（2）請求與保持條件：一個進程因請求資源而阻塞時，對已獲取的資源保持不放。

　　　　　　（3）不剝奪條件：進程已獲取的資源，在未使用完以前，不能強制剝奪。

　　　　　　（4）循環等待條件：若干進程之間造成一種頭尾相接的循環等待資源關係。

　　　　這四個是產生死鎖的必要條件，只要系統發生死鎖，這些條件必然成立，而只要上述條件之一不知足，思索就不會發生。

8。redis崩潰了怎麼辦？

　　答：首先是避免崩潰，保證redis高可用性，主從+哨兵 來避免redis全盤崩潰。

　　　　其次是redis持久化，一旦redis重啓，自動從磁盤上加載數據，快速回復緩存數據。

　　ps: 緩存雪崩：存雪崩是指在咱們設置緩存時採用了相同的過時時間，致使緩存在某一時刻同時失效，或者某一時間緩存大範圍掛掉，致使請求所有轉發到DB，DB瞬時壓力太重宕掉。

　　　　緩存穿透：緩存穿透是指查詢一個必定不存在的數據，因爲緩存是不命中時被動寫的，而且出於容錯考慮，若是從存儲層查不到數據則不寫入緩存，這將致使這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。

　　在流量大時，可能DB就掛掉了

9. TCP和UDP：

　　答： 1.基於鏈接與無鏈接
  　　　　2.TCP要求系統資源較多，UDP較少； 
  　　　　3.UDP程序結構較簡單 
  　　　　4.流模式（TCP）與數據報模式(UDP); 
  　　　　5.TCP保證數據正確性，UDP可能丟包 
  　　　　6.TCP保證數據順序，UDP不保證 

　　　　

10. http的長鏈接和短鏈接：

　　推薦這篇文章：http://www.javashuo.com/article/p-fiwikntb-bu.html

　　答：HTTP的長鏈接和短鏈接本質上是TCP長鏈接和短鏈接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，

　　使在網絡上的另外一端收到發端發出的全部包，而且順序與發出順序一致。TCP有可靠，面向鏈接的特色。

　　在HTTP/1.0中，默認使用的是短鏈接。也就是說，瀏覽器和服務器每進行一次HTTP操做，就創建一次鏈接，但任務結束就中斷鏈接。若是客戶端瀏覽器訪問的某個HTML或其餘類型的 Web頁中包含有其餘的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會創建一個HTTP會話。

但從 HTTP/1.1起，默認使用長鏈接，用以保持鏈接特性。使用長鏈接的HTTP協議，會在響應頭有加入這行代碼：Connection:keep-alive

　　在使用長鏈接的狀況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的 TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接。Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間。實現長鏈接要客戶端和服務端都支持長鏈接。

HTTP協議的長鏈接和短鏈接，實質上是TCP協議的長鏈接和短鏈接。

 

想了解更多Python關於爬蟲、數據分析的內容，獲取大量爬蟲爬取到的源數據，歡迎你們關注個人微信公衆號：悟道Python