系統調優，你所不知道的TIME_WAIT和CLOSE_WAIT

你遇到過TIME_WAIT的問題嗎？

我相信很多都遇到過這個問題。一旦有使用者在喊：網路變慢了。第一件事情就是，netstat -a | grep TIME_WAIT | wc -l 一下，哎呀媽呀，幾千個TIME_WAIT。

然後，做的第一件事情就是：開啟Google或者Bing，輸入關鍵詞：too many time wait。一定能找到解決方案，而排在最前面或者被很多人到處轉載的解決方案一定是：

開啟 sysctl.conf 檔案，修改以下幾個引數：

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_timestamps = 1

你也會被告知，開啟tw_recylce和tw_reuse一定需要timestamps的支援，而且這些配置一般不建議開啟，但是對解決TIME_WAIT很多的問題，有很好的用處。

接下來，你就直接修改了這幾個引數，reload一下，發現，咦，沒幾分鐘，TIME_WAIT的數量真的降低了，也沒發現哪個使用者說有問題，然後就沒有然後了。

做到這一步，相信50%或者更高比例的開發就已經止步了。問題好像解決了，但是，要徹底理解並解決這個問題，可能就沒這麼簡單，或者說，還有很長的路要走！

什麼是TIME-WAIT和CLOSE-WAIT?

所謂，要解決問題，就要先理解問題。隨便改兩行程式碼，發現bug“沒有了”，也不是bug真的沒有了，只是隱藏在更深的地方，你沒有發現，或者以你的知識水平，你無法發現而已。

大家知道，由於socket是全雙工的工作模式，一個socket的關閉，是需要四次握手來完成的。

• 主動關閉連線的一方，呼叫close()；協議層傳送FIN包

• 被動關閉的一方收到FIN包後，協議層回覆ACK；然後被動關閉的一方，進入CLOSE_WAIT狀態，主動關閉的一方等待對方關閉，則進入FIN_WAIT_2狀態；此時，主動關閉的一方 等待 被動關閉一方的應用程式，呼叫close操作

• 被動關閉的一方在完成所有資料傳送後，呼叫close()操作；此時，協議層傳送FIN包給主動關閉的一方，等待對方的ACK，被動關閉的一方進入LAST_ACK狀態；

• 主動關閉的一方收到FIN包，協議層回覆ACK；此時，主動關閉連線的一方，進入TIME_WAIT狀態；而被動關閉的一方，進入CLOSED狀態

• 等待2MSL時間，主動關閉的一方，結束TIME_WAIT，進入CLOSED狀態

通過上面的一次socket關閉操作，你可以得出以下幾點：

1. 主動關閉連線的一方 - 也就是主動呼叫socket的close操作的一方，最終會進入TIME_WAIT狀態

2. 被動關閉連線的一方，有一箇中間狀態，即CLOSE_WAIT，因為協議層在等待上層的應用程式，主動呼叫close操作後才主動關閉這條連線

3. TIME_WAIT會預設等待2MSL時間後，才最終進入CLOSED狀態；

4. 在一個連線沒有進入CLOSED狀態之前，這個連線是不能被重用的！

所以，這裡憑你的直覺，TIME_WAIT並不可怕（not really，後面講），CLOSE_WAIT才可怕，因為CLOSE_WAIT很多，表示說要麼是你的應用程式寫的有問題，沒有合適的關閉socket；要麼是說，你的伺服器CPU處理不過來（CPU太忙）或者你的應用程式一直睡眠到其它地方(鎖，或者檔案I/O等等)，你的應用程式獲得不到合適的排程時間，造成你的程式沒法真正的執行close操作。

這裡又出現兩個問題：

1. 上文提到的連線重用，那連線到底是個什麼概念？

2. 協議層為什麼要設計一個TIME_WAIT狀態？這個狀態為什麼預設等待2MSL時間才會進入CLOSED

先解釋清楚這兩個問題，我們再來看，開頭提到的幾個網路配置究竟有什麼用，以及TIME_WAIT的後遺症問題。

Socket連線到底是個什麼概念？

大家經常提socket，那麼，到底什麼是一個socket？其實，socket就是一個 五元組，包括：

1. 源IP

2. 源埠

3. 目的IP

4. 目的埠

5. 型別：TCP or UDP

這個五元組，即標識了一條可用的連線。注意，有很多人把一個socket定義成四元組，也就是 源IP:源埠 + 目的IP:目的埠，這個定義是不正確的。

