今天模擬了四次揮手中的一些錯誤，開門見山，先來TCP狀態轉移圖
當然四次揮手的主動方不一定是客戶端，正常情況下是客戶端，但是如果客戶端長時間未響應，服務器也可以主動斷開（防止惡意佔用系統資源和網絡不好情況）
四次揮手圖和狀態圖來自百度，連接圖來自我的服務器
- 在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨的連接，在處理完本次請求後，就自動釋放連接。
- 在HTTP 1.1中則可以在一次連接中處理多個請求，並且多個請求可以重疊進行，不需要等待一個請求結束後再發送下一個請求。
連接中出現大量FIN_WAIT2和CLOSE_WAIT問題
CLOSE_WAIT問題
我運行服務器時，併發連接，結合代碼和四次揮手圖片，發現
CLOSE_WAIT狀態被動關閉的狀態,此時自己還沒有發送最後一次FIN包，處於忙處理階段，一般是幾分鐘的過程，比如服務器需要繁瑣的處理和交流，依然需要發包，此時就會有一定量的CLOSE_WAIT。
服務器端處於CLOSE_WAIT狀態，說明應用程序沒有關閉相應的socket，也就不會發送最後的FIN,所以客戶端處於FIN_WAIT_2狀態。
FIN_WAIT2問題
這個就比較嚴重了，作爲主動關閉方，當主動方發送FIN包時，良性的被動方自然立刻回覆ACK。主動方就跳過FIN_WAIT1狀態進入FIN_WAIT2狀態，如果被動方不發送ACK，主動方則會一直處於FIN_WAIT2。
表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你，稍後再關閉連接。
比如服務器發現客戶端有問題，斷開連接，但是客戶端遲遲不發FIN包，一直進行數據傳輸，那麼TCP規則下，服務器一直要保持FIN_WAIT2狀態
SERVER由於某種原因關閉連接，如KEEPALIVE的超時，這樣，作爲主動關閉的SERVER一方就會進入 FIN_WAIT2狀態，但TCP/IP協議棧有個問題，FIN_WAIT2狀態是沒有超時的（不象TIME_WAIT狀態），所以如果CLIENT不關閉，這個FIN_WAIT_2狀態將保持到系統重新啓動，越來越多的FIN_WAIT_2狀態會致使內核crash。
根據網上的一些博客設置一些參數，可以讓長時間的FINWAIT2進入TIME_WAIT
現實終究是打敗了標準
FIN_WAIT2狀態的 TCP 連接會進入TIME_WAIT狀態