解讀TIME_WAIT--你在網上看到的大多數帖子可能都是錯誤的

因爲TCP協議整個機制也很是複雜我只能儘量的在某一條線上來講，不可能面面俱到，若是有疏漏或者對於內容有異議能夠留言。謝謝你們。

查看服務器上各個狀態的統計數量：

netstat -ant | awk '/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}'

單獨查看TIME_WAIT，ss -nat | grep TIME-WAIT

ss命令中的TIME WAIT的寫法和netstat中有所不一樣

TIME_WAIT的做用

主動斷開的一方的TCP鏈接會在這個狀態下保持2MSL，其做用就2個：

• 確保對方收到本身發送的最後一個ACK（由於對方發送了FIN），若是對方沒有收到本身發送的ACK一定會從新發送FIN，這樣保證4次斷開的完整性。由於MSL是最大報文生存時間，若是在1個MSL時間內本身發送的ACK對方沒有收到那就註定收不到了，並且對方確定還會發送FIN，那麼一個FIN發送過來的最長時間也是1個MSL，因此這裏要等待2MSL。

• 另一個緣由就是避免延遲的IP報文，在頻繁短鏈接的場景下客戶端一般會對同一個IP和端口在短期內發起屢次鏈接，而客戶端使用的端口是本身系統隨機分配的高位端口，有必定機率發生上一個socket四元組和下一個socket四元組同樣，若是這時候一個本來屬於上一個socket四元組的被延遲的IP報文送達，那麼這將發送數據混亂的狀態，因此爲了不這種狀況就利用MSL這個報文最大生存時長機制讓殘餘的IP報文在網絡中消失。這時候一樣的四元組又能夠被使用了。

另外你無須擔憂這個遲到的IP報文是有用的，由於TCP是可靠鏈接，它有重傳機制，因此這個遲到的IP報文消失不會影響以前通訊的數據完整性。哪怕這個報文是在2MSL期間到達也將會被拋棄。

處於該狀態的socket何時能夠再次使用：

• 2MSL以後

• 若是處於2MS期間，重用鏈接那麼要保證新鏈接的TCP的Seq也就是序列號要比以前的大

• 若是處於2MS期間，重用的鏈接要保證後續的時間戳要比以前的鏈接的時間戳更晚

只有知足上面的條件纔不會在發生新鏈接上出現老鏈接的延遲的IP分組，知足第一個條件則不會出現延遲的IP分組，若是知足後面的條件那麼延遲的IP分組即便出如今新鏈接上也會被直接丟棄進而不會影響現有通訊數據。

使用Wireshark抓包在TCP中顯示的Seq都是從0開始的，這是這個軟件作了處理，以下圖：

要想看真正的序列號須要作一個配置：

Wireshark-->Preferences-->Protocols-->Tcp

點擊肯定你就能夠看到真實的Seq

2MSL到底有多長呢？這個不必定，1分鐘、2分鐘或者4分鐘，還有的30秒。不一樣的發行版可能會不一樣。在Centos 7.6.1810 的3.10內核版本上是60秒。v3.10/source/include/net/tcp.h

TIME_WAIT會影響什麼

端口：可是這是對於通訊過程當中扮演客戶端角色的一端來講，由於客戶端使用隨機端口來訪問服務器，當它主動斷開的時候會出現這個狀態，好比第一次系統給它分配了一個51000的隨機端口訪問服務器，而後客戶端主動斷開了，在2MSL期間，該端口就處於TIME_WAIT狀態，若是它再次訪問相同的服務器，那麼系統會爲它再次分配一個隨機端口，若是51000端口還處於TIME_WAIT狀態，那麼這個隨機端口就確定不是51000，若是51000端口不處於TIME_WAIT狀態，那麼這個隨機端口就有多是51000。因此這個狀態在必定期間內對於客戶端角色來說會影響併發量，大量這個TIME_WAIT就致使可用隨機端口不斷減小。

內存：這個量會很小，無需擔憂，哪怕是上萬的TIME_WAIT。

文件描述符：可是處於TIME_WAIT狀態的套接字實際上是已經關閉了文件描述符，也就是說這個狀態並不佔用文件描述符這也就是意味着該狀態不會對應一個打開的文件。