例如，如果你的本地出口IP是180.172.35.150，那麼你的瀏覽器在連線某一個Web伺服器，例如百度的時候，這條socket連線的四元組可能就是：

[180.172.35.150:45678, tcp, 180.97.33.108:80]

源IP為你的出口IP地址 180.172.35.150，源埠為隨機埠 45678，目的IP為百度的某一個負載均衡伺服器IP 180.97.33.108，埠為HTTP標準的80埠。

如果這個時候，你再開一個瀏覽器，訪問百度，將會產生一條新的連線：

[180.172.35.150:43678, tcp, 180.97.33.108:80]

這條新的連線的源埠為一個新的隨機埠 43678。

如此來看，如果你的本機需要壓測百度，那麼，你最多可以建立多少個連線呢？我在文章《雲思路 | 輕鬆構建千萬級投票系統》裡也稍微提過這個問題，沒有閱讀過本文的，可以傳送“投票系統”閱讀。

第二個問題，TIME_WAIT有什麼用？

如果我們來做個類比的話，TIME_WAIT的出現，對應的是你的程式裡的異常處理，它的出現，就是為了解決網路的丟包和網路不穩定所帶來的其他問題：

第一，防止前一個連線【五元組，我們繼續以 180.172.35.150:45678, tcp, 180.97.33.108:80 為例】上延遲的資料包或者丟失重傳的資料包，被後面複用的連線【前一個連線關閉後，此時你再次訪問百度，新的連線可能還是由180.172.35.150:45678, tcp, 180.97.33.108:80 這個五元組來表示，也就是源埠湊巧還是45678】錯誤的接收（異常：資料丟了，或者傳輸太慢了），參見下圖：

• SEQ=3的資料包丟失，重傳第一次，沒有得到ACK確認

• 如果沒有TIME_WAIT，或者TIME_WAIT時間非常端，那麼關閉的連線【180.172.35.150:45678, tcp, 180.97.33.108:80 的狀態變為了CLOSED，源埠可被再次利用】，馬上被重用【對180.97.33.108:80新建的連線，複用了之前的隨機埠45678】，並連續傳送SEQ=1,2 的資料包

• 此時，前面的連線上的SEQ=3的資料包再次重傳，同時，seq的序號剛好也是3（這個很重要，不然，SEQ的序號對不上，就會RST掉），此時，前面一個連線上的資料被後面的一個連線錯誤的接收

第二，確保連線方能在時間範圍內，關閉自己的連線。其實，也是因為丟包造成的，參見下圖：

• 主動關閉方關閉了連線，傳送了FIN；

• 被動關閉方回覆ACK同時也執行關閉動作，傳送FIN包；此時，被動關閉的一方進入LAST_ACK狀態

• 主動關閉的一方回去了ACK，主動關閉一方進入TIME_WAIT狀態；

• 但是最後的ACK丟失，被動關閉的一方還繼續停留在LAST_ACK狀態

• 此時，如果沒有TIME_WAIT的存在，或者說，停留在TIME_WAIT上的時間很短，則主動關閉的一方很快就進入了CLOSED狀態，也即是說，如果此時新建一個連線，源隨機埠如果被複用，在connect傳送SYN包後，由於被動方仍認為這條連線【五元組】還在等待ACK，但是卻收到了SYN，則被動方會回覆RST

• 造成主動建立連線的一方，由於收到了RST，則連線無法成功

所以，你看到了，TIME_WAIT的存在是很重要的，如果強制忽略TIME_WAIT，還是有很高的機率，造成資料粗亂，或者短暫性的連線失敗。

那麼，為什麼說，TIME_WAIT狀態會是持續2MSL（2倍的max segment lifetime）呢？這個時間可以通過修改核心引數調整嗎？第一，這個2MSL，是RFC 793裡定義的，參見RFC的截圖示紅的部分：

這個定義，更多的是一種保障（IP資料包裡的TTL，即資料最多存活的跳數，真正反應的才是資料在網路上的存活時間），確保最後丟失了ACK，被動關閉的一方再次重發FIN並等待回覆的ACK，一來一去兩個來回。核心裡，寫死了這個MSL的時間為：30秒（有讀者提醒，RFC裡建議的MSL其實是2分鐘，但是很多實現都是30秒），所以TIME_WAIT的即為1分鐘：

