大家好，我是小林。

之前有位讀者面字節(jié)被問到兩個很經(jīng)典的 TCP 問題：

第一個問題：服務端大量處于 TIME_WAIT 狀態(tài)連接的原因。

第二個問題：服務端大量處于 CLOSE_WAIT 狀態(tài)連接的原因。

這兩個問題在面試中很常問，主要也是因為在工作中也很常遇到這個問題。

這次，我們就來聊聊這兩個問題。

服務端出現(xiàn)大量 TIME_WAIT 狀態(tài)的原因有哪些？

我們先來看一下 TCP 四次揮手的流程吧，看看 TIME_WAIT 狀態(tài)發(fā)生在哪一個階段。

下面這個圖，是由「客戶端」作為「主動關(guān)閉方」的 TCP 四次揮手的流程。

TCP 四次揮手的流程

從上面我們可以知道，TIME_WAIT 狀態(tài)是「主動關(guān)閉連接方」才會出現(xiàn)的狀態(tài)。而且 TIME_WAIT 狀態(tài)會持續(xù) 2MSL 時間才會進入到 close 狀態(tài)。在 Linux 上 2MSL 的時長是 60 秒，也就是說停留在 TIME_WAIT 的時間為固定的 60 秒。

為什么需要 TIME_WAIT 狀態(tài)？（老八股文了，幫大家復習一波）主要有兩個原因：

• 保證「被動關(guān)閉連接」的一方，能被正確的關(guān)閉。TCP 協(xié)議在關(guān)閉連接的四次揮手中，在主動關(guān)閉方發(fā)送的最后一個 ACK 報文，有可能丟失，這時被動方會重新發(fā) FIN 報文, 如果這時主動方處于 CLOSE 狀態(tài) ，就會響應 RST 報文而不是 ACK 報文。所以主動方要處于 TIME_WAIT 狀態(tài)，而不能是 CLOSE。
• 防止歷史連接中的數(shù)據(jù)，被后面相同四元組的連接錯誤的接收。TCP 報文可能由于路由器異常而 “迷路”，在迷途期間，TCP 發(fā)送端可能因確認超時而重發(fā)這個報文，迷途的報文在路由器修復后也會被送到最終目的地，這個原來的迷途報文就稱為 lost duplicate。在關(guān)閉一個 TCP 連接后，馬上又重新建立起一個相同的 IP 地址和端口之間的 TCP 連接，后一個連接被稱為前一個連接的化身，那么有可能出現(xiàn)這種情況，前一個連接的迷途重復報文在前一個連接終止后出現(xiàn)，從而被誤解成從屬于新的化身。為了避免這個情 況， TIME_WAIT 狀態(tài)需要持續(xù) 2MSL，因為這樣就可以保證當成功建立一個 TCP 連接的時候，來自連接先前化身的重復報文已經(jīng)在網(wǎng)絡中消逝。

很多人誤解以為只有客戶端才會有 TIME_WAIT 狀態(tài)，這是不對的。TCP 是全雙工協(xié)議，哪一方都可以先關(guān)閉連接，所以哪一方都可能會有 TIME_WAIT 狀態(tài)。

總之記住，誰先關(guān)閉連接的，它就是主動關(guān)閉方，那么 TIME_WAIT 就會出現(xiàn)在主動關(guān)閉方。

什么場景下服務端會主動斷開連接呢？

如果服務端出現(xiàn)大量的 TIME_WAIT 狀態(tài)的 TCP 連接，就是說明服務端主動斷開了很多 TCP 連接。

問題來了，什么場景下服務端會主動斷開連接呢？

• 第一個場景：HTTP 沒有使用長連接
• 第二個場景：HTTP 長連接超時
• 第三個場景：HTTP 長連接的請求數(shù)量達到上限

接下來，分別介紹下。

第一個場景：HTTP 沒有使用長連接

我們先來看看 HTTP 長連接（Keep-Alive）機制是怎么開啟的。

在 HTTP/1.0 中默認是關(guān)閉的，如果瀏覽器要開啟 Keep-Alive，它必須在請求的 header 中添加：

Connection: Keep-Alive

然后當服務器收到請求，作出回應的時候，它也被添加到響應中 header 里：

