tcp協議幾個要注意的點

首先看下tcp的狀態轉移圖，從幾個角度看下這張圖：

首先，代碼自己邏輯有問題，反應到上圖會有什麼現象，

    1，服務器端出現大量的syn_rcvd，這個明顯很明顯，客戶端故意不發ack，應該是客戶端邏輯問題，有人在SYN泛洪。

    2，服務器端若是代碼收到fin或者rst，不顯式調用close會出現什麼狀況，服務端會一直停留在close_wait.

    3,客戶端或者服務端出現大量的time_wait這個正常嗎，這兩個狀況都是有可能出現的。首先看第一個，客戶端大量出現。我用requests請求，頻繁post/get，或者頻繁調用curl(會馬上四次握手結束鏈接)。這種狀況通常不會出問題，可是若是使用多線程/進程，大量post的時候，會佔光操做系統fd，若是不作內核參數優化，會報錯！這種狀況，若是發給一個地址，能用長鏈接，儘可能用長鏈接，能迅速改善。第二種是服務端出現大量的close_wait，這裏就要看訪問請求的類型了，是否該開放長鏈接，長鏈接timeout是否設置得當，是否該使用套接字複用。

總結，因爲代碼層次誤操做，不顯式close，長鏈接使用不當，會響應出現timewait，close_wait，其中，長鏈接及其超時設置不當，生產中出現的比較多，特別是使用apache，因爲基於多線程方式，容易down。

第二個問題，何時會發fin/rst的問題。

第三個，python中的read/recv函數如何判斷fin/rst,這裏和c的不同，作了簡化

 

補充下，http1.0默認是短連接，http1.1是長連接，而urllib2/3默認是短連接，request得注意版本。