所以，再次回想一下前面的問題，如果一條連線，即使在四次握手關閉了，由於TIME_WAIT的存在，這個連線，在1分鐘之內，也無法再次被複用，那麼，如果你用一臺機器做壓測的客戶端，你一分鐘能傳送多少併發連線請求？如果這臺是一個負載均衡伺服器，一臺負載均衡伺服器，一分鐘可以有多少個連線同時訪問後端的伺服器呢？

TIME_WAIT很多，可怕嗎？

如果你通過 ss -tan state time-wait | wc -l 發現，系統中有很多TIME_WAIT，很多人都會緊張。多少算多呢？幾百幾千？如果是這個量級，其實真的沒必要緊張。第一，這個量級，因為TIME_WAIT所佔用的記憶體很少很少；因為記錄和尋找可用的local port所消耗的CPU也基本可以忽略。

會佔用記憶體嗎？當然！任何你可以看到的資料，核心裡都需要有相關的資料結構來儲存這個資料啊。一條Socket處於TIME_WAIT狀態，它也是一條“存在”的socket，核心裡也需要有保持它的資料：

1. 核心裡有儲存所有連線的一個hash table，這個hash table裡面既包含TIME_WAIT狀態的連線，也包含其他狀態的連線。主要用於有新的資料到來的時候，從這個hash table裡快速找到這條連線。不同的核心對這個hash table的大小設定不同，你可以通過dmesg命令去找到你的核心設定的大小：

   
   

2. 還有一個hash table用來儲存所有的bound ports，主要用於可以快速的找到一個可用的埠或者隨機埠：

   
   

由於核心需要儲存這些資料，必然，會佔用一定的記憶體。

會消耗CPU嗎？當然！每次找到一個隨機埠，還是需要遍歷一遍bound ports的吧，這必然需要一些CPU時間。

TIME_WAIT很多，既佔記憶體又消耗CPU，這也是為什麼很多人，看到TIME_WAIT很多，就蠢蠢欲動的想去幹掉他們。其實，如果你再進一步去研究，1萬條TIME_WAIT的連線，也就多消耗1M左右的記憶體，對現代的很多伺服器，已經不算什麼了。至於CPU，能減少它當然更好，但是不至於因為1萬多個hash item就擔憂。

如果，你真的想去調優，還是需要搞清楚別人的調優建議，以及調優引數背後的意義！

TIME_WAIT調優，你必須理解的幾個調優引數

在具體的圖例之前，我們還是先解析一下相關的幾個引數存在的意義。

1. net.ipv4.tcp_timestamps

   
   

   RFC 1323 在 TCP Reliability一節裡，引入了timestamp的TCP option，兩個4位元組的時間戳欄位，其中第一個4位元組欄位用來儲存傳送該資料包的時間，第二個4位元組欄位用來儲存最近一次接收對方傳送到資料的時間。有了這兩個時間欄位，也就有了後續優化的餘地。

   
   

   tcp_tw_reuse 和 tcp_tw_recycle就依賴這些時間欄位。

   
   

2. net.ipv4.tcp_tw_reuse

   
   

   字面意思，reuse TIME_WAIT狀態的連線。

   
   

   時刻記住一條socket連線，就是那個五元組，出現TIME_WAIT狀態的連線，一定出現在主動關閉連線的一方。所以，當主動關閉連線的一方，再次向對方發起連線請求的時候（例如，客戶端關閉連線，客戶端再次連線服務端，此時可以複用了；負載均衡伺服器，主動關閉後端的連線，當有新的HTTP請求，負載均衡伺服器再次連線後端伺服器，此時也可以複用），可以複用TIME_WAIT狀態的連線。

   
   

   通過字面解釋，以及例子說明，你看到了，tcp_tw_reuse應用的場景：某一方，需要不斷的通過“短連線”連線其他伺服器，總是自己先關閉連線(TIME_WAIT在自己這方)，關閉後又不斷的重新連線對方。

   
   

   那麼，當連線被複用了之後，延遲或者重發的資料包到達，新的連線怎麼判斷，到達的資料是屬於複用後的連線，還是複用前的連線呢？那就需要依賴前面提到的兩個時間欄位了。複用連線後，這條連線的時間被更新為當前的時間，當延遲的資料達到，延遲資料的時間是小於新連線的時間，所以，核心可以通過時間判斷出，延遲的資料可以安全的丟棄掉了。

   
   

   這個配置，依賴於連線雙方，同時對timestamps的支援。同時，這個配置，僅僅影響outbound連線，即做為客戶端的角色，連線服務端[connect(dest_ip, dest_port)]時複用TIME_WAIT的socket。

   
   

