四次握手流程

先來一張TCP斷開連線流程圖：（圖片來自於網路）

上圖中，A是主動關閉方，B是被動關閉方，四次握手可以描述為：

• 第一次握手：A告訴B，“我要關閉連線了”。
• 第二次握手：B回覆A，“我知道你要關閉了，但是請等一下，我還有資料沒有傳完，你等我訊息”。
• 第三次握手：B告訴A，“我的資料發完了，你可以關閉連線了”。
• 第四次握手：A回覆B，“好的，你先關吧，我2MSL時間後再關”。

出現大量CLOSE_WAIT的原因

被動關閉方收到主動關閉方發來的FIN，則會迴應ACK，並進入CLOSE_WAIT狀態。但如果被動關閉方不執行close()，就不能由CLOSE_WAIT遷移到LAST_ACK。在該狀態下，recv/read會返回0。

舉例來說，當主動關閉方呼叫closesocket的時候，被動關閉方的應用程式正在呼叫recv，這時候有可能應用程式沒有收到主動關閉方發來的FIN包，而是由TCP代回了一個ACK，所以就陷入CLOSE_WAIT出不來了。

TCP的KeepLive功能，可以讓作業系統替我們自動清理掉CLOSE_WAIT的連線。但是KeepLive在Windows作業系統下預設是7200秒，需要調整一下：

開啟登錄檔（執行 -> 輸入regedit -> 回車），在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters裡修改：

KeepAliveTime              REG_DWORD  300000
KeepAliveInterval          REG_DWORD  1000
TcpMaxDataRetransmissions  REG_DWORD  5

為什麼要有TIME_WAIT

• 讓4次握手關閉流程更加可靠。
  若最後一個ACK丟失，被動關閉方會重新發一個FIN。在TIME_WAIT狀態內，主動關閉方收到重發的FIN後，會重發ACK。

  而倘若沒有2MSL的TIME_WAIT狀態，當主動關閉方收到重發的FIN後，會回覆一個RST，被動關閉方在收到RST後，會將其解釋成一個錯誤：connect reset by peer。

• 等待老的重複分節在網路中消逝，防止lost duplicate對後續新建的incarnation connection的傳輸造成破壞。

  • lost duplicate：在實際的網路中非常常見，經常是由於路由器產生故障，路徑無法收斂，導致一個數據包在路由器A、B、C之間做類似死迴圈的跳轉。IP頭部有個TTL，限制了一個包在網路中的最大跳數。因此這個包有兩種命運，

    • TTL變為0，在網路中消失；
    • TTL在變為0之前路由器路徑收斂，它憑藉剩餘的TTL跳數終於到達目的地。但非常可惜的是TCP通過超時重傳機制在早些時候傳送了一個跟它一模一樣的包，並且先於它到達了目的地，因此它註定被TCP協議棧拋棄；

  • incarnation connection：跟上次的socket pair一模一樣的新連線。倘若沒有2MSL時間的TIME_WAIT狀態來等待lost duplicate失效，那麼就會出現如下情況，

    一個incarnation connection收到的seq=1000，這時來了一個lost duplicate為seq=1000，len=1000，則tcp認為這個lost duplicate合法，並存放入了receive buffer，導致傳輸出現錯誤。

TIME_WAIT狀態為什麼持續2MSL

MSL（Maximum Segment Lifetime）是指報文最大生存時間。RFC 793規範MSL為2min。然後，實際TCP實現中的常用值是30s、1min或2min。

之所以是2MSL而不是1MSL，是因為這裡面還包括了最後一個ACK在路上的時間。

2MSL在Windows上預設是4min。

TIME_WAIT帶來的問題

RFC要求socket pair在處於TIME_WAIT時，不能再起一個incarnation connection。但絕大部分TCP實現，強加了更為嚴格的限制，“在2MSL等待期間，socket中使用的本地埠在預設情況下不能再被使用”。

這個限制對於client來說是無所謂的，但是對於server，就嚴重了。一旦server端主動關閉了某個client的連線，導致server監聽的埠在2MSL時間內無法接受新的連線，這顯然是不行的。

• 方案一
  保證由client主動發起關閉。

• 方案二
  server主動關閉的時候使用RST的方式，不進入 TIME_WAIT狀態。
  具體做法是設定socket的SO_LINGER選項。

• 方案三
  給server的socket設定SO_REUSEADDR選項，這樣的話就算server埠處於TIME_WAIT狀態，在這個埠上依舊可以將服務啟動。

  當然，“非相同socket pair”這個限制依然存在，即在2MSL時間內仍然拒絕來自與之前斷掉的client相同ip和port的連線，錯誤資訊為address already in use。

  程式碼如下：

int opt = 1;
setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