如何解決

網上不少人給出的答案是調整內核參數好比下面的參數，可是這些答案有不少誤區，在不一樣場景下並不必定適用，因此這裏先對參數作一下澄清：

net.ipv4.tcp_tw_reuse = 1

表示開啓重用。容許將一個處於TIME-WAIT狀態的端口從新用於新的TCP鏈接，默認爲0，表示關閉，其防止重複報文的原理也是時間戳，具體看後面。

net.ipv4.tcp_tw_recycle = 1

表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，意思就是系統會保存最近一次該socket鏈接上的傳輸報文（包括數據或者僅僅是ACK報文）的時間戳，當相同四元組socket過來的報文的時間戳小於緩存下來的時間戳則丟棄該數據包，並回收這個socket，默認爲0，表示關閉。開啓這個功能風險有點大，NAT環境可能致使DROP掉SYN包（回覆RST），在NAT場景下不要使用。須要注意在Linux內核4.10版本之後該參數就已經被移除了。

net.ipv4.tcp_fin_timeout = 60

這個時間不是修改2MSL的時長，主動關閉鏈接的一方接收到ACK以後會進入，FIN_WAIT-2狀態，而後等待被動關閉一方發送FIN，這個時間是設置主動關閉的一方等待對方發送FIN的最長時長，默認是60秒。在這個狀態下端口是不可能被重用的，文件描述符和內存也不會被釋放，由於這個階段被動關閉的一方有可能還有數據要發送，由於對端處於CLOSE_WAIT狀態，也就是等待上層應用程序。關於這個的真實含義我但願你們清楚，並且不要調整的過小固然太大也不行，至少在3.10內核版本上這個參數不是調整的TIME_WAIT時長。個人資料查詢3.10內核變量定義和RedHat官方解釋。至於到底如何修改TIME_WAIT的時長，目前沒找到能夠經過命令或者配置的形式去修改的方式。

net.ipv4.ip_local_port_range = 32768 60999

表示用於外連使用的隨機高位端口範圍，也就是做爲客戶端鏈接其餘服務的時候系統從這個範圍隨機取出一個端口來做爲源端口使用來去鏈接對端服務器，這個範圍也就決定了最多主動能同時創建多少個外連。

net.ipv4.tcp_max_tw_buckets = 6000

同時保持TIME_WAIT套接字的最大個數，超過這個數字那麼該TIME_WAIT套接字將馬上被釋放並在/var/log/message日誌中打印警告信息（TCP: time wait bucket table overflow）。這個過多主要是消耗內存，單個TIME_WAIT佔用內存很是小，可是多了就很差了，這個主要看內存以及你的服務器是否直接對外。

使用net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle 的前提是開啓時間戳net.ipv4.tcp_timestamps = 1不過這一項默認是開啓的。

做爲7層的代理的Nginx

在這種場景下首先要搞清楚哪一側產生TIME_WAIT最多。爲何要看這個，咱們知道TIME_WAIT是主動關閉一方具備的狀態，可是Nginx做爲7層代理對外它是服務器而對內它是客戶端（例如，相對於後端的其餘Web應用好比Tomcat）。

對外側（被動鏈接）

ss -nat | grep "TIME-WAIT" | awk '{print $4}' | egrep -w "192.168.71.101:80|192.168.71.101:443" | wc -l

做爲代理服務器對外提供的端口就是80和443，因此咱們針對"TIME-WAIT"狀態來進行過濾本地地址和端口並且經過-w進行嚴格匹配2個條件就是"192.168.71.101:80|192.168.71.101:443"，這樣就統計出Nginx做爲服務器一方的外連TIME-WAIT的數量。

看一下抓包狀況（下圖是測試環境的包，上圖是生產環境的統計）

因爲在做爲Web代理角色運行的時候爲了提升HTTP性能因此Nginx一般會開啓Keep-alive來讓客戶端對TCP鏈接進行復用，若是客戶端在Keep-alive超時內沒有進行通訊那麼當觸發超時時服務器就會主動斷開鏈接，也就是上圖紅色箭頭的地方，另一個狀況就是Nginx設置對Keep-alive最大請求數量，意思是改連接在複用的時候能夠發送多少次請求，若是到達這個最大請求次數也會斷開鏈接，但不管怎麼說這種狀況是服務器主動斷開因此TIME_WAIT則會出如今服務器上。