3. net.ipv4.tcp_tw_recycle

   
   

   字面意思，銷燬掉 TIME_WAIT。

   
   

   當開啟了這個配置後，核心會快速的回收處於TIME_WAIT狀態的socket連線。多快？不再是2MSL，而是一個RTO（retransmission timeout，資料包重傳的timeout時間）的時間，這個時間根據RTT動態計算出來，但是遠小於2MSL。

   
   

   有了這個配置，還是需要保障 丟失重傳或者延遲的資料包，不會被新的連線(注意，這裡不再是複用了，而是之前處於TIME_WAIT狀態的連線已經被destroy掉了，新的連線，剛好是和某一個被destroy掉的連線使用了相同的五元組而已)所錯誤的接收。在啟用該配置，當一個socket連線進入TIME_WAIT狀態後，核心裡會記錄包括該socket連線對應的五元組中的對方IP等在內的一些統計資料，當然也包括從該對方IP所接收到的最近的一次資料包時間。當有新的資料包到達，只要時間晚於核心記錄的這個時間，資料包都會被統統的丟掉。

   
   

   這個配置，依賴於連線雙方對timestamps的支援。同時，這個配置，主要影響到了inbound的連線（對outbound的連線也有影響，但是不是複用），即做為服務端角色，客戶端連進來，服務端主動關閉了連線，TIME_WAIT狀態的socket處於服務端，服務端快速的回收該狀態的連線。

由此，如果客戶端處於NAT的網路(多個客戶端，同一個IP出口的網路環境)，如果配置了tw_recycle，就可能在一個RTO的時間內，只能有一個客戶端和自己連線成功(不同的客戶端發包的時間不一致，造成服務端直接把資料包丟棄掉)。

我儘量嘗試用文字解釋清楚，但是，來點案例和圖示，應該有助於我們徹底理解。

我們來看這樣一個網路情況：

1. 客戶端IP地址為：180.172.35.150，我們可以認為是瀏覽器

2. 負載均衡有兩個IP，外網IP地址為 115.29.253.156，內網地址為10.162.74.10；外網地址監聽80埠

3. 負載均衡背後有兩臺Web伺服器，一臺IP地址為 10.162.74.43，監聽80埠；另一臺為 10.162.74.44，監聽 80 埠

4. Web伺服器會連線資料伺服器，IP地址為 10.162.74.45，監聽 3306 埠

這種簡單的架構下，我們來看看，在不同的情況下，我們今天談論的tw_reuse/tw_recycle對網路連線的影響。

先做個假定：

1. 客戶端通過HTTP/1.1連線負載均衡，也就是說，HTTP協議投Connection為keep-alive，所以我們假定，客戶端 對 負載均衡伺服器 的socket連線，客戶端會斷開連線，所以，TIME_WAIT出現在客戶端

2. Web伺服器和MySQL伺服器的連線，我們假定，Web伺服器上的程式在連線結束的時候，呼叫close操作關閉socket資源連線，所以，TIME_WAIT出現在 Web 伺服器端。

那麼，在這種假定下：

1. Web伺服器上，肯定可以配置開啟的配置：tcp_tw_reuse；如果Web伺服器有很多連向DB伺服器的連線，可以保證socket連線的複用。

2. 那麼，負載均衡伺服器和Web伺服器，誰先關閉連線，則決定了我們怎麼配置tcp_tw_reuse/tcp_tw_recycle了

場景一：負載均衡伺服器首先關閉連線 

在這種情況下，因為負載均衡伺服器對Web伺服器的連線，TIME_WAIT大都出現在負載均衡伺服器上。

在負載均衡伺服器上的配置：

• net.ipv4.tcp_tw_reuse = 1 //儘量複用連線

• net.ipv4.tcp_tw_recycle = 0 //不能保證客戶端不在NAT的網路啊

在Web伺服器上的配置為：

• net.ipv4.tcp_tw_reuse = 1 //這個配置主要影響的是Web伺服器到DB伺服器的連線複用

• net.ipv4.tcp_tw_recycle： 設定成1和0都沒有任何意義。想一想，在負載均衡和它的連線中，它是服務端，但是TIME_WAIT出現在負載均衡伺服器上；它和DB的連線，它是客戶端，recycle對它並沒有什麼影響，關鍵是reuse