Connection: Keep-Alive

這樣做，TCP 連接就不會中斷，而是保持連接。當客戶端發(fā)送另一個請求時，它會使用同一個 TCP 連接。這一直繼續(xù)到客戶端或服務器端提出斷開連接。

從 HTTP/1.1 開始， 就默認是開啟了 Keep-Alive，現(xiàn)在大多數(shù)瀏覽器都默認是使用 HTTP/1.1，所以 Keep-Alive 都是默認打開的。一旦客戶端和服務端達成協(xié)議，那么長連接就建立好了。

如果要關(guān)閉 HTTP Keep-Alive，需要在 HTTP 請求或者響應的 header 里添加 Connection:close 信息，也就是說，只要客戶端和服務端任意一方的 HTTP header 中有 Connection:close 信息，那么就無法使用 HTTP 長連接的機制。

關(guān)閉 HTTP 長連接機制后，每次請求都要經(jīng)歷這樣的過程：建立 TCP -> 請求資源 -> 響應資源 -> 釋放連接，那么此方式就是 HTTP 短連接，如下圖：

HTTP 短連接

在前面我們知道，只要任意一方的 HTTP header 中有 Connection:close 信息，就無法使用 HTTP 長連接機制，這樣在完成一次 HTTP 請求/處理后，就會關(guān)閉連接。

問題來了，這時候是客戶端還是服務端主動關(guān)閉連接呢？

在 RFC 文檔中，并沒有明確由誰來關(guān)閉連接，請求和響應的雙方都可以主動關(guān)閉 TCP 連接。

不過，根據(jù)大多數(shù) Web 服務的實現(xiàn)，不管哪一方禁用了 HTTP Keep-Alive，都是由服務端主動關(guān)閉連接，那么此時服務端上就會出現(xiàn) TIME_WAIT 狀態(tài)的連接。

客戶端禁用了 HTTP Keep-Alive，服務端開啟 HTTP Keep-Alive，誰是主動關(guān)閉方？

當客戶端禁用了 HTTP Keep-Alive，這時候 HTTP 請求的 header 就會有 Connection:close 信息，這時服務端在發(fā)完 HTTP 響應后，就會主動關(guān)閉連接。

為什么要這么設計呢？HTTP 是請求-響應模型，發(fā)起方一直是客戶端，HTTP Keep-Alive 的初衷是為客戶端后續(xù)的請求重用連接，如果我們在某次 HTTP 請求-響應模型中，請求的 header 定義了 connection：close 信息，那不再重用這個連接的時機就只有在服務端了，所以我們在 HTTP 請求-響應這個周期的「末端」關(guān)閉連接是合理的。

客戶端開啟了 HTTP Keep-Alive，服務端禁用了 HTTP Keep-Alive，誰是主動關(guān)閉方？

當客戶端開啟了 HTTP Keep-Alive，而服務端禁用了 HTTP Keep-Alive，這時服務端在發(fā)完 HTTP 響應后，服務端也會主動關(guān)閉連接。

為什么要這么設計呢？在服務端主動關(guān)閉連接的情況下，只要調(diào)用一次 close() 就可以釋放連接，剩下的工作由內(nèi)核 TCP 棧直接進行了處理，整個過程只有一次 syscall；如果是要求 客戶端關(guān)閉，則服務端在寫完最后一個 response 之后需要把這個 socket 放入 readable 隊列，調(diào)用 select / epoll 去等待事件；然后調(diào)用一次 read() 才能知道連接已經(jīng)被關(guān)閉，這其中是兩次 syscall，多一次用戶態(tài)程序被激活執(zhí)行，而且 socket 保持時間也會更長。

因此，當服務端出現(xiàn)大量的 TIME_WAIT 狀態(tài)連接的時候，可以排查下是否客戶端和服務端都開啟了 HTTP Keep-Alive，因為任意一方?jīng)]有開啟  HTTP Keep-Alive，都會導致服務端在處理完一個 HTTP 請求后，就主動關(guān)閉連接，此時服務端上就會出現(xiàn)大量的 TIME_WAIT 狀態(tài)的連接。

針對這個場景下，解決的方式也很簡單，讓客戶端和服務端都開啟 HTTP Keep-Alive 機制。