對於這種狀況的TIME_WAIT經過修改net.ipv4.tcp_tw_reuse沒法優化，由於服務器工做在80或者443端口，不存在重複使用或者快速回收的前提。開啓net.ipv4.tcp_tw_recycle這個功能卻是還有點意義。

對內側（主動鏈接）

ss -nat | grep "TIME-WAIT" | awk '{print $4}' | egrep -w -v "192.168.71.101:80|192.168.71.101:443" | wc -l

咱們增長一個-v參數來取反，這樣就獲取了本地地址中不是80和443端口的TIME-WAIT狀態數量，那麼這個數量就是Nginx做爲客戶端進行內連後端服務器所產生的。

很明顯對內側的TIME_WAIT明顯比對外側要高，這就是由於Nginx反向代理到後端使用隨機端口來主動鏈接後端服務的固定端口，在短鏈接的狀況下（一般是短鏈接），Nginx做爲主動發起鏈接的一方會主動斷開，因此在業務繁忙的Nginx代理服務器上會看到大量的對內側的TIME_WAIT。

基於這種狀況能夠採用net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle優化方式，由於高位隨機端口具有複用的可能。固然至於舊IP分組影響新鏈接的狀況在前面已經說過了其依靠時間戳來作丟棄。具體機制請看後面，如今你只須要知道是依靠時間戳來規避這個問題。

另外net.ipv4.ip_local_port_range參數能夠設置一個更大的範圍，好比net.ipv4.ip_local_port_range = 2048 65000這就意味着你的可用隨機端口多了，端口少咱們更多關注與端口複用，端口多實際上是不是複用的意義就不是那麼大，固然這還得取決於併發量，固然這裏也不要死磕，若是你的併發量是100萬，你怎麼可能期望1臺Nginx來抗住流量呢，顯然須要構建Nginx集羣。

再有net.ipv4.tcp_max_tw_buckets這個參數當主機對外的時候須要調整，若是徹底是內網提供服務那麼這個值無需關心，它根據系統內存動態生成的，固然你能夠修改。在對外的時候主要是簡單防止DoS攻擊。

net.ipv4.tcp_fin_timeout這個值保持默認60秒或者調整成30秒均可以，主要避免對端上層應用死掉了沒法進行正常發送fin，進而長期處在CLOSE_WAIT階段，這樣你本身這段的服務器就被拖住了。

總結

對於TIME_WAIT不要死磕，存在即合理，明明是一個很正常的且保證可靠通訊的機制你非要抑制它的產生或者讓它快速消失。任何的調整都是雙刃劍，就像2臺Nginx組成的集羣去抗100萬併發的流量，你非要去優化TIME_WAIT，你爲何不想一想會不會是你Nginx集羣規模過小了呢？

做爲不會主動進行外連的服務器來講對於TIME_WAIT除了消耗一點內存和CPU資源以外你沒必要過多關心這個狀態。

針對Nginx作反代的場景使用reuse優化一下，另外調大一下高位端口範圍，fin_timeout能夠設置小一點，至於net.ipv4.tcp_max_tw_buckets保存默認就能夠，另外對於net.ipv4.tcp_tw_recycle則放棄使用吧，比較從Linux 4.10之後這個參數也被棄用了參見kernel.org。

2MSL和resue或者recycle會不會有衝突

這個問題在TCP上有一個術語縮寫是PAWS，全名爲PROTECT AGAINST WRAPPED SEQUENCE NUMBERS，也就是防止TCP的Seq序列號反轉的機制。

咱們上面介紹了2MSL的做用以及減小TIME_WAIT經常使用措施，可是你想過沒有重用TIME_WAIT狀態的端口以及快速回收會不會引起收到該相同4元組以前的重複IP報文呢？很顯然是有可能的，那麼這裏就談談如何規避。一般2種辦法：

• TCP序列號，也就是Seq位置的數字