場景二：Web伺服器首先關閉來自負載均衡伺服器的連線

在這種情況下，Web伺服器變成TIME_WAIT的重災區。負載均衡對Web伺服器的連線，由Web伺服器首先關閉連線，TIME_WAIT出現在Web伺服器上；Web伺服器對DB伺服器的連線，由Web伺服器關閉連線，TIME_WAIT也出現在它身上，此時，負載均衡伺服器上的配置：

• net.ipv4.tcp_tw_reuse：0 或者 1 都行，都沒有實際意義

• net.ipv4.tcp_tw_recycle=0 //一定是關閉recycle

在Web伺服器上的配置：

• net.ipv4.tcp_tw_reuse = 1 //這個配置主要影響的是Web伺服器到DB伺服器的連線複用

• net.ipv4.tcp_tw_recycle=1 //由於在負載均衡和Web伺服器之間並沒有NAT的網路，可以考慮開啟recycle，加速由於負載均衡和Web伺服器之間的連線造成的大量TIME_WAIT

回答幾個大家提到的幾個問題

1. 請問我們所說連線池可以複用連線，是不是意味著，需要等到上個連線time wait結束後才能再次使用?

所謂連線池複用，複用的一定是活躍的連線，所謂活躍，第一表明連線池裡的連線都是ESTABLISHED的，第二，連線池做為上層應用，會有定時的心跳去保持連線的活躍性。既然連線都是活躍的，那就不存在有TIME_WAIT的概念了，在上篇裡也有提到，TIME_WAIT是在主動關閉連線的一方，在關閉連線後才進入的狀態。既然已經關閉了，那麼這條連線肯定已經不在連線池裡面了，即被連線池釋放了。

2. 想請問下，作為負載均衡的機器隨機埠使用完的情況下大量time_wait，不調整你文字裡說的那三個引數，有其他的更好的方案嗎？

第一，隨機埠使用完，你可以通過調整/etc/sysctl.conf下的net.ipv4.ip_local_port_range配置，至少修改成 net.ipv4.ip_local_port_range=1024 65535，保證你的負載均衡伺服器至少可以使用6萬個隨機埠，也即可以有6萬的反向代理到後端的連線，可以支援每秒1000的併發（想一想，因為TIME_WAIT狀態會持續1分鐘後消失，所以一分鐘最多有6萬，每秒1000）；如果這麼多埠都使用完了，也證明你應該加伺服器了，或者，你的負載均衡伺服器需要配置多個IP地址，或者，你的後端伺服器需要監聽更多的埠和配置更多的IP（想一下socket的五元組）

第二，大量的TIME_WAIT，多大量？如果是幾千個，其實不用擔心，因為這個記憶體和CPU的消耗有一些，但是是可以忽略的。

第三，如果真的量很大，上萬上萬的那種，可以考慮，讓後端的伺服器主動關閉連線，如果後端伺服器沒有外網的連線只有負載均衡伺服器的連線（主要是沒有NAT網路的連線），可以在後端伺服器上配置tw_recycle，然後同時，在負載均衡伺服器上，配置tw_reuse。

3. 如果想深入的學習一下網路方面的知識，有什麼推薦的？

學習網路比學一門程式語言“難”很多。所謂難，其實，是因為需要花很多的時間投入。我自己不算精通，只能說入門和理解。基本書可以推薦：《TCP/IP 協議詳解》，必讀；《TCP/IP高效程式設計：改善網路程式的44個技巧》，必讀；《Unix環境高階程式設計》，必讀；《Unix網路程式設計：卷一》，我只讀過卷一；另外，還需要熟悉一下網路工具，tcpdump以及wireshark，我的notes裡有一個一站式學習Wireshark：https://github.com/dafang/notebook/issues/114，也值得一讀。有了這些積累，可能就是一些實踐以及碎片化的學習和積累了。

寫在最後

這篇文章我斷斷續續寫了兩天，內容找了多個地方去驗證，包括看到Vincent Bernat的一篇文章以及Vincent在多個地方和別人的討論。期間，我也花了一些時間和Vincent探討了幾個我沒在tcp原始碼裡翻找到的有疑問的地方。

我力求比散佈在網上的文章做到準確並儘量整理的清晰一些。但是，也難免會

有疏漏或者有錯誤的地方，高手看到可以隨時指正，並和我討論，大家一起研究！