不過在BSD-derived實現和Windows Server 2003中，只要SYN的seq比上一次關閉時的最大seq還要大，那麼TIME_WAIT狀態一樣接受這個SYN。

• 方案四
  Linux實現了一個TIME_WAIT狀態快速回收的機制，即無需等待2MSL這麼久的時間，而是等待一個Retrans時間即釋放，也就是等待一個重傳時間(一般超級短，以至於你都來不及能在netstat -ant中看到TIME_WAIT狀態)隨即釋放。
  釋放了之後，一個連線的tuple元素資訊就都沒有了，而此時，新建立的TCP卻面臨著危險：

  • 可能被之前遲到的FIN包給終止
  • 可能被之前連線劫持

  於是需要有一定的手段避免這些危險。什麼手段呢？雖然曾經連線的tuple資訊沒有了，但是在IP層還可以儲存一個peer資訊，注意這個資訊不單單是用於TCP這個四層協議的，路由邏輯也會使用它，其欄位包括但不限於：

  • 對端ip地址
  • peer最後一次被TCP觸控到的時間戳

  在快速釋放掉TIME_WAIT連線之後，peer依然保留著。丟失的僅僅是埠資訊。不過有了peer的IP地址資訊以及TCP最後一次觸控它的時間戳就足夠了，TCP規範給出一個優化，即一個新的連線除了同時觸犯了以下幾點，其它的均可以快速接入，即使它本應該處在TIME_WAIT狀態：

  • 來自同一臺機器的TCP連線攜帶時間戳
  • 之前同一臺peer機器(僅僅識別IP地址，因為連線被快速釋放了，沒了埠資訊)的某個TCP資料在MSL秒之內到過本機
  • 新連線的時間戳小於peer機器上次TCP到來時的時間戳，且差值大於重放視窗戳

  看樣子只有以上的3點的同時滿足才能拒絕掉一個新連線，要比TIME_WAIT機制設定的障礙導致的連線拒絕機率小很多，但是要看到，上述的快速釋放機制沒有埠資訊！這就把機率擴大了65535倍。然而，如果對於單獨的機器而言，這不算什麼，因為單臺機器的時間戳不可能倒流的，出現上述的3點均滿足時，一定是老的重複資料包又回來了。
  但是，一旦涉及到NAT裝置，就悲催了，因為NAT裝置將資料包的源IP地址都改成了一個地址(或者少量的IP地址)，但是卻基本上不修改TCP包的時間戳。

  TIME_WAIT快速回收在Linux上通過net.ipv4.tcp_tw_recycle啟用，由於其根據時間戳來判定，所以必須開啟TCP時間戳才有效。

  建議：如果前端部署了三/四層NAT裝置，儘量關閉快速回收，以免發生NAT背後真實機器由於時間戳混亂導致的SYN拒絕問題。

Windows下調整TIME_WAIT時間

1、開啟登錄檔（執行 -> 輸入regedit -> 回車）
2、在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters裡新增一項：

TcpTimedWaitDelay  REG_DWORD  0x0000001e(30)

Linux下調整核心引數

編輯檔案：

vim /etc/sysctl.conf

加入以下內容：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30

最後執行：

/sbin/sysctl -p

使引數生效。

• net.ipv4.tcp_syncookies = 1
  開啟SYN cookies，當出現SYN等待佇列溢位時，啟用cookies來處理，可防範少量SYN攻擊。預設為0，表示關閉。

• net.ipv4.tcp_tw_reuse = 1
  開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線，預設為0，表示關閉。

• net.ipv4.tcp_tw_recycle = 1
  開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉。

• net.ipv4.tcp_fin_timeout = 30
  系統預設的 TIMEOUT 時間。

Linux下kill程序時對socket的關閉處理

Linux照顧到了一種特殊情況，即殺死程序的情況，在系統kill程序的時候，會直接呼叫連線的close函式單方面關閉一個方向的連線，然後並不會等待對端關閉另一個方向的連線程序即退出。現在的問題是，TCP規範和UNIX程序的檔案描述符規範直接衝突！程序關閉了，套接字就要關閉，但是TCP是全雙工的，你不能保證對端也在同一個時刻同意並且實施關閉動作，既然連線不能關閉，作為檔案描述符，程序就不會關閉得徹底！所以，Linux使用了一種“子狀態”的機制，即在程序退出的時候，單方面傳送FIN，然後不等後續的關閉序列即將連線拷貝到一個佔用資源更少的TW套接字，狀態直接轉入TIMW_WAIT，此時記錄一個子狀態FIN_WAIT_2，接下來的套接字就和原來的屬於程序描述符的連線沒有關係了。等到新的連線到來的時候，直接匹配到這個主狀態為TW，子狀態為FIN_WAIT_2的TW連線上，它負責處理FIN，FIN ACK等資料。

統計所有TCP連線的各種狀態的數量

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'