第二個場景：HTTP 長連接超時

HTTP 長連接的特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。

HTTP 長連接可以在同一個 TCP 連接上接收和發(fā)送多個 HTTP 請求/應答，避免了連接建立和釋放的開銷。

可能有的同學會問，如果使用了 HTTP 長連接，如果客戶端完成一個 HTTP 請求后，就不再發(fā)起新的請求，此時這個 TCP 連接一直占用著不是挺浪費資源的嗎？

對沒錯，所以為了避免資源浪費的情況，web 服務軟件一般都會提供一個參數(shù)，用來指定 HTTP 長連接的超時時間，比如 nginx 提供的 keepalive_timeout 參數(shù)。

假設設置了 HTTP 長連接的超時時間是 60 秒，nginx 就會啟動一個「定時器」，如果客戶端在完后一個 HTTP 請求后，在 60 秒內(nèi)都沒有再發(fā)起新的請求，定時器的時間一到，nginx 就會觸發(fā)回調(diào)函數(shù)來關(guān)閉該連接，那么此時服務端上就會出現(xiàn) TIME_WAIT 狀態(tài)的連接。

HTTP 長連接超時

當服務端出現(xiàn)大量 TIME_WAIT 狀態(tài)的連接時，如果現(xiàn)象是有大量的客戶端建立完 TCP 連接后，很長一段時間沒有發(fā)送數(shù)據(jù)，那么大概率就是因為 HTTP 長連接超時，導致服務端主動關(guān)閉連接，產(chǎn)生大量處于 TIME_WAIT 狀態(tài)的連接。

可以往網(wǎng)絡問題的方向排查，比如是否是因為網(wǎng)絡問題，導致客戶端發(fā)送的數(shù)據(jù)一直沒有被服務端接收到，以至于 HTTP 長連接超時。

第三個場景：HTTP 長連接的請求數(shù)量達到上限

Web 服務端通常會有個參數(shù)，來定義一條 HTTP 長連接上最大能處理的請求數(shù)量，當超過最大限制時，就會主動關(guān)閉連接。

比如 nginx 的 keepalive_requests 這個參數(shù)，這個參數(shù)是指一個 HTTP 長連接建立之后，nginx 就會為這個連接設置一個計數(shù)器，記錄這個 HTTP 長連接上已經(jīng)接收并處理的客戶端請求的數(shù)量。如果達到這個參數(shù)設置的最大值時，則 nginx 會主動關(guān)閉這個長連接，那么此時服務端上就會出現(xiàn) TIME_WAIT 狀態(tài)的連接。

keepalive_requests 參數(shù)的默認值是 100 ，意味著每個 HTTP 長連接最多只能跑 100  次請求，這個參數(shù)往往被大多數(shù)人忽略，因為當 QPS (每秒請求數(shù)) 不是很高時，默認值 100 湊合夠用。

但是，對于一些 QPS 比較高的場景，比如超過 10000 QPS，甚至達到 30000 , 50000 甚至更高，如果 keepalive_requests 參數(shù)值是 100，這時候就 nginx 就會很頻繁地關(guān)閉連接，那么此時服務端上就會出大量的 TIME_WAIT 狀態(tài)。

針對這個場景下，解決的方式也很簡單，調(diào)大 nginx 的 keepalive_requests 參數(shù)就行。

TIME_WAIT 狀態(tài)過多有什么危害？

過多的 TIME-WAIT 狀態(tài)主要的危害有兩種：

第一是占用系統(tǒng)資源，比如文件描述符、內(nèi)存資源、CPU 資源等；

第二是占用端口資源，端口資源也是有限的，一般可以開啟的端口為32768～61000，也可以通過 net.ipv4.ip_local_port_range參數(shù)指定范圍。

客戶端和服務端 TIME_WAIT 過多，造成的影響是不同的。

如果客戶端（主動發(fā)起關(guān)閉連接方）的 TIME_WAIT 狀態(tài)過多，占滿了所有端口資源，那么就無法對「目的 IP+ 目的 PORT」都一樣的服務端發(fā)起連接了，但是被使用的端口，還是可以繼續(xù)對另外一個服務端發(fā)起連接的。具體可以看我這篇文章：客戶端的端口可以重復使用嗎？