• 時間戳，因此這也是爲何在開啓resue和recycle的時候要求開啓時間戳功能。

TCP頭中的序列號位有長度限制（32位），其最大值爲2的32次方個，這就意味着它是循環使用的，也很容易在短期內完成一個循環（序列號反轉），在1Gbps的網絡裏17秒就能夠完成一個循環，因此單純的經過檢查序列號不能徹底實現阻擋老IP分組的數據，由於高速網絡中這個循環完成的太快，而一個IP分組的最長TTL是2MSL，一般是1分鐘，因此最主要仍是靠時間戳。

前面咱們也幾回提到時間戳，好比在reuse和recycle的時候提到會對比時間戳，若是收到的報文時間戳小於最近鏈接的時間戳就會被丟棄，那麼咱們如何獲取這個時間戳呢？咱們先看看它長什麼樣子：

TSval：發送端時間戳

TSecr：對端回顯時間戳

咱們看第三行，以下圖：

這一行是客戶端回覆ACK給服務器完成三次握手的最後一個階段，TSval就是客戶端的時間戳這個和第一行同樣這是由於速度快尚未走完一個時間週期，這一行的TSecr是434971890，這個就是第二行服務器回覆SYN時候給客戶端發來的服務器的時間戳，這個就叫作回顯時間戳。

這個時間戳是一個相對時間戳而不是咱們一般理解的絕對時間戳（自1970年1月1日的那種形式），並且你不能把它當作時間來用，在RFC1323中也提到對報文的接收者來說時間戳能夠看作另一種高階序列號。

這裏就會有一個問題，2個時間戳，一個是本身的，一個是對端的，到底用哪一個時間戳來進行比較來肯定是否丟棄報文呢？答案是TSval，也就是發送端的時間戳。這樣很容易理解，做爲主動斷開的一方要丟棄的是對端傳遞過來的重複報文，顯然須要用對端的時間戳來判斷不可能用本身的時間戳。並且從上圖能夠看到本身的時間戳和對端的時間戳明顯有很大差距，也就是說這個時間戳是通訊雙方本身生成的。這個時間戳就放在TCP報文的options選項中，以下圖：

能夠看到它是options，既然是選項那麼就不是必須的，因此這也就是爲何當開啓reuse和recycle的時候要求開啓這個，由於不開啓則沒法識別重複的IP分組。

簡單原理就是：保存該socket上一次報文的TSval時間戳，若是該socket的4元組被重複利用或者快速回收，那麼假如收到了以前鏈接重複的報文，則比較該報文的時間戳是否是比保存的TSval小，若是小則丟棄。我這裏只是簡單來講基於時間戳的機制來放置重複報文，整個的PAWS還有其餘的原則，具體請查看RFC1323。

另外，因爲時間戳也是經過一串數字來表示且TCP頭的時間戳長度也是32位（每一個都是4byes），因此它也會出現循環，時間跳動頻率就決定了翻轉週期，那這個頻率是多少呢，RFC1312中規定建議在1ms到1s之間，這個時間間隔不一樣系統可能不同，不過這裏內核選項和用戶選項的區別：

內核選項，在Linux中cat /boot/config-$(uname -r) | grep -w "CONFIG_HZ"查看，

Jiffies是從計算機啓動到如今總共發生多少節拍數，節拍數叫作Tick，Tick是HZ的倒數，若是上所示HZ是1000，每秒發生1000次中斷，也就是1毫秒發生一次中斷，對應Tick是1ms，也就是每1毫秒Jiffies就加1。當重啓電腦的時候Jiffies重置。

用戶選項，因爲用戶空間程序不能直接訪問，因此內核還提供了一個USER_HZ來讓用戶空間程序使用，固定爲100，百分之一秒，也就是10毫秒。如何查看呢？getconf CLK_TCK命令：

咱們從網卡上看也是這個值cat /proc/sys/net/ipv4/neigh/ens33/locktime

若是這個間隔是1毫秒，那麼時間戳反轉一次將是24.8天；若是是10毫秒就是248天，依次類推，但最大不能超過1秒。

---

查詢內核參數及含義

在線查詢內核代碼