因此，客戶端（發(fā)起連接方）都是和「目的 IP+ 目的 PORT 」都一樣的服務端建立連接的話，當客戶端的 TIME_WAIT 狀態(tài)連接過多的話，就會受端口資源限制，如果占滿了所有端口資源，那么就無法再跟「目的 IP+ 目的 PORT」都一樣的服務端建立連接了。

不過，即使是在這種場景下，只要連接的是不同的服務端，端口是可以重復使用的，所以客戶端還是可以向其他服務端發(fā)起連接的，這是因為內(nèi)核在定位一個連接的時候，是通過四元組（源IP、源端口、目的IP、目的端口）信息來定位的，并不會因為客戶端的端口一樣，而導致連接沖突。

如果服務端（主動發(fā)起關(guān)閉連接方）的 TIME_WAIT 狀態(tài)過多，并不會導致端口資源受限，因為服務端只監(jiān)聽一個端口，而且由于一個四元組唯一確定一個 TCP 連接，因此理論上服務端可以建立很多連接，但是 TCP 連接過多，會占用系統(tǒng)資源，比如文件描述符、內(nèi)存資源、CPU 資源等。

如何優(yōu)化 TIME_WAIT 狀態(tài)？

這里給出優(yōu)化 TIME-WAIT 的幾個方式，都是有利有弊：

• 打開 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_timestamps 選項；
• net.ipv4.tcp_max_tw_buckets
• 程序中使用 SO_LINGER ，應用強制使用 RST 關(guān)閉。

方式一：net.ipv4.tcp_tw_reuse 和 tcp_timestamps

開啟 tcp_tw_reuse，則可以復用處于 TIME_WAIT 的 socket 為新的連接所用。

有一點需要注意的是，tcp_tw_reuse 功能只能用客戶端（連接發(fā)起方），因為開啟了該功能，在調(diào)用 connect() 函數(shù)時，內(nèi)核會隨機找一個 time_wait 狀態(tài)超過 1 秒的連接給新的連接復用。

net.ipv4.tcp_tw_reuse = 1

使用這個選項，還有一個前提，需要打開對 TCP 時間戳的支持，即

net.ipv4.tcp_timestamps=1（默認即為 1）

這個時間戳的字段是在 TCP 頭部的「選項」里，它由一共 8 個字節(jié)表示時間戳，其中第一個 4 字節(jié)字段用來保存發(fā)送該數(shù)據(jù)包的時間，第二個 4 字節(jié)字段用來保存最近一次接收對方發(fā)送到達數(shù)據(jù)的時間。

由于引入了時間戳，可以使得重復的數(shù)據(jù)包會因為時間戳過期被自然丟棄，因此 TIME_WAIT 狀態(tài)才可以被復用。

方式二：net.ipv4.tcp_max_tw_buckets

這個值默認為 18000，當系統(tǒng)中處于 TIME_WAIT 的連接一旦超過這個值時，系統(tǒng)就會將后面的 TIME_WAIT 連接狀態(tài)重置，這個方法比較暴力。

net.ipv4.tcp_max_tw_buckets = 18000

方式三：程序中使用 SO_LINGER

我們可以通過設置 socket 選項，來設置調(diào)用 close 關(guān)閉連接行為。

struct linger so_linger;
so_linger.l_onoff = 1;
so_linger.l_linger = 0;
setsockopt(s, SOL_SOCKET, SO_LINGER, &so_linger,sizeof(so_linger));

如果l_onoff為非 0， 且l_linger值為 0，那么調(diào)用close后，會立該發(fā)送一個RST標志給對端，該 TCP 連接將跳過四次揮手，也就跳過了TIME_WAIT狀態(tài)，直接關(guān)閉。

但這為跨越TIME_WAIT狀態(tài)提供了一個可能，不過是一個非常危險的行為，不值得提倡。

前面介紹的方法都是試圖越過 TIME_WAIT狀態(tài)的，這樣其實不太好。雖然 TIME_WAIT 狀態(tài)持續(xù)的時間是有一點長，顯得很不友好，但是它被設計來就是用來避免發(fā)生亂七八糟的事情。

《UNIX網(wǎng)絡編程》一書中卻說道：TIME_WAIT 是我們的朋友，它是有助于我們的，不要試圖避免這個狀態(tài)，而是應該弄清楚它。

如果服務端要避免過多的 TIME_WAIT 狀態(tài)的連接，就永遠不要主動斷開連接，讓客戶端去斷開，由分布在各處的客戶端去承受 TIME_WAIT。

服務端出現(xiàn)大量 CLOSE_WAIT 狀態(tài)的原因有哪些？

還是拿這張圖：

TCP 四次揮手的流程

從上面這張圖我們可以得知，CLOSE_WAIT 狀態(tài)是「被動關(guān)閉方」才會有的狀態(tài)，而且如果「被動關(guān)閉方」沒有調(diào)用 close 函數(shù)關(guān)閉連接，那么就無法發(fā)出 FIN 報文，從而無法使得 CLOSE_WAIT 狀態(tài)的連接轉(zhuǎn)變?yōu)?LAST_ACK 狀態(tài)。

所以，當服務端出現(xiàn)大量 CLOSE_WAIT 狀態(tài)的連接的時候，說明服務端的程序沒有調(diào)用 close 函數(shù)關(guān)閉連接。

那什么情況會導致服務端的程序沒有調(diào)用 close 函數(shù)關(guān)閉連接？這時候通常需要排查代碼。

我們先來分析一個普通的 TCP 服務端的流程：

• 創(chuàng)建服務端 socket，bind 綁定端口、listen 監(jiān)聽端口
• 將服務端 socket 注冊到 epoll
• epoll_wait 等待連接到來，連接到來時，調(diào)用 accpet 獲取已連接的 socket
• 將已連接的 socket 注冊到 epoll
• epoll_wait 等待事件發(fā)生
• 對方連接關(guān)閉時，我方調(diào)用 close

可能導致服務端沒有調(diào)用 close 函數(shù)的原因，如下。

第一個原因：第 2 步?jīng)]有做，沒有將服務端 socket 注冊到 epoll，這樣有新連接到來時，服務端沒辦法感知這個事件，也就無法獲取到已連接的 socket，那服務端自然就沒機會對 socket 調(diào)用 close 函數(shù)了。

不過這種原因發(fā)生的概率比較小，這種屬于明顯的代碼邏輯 bug，在前期 read view 階段就能發(fā)現(xiàn)的了。

第二個原因：第 3 步?jīng)]有做，有新連接到來時沒有調(diào)用 accpet 獲取該連接的 socket，導致當有大量的客戶端主動斷開了連接，而服務端沒機會對這些 socket 調(diào)用 close 函數(shù)，從而導致服務端出現(xiàn)大量 CLOSE_WAIT 狀態(tài)的連接。

發(fā)生這種情況可能是因為服務端在執(zhí)行 accpet  函數(shù)之前，代碼卡在某一個邏輯或者提前拋出了異常。

第三個原因：第 4 步?jīng)]有做，通過 accpet 獲取已連接的 socket 后，沒有將其注冊到 epoll，導致后續(xù)收到 FIN 報文的時候，服務端沒辦法感知這個事件，那服務端就沒機會調(diào)用 close 函數(shù)了。

發(fā)生這種情況可能是因為服務端在將已連接的 socket 注冊到 epoll 之前，代碼卡在某一個邏輯或者提前拋出了異常。之前看到過別人解決 close_wait 問題的實踐文章，感興趣的可以看看：一次 Netty 代碼不健壯導致的大量 CLOSE_WAIT 連接原因分析

第四個原因：第 6 步?jīng)]有做，當發(fā)現(xiàn)客戶端關(guān)閉連接后，服務端沒有執(zhí)行 close 函數(shù)，可能是因為代碼漏處理，或者是在執(zhí)行 close 函數(shù)之前，代碼卡在某一個邏輯，比如發(fā)生死鎖等等。

可以發(fā)現(xiàn)，當服務端出現(xiàn)大量 CLOSE_WAIT 狀態(tài)的連接的時候，通常都是代碼的問題，這時候我們需要針對具體的代碼一步一步的進行排查和定位，主要分析的方向就是服務端為什么沒有調(diào)用 close。