談?wù)?TCP 的 TIME_WAIT

由來(lái)

最近有同事在用 ab 進(jìn)行服務(wù)壓測(cè)，到 QPS 瓶頸后懷疑是起壓機(jī)的問(wèn)題，來(lái)跟我借測(cè)試機(jī)，于是我就趁機(jī)分析了一波起壓機(jī)可能成為壓測(cè)瓶頸的可能，除了網(wǎng)絡(luò) I/O、機(jī)器性能外，還考慮到了網(wǎng)絡(luò)協(xié)議的問(wèn)題。

當(dāng)然本文的主角并不是壓測(cè)，后來(lái)分析證明同事果然還是想多了，瓶頸是在服務(wù)端。

分析起壓機(jī)瓶頸的過(guò)程中，對(duì)于 TCP TIME_WAIT 狀態(tài)的一個(gè)猜想引起了我的興趣。由于之前排查問(wèn)題時(shí)，簡(jiǎn)單地接觸過(guò)這個(gè)狀態(tài)，但并未深入了解，于是決定抽時(shí)間分析一下，拆解一下我的猜想。

TCP 的狀態(tài)轉(zhuǎn)換

我們都知道 TCP 的三次握手，四次揮手，說(shuō)來(lái)簡(jiǎn)單，但在不穩(wěn)定的物理網(wǎng)絡(luò)中，每一個(gè)動(dòng)作都有可能失敗，為了保證數(shù)據(jù)被有效傳輸，TCP 的具體實(shí)現(xiàn)中也加入了很多對(duì)這些異常狀況的處理。

狀態(tài)分析

先用一張圖來(lái)回想一下 TCP 的狀態(tài)轉(zhuǎn)換。

一眼看上去，這么多種狀態(tài)，各個(gè)方向的連線，讓人感覺(jué)有點(diǎn)懵。但細(xì)細(xì)分析下來(lái)，還是有理可循的。

首先，整個(gè)圖可以被劃分為三個(gè)部分，即上半部分建連過(guò)程，左下部分主動(dòng)關(guān)閉連接過(guò)程和右下部分被動(dòng)關(guān)閉連接過(guò)程。

再來(lái)看各個(gè)部分：建連過(guò)程就是我們熟悉的三次握手，只是這張圖上多了一個(gè)服務(wù)端會(huì)存在的 LISTEN 狀態(tài)；而主動(dòng)關(guān)閉連接和被動(dòng)關(guān)閉連接，都是四次揮手的過(guò)程。

查看連接狀態(tài)

在 Linux 上，我們常用 netstat 來(lái)查看網(wǎng)絡(luò)連接的狀態(tài)。當(dāng)然我們還可以使用更快捷高效的 ss (Socket Statistics) 來(lái)替代 netstat。

這兩個(gè)工具都會(huì)列出此時(shí)機(jī)器上的 socket 連接的狀態(tài)，通過(guò)簡(jiǎn)單的統(tǒng)計(jì)就可以分析出此時(shí)服務(wù)器的網(wǎng)絡(luò)狀態(tài)。

TIME_WAIT

定義

我們從上面的圖中可以看出來(lái)，當(dāng) TCP 連接主動(dòng)關(guān)閉時(shí)，都會(huì)經(jīng)過(guò) TIME_WAIT 狀態(tài)。而且我們?cè)跈C(jī)器上 curl 一個(gè) url 創(chuàng)建一個(gè) TCP 連接后，使用 ss 等工具可以在一定時(shí)長(zhǎng)內(nèi)持續(xù)觀察到這個(gè)連續(xù)處于 TIME_WAIT 狀態(tài)。

所以TIME_WAIT 是這么一種狀態(tài)：TCP 四次握手結(jié)束后，連接雙方都不再交換消息，但主動(dòng)關(guān)閉的一方保持這個(gè)連接在一段時(shí)間內(nèi)不可用。

那么，保持這么一個(gè)狀態(tài)有什么用呢？

原因

上文中提到過(guò)，對(duì)于復(fù)雜的網(wǎng)絡(luò)狀態(tài)，TCP 的實(shí)現(xiàn)提出了多種應(yīng)對(duì)措施，TIME_WAIT 狀態(tài)的提出就是為了應(yīng)對(duì)其中一種異常狀況。

為了理解 TIME_WAIT 狀態(tài)的必要性，我們先來(lái)假設(shè)沒(méi)有這么一種狀態(tài)會(huì)導(dǎo)致的問(wèn)題。暫以 A、B 來(lái)代指 TCP 連接的兩端，A 為主動(dòng)關(guān)閉的一端。

• 四次揮手中，A 發(fā) FIN， B 響應(yīng) ACK，B 再發(fā) FIN，A 響應(yīng) ACK 實(shí)現(xiàn)連接的關(guān)閉。而如果 A 響應(yīng)的 ACK 包丟失，B 會(huì)以為 A 沒(méi)有收到自己的關(guān)閉請(qǐng)求，然后會(huì)重試向 A 再發(fā) FIN 包。

  如果沒(méi)有 TIME_WAIT 狀態(tài)，A 不再保存這個(gè)連接的信息，收到一個(gè)不存在的連接的包，A 會(huì)響應(yīng) RST 包，導(dǎo)致 B 端異常響應(yīng)。

  此時(shí)， TIME_WAIT 是為了保證全雙工的 TCP 連接正常終止。

• 我們還知道，TCP 下的 IP 層協(xié)議是無(wú)法保證包傳輸?shù)南群箜樞虻摹Ｈ绻p方揮手之后，一個(gè)網(wǎng)絡(luò)四元組（src/dst ip/port）被回收，而此時(shí)網(wǎng)絡(luò)中還有一個(gè)遲到的數(shù)據(jù)包沒(méi)有被 B 接收，A 應(yīng)用程序又立刻使用了同樣的四元組再創(chuàng)建了一個(gè)新的連接后，這個(gè)遲到的數(shù)據(jù)包才到達(dá) B，那么這個(gè)數(shù)據(jù)包就會(huì)讓 B 以為是 A 剛發(fā)過(guò)來(lái)的。

  此時(shí)， TIME_WAIT 的存在是為了保證網(wǎng)絡(luò)中迷失的數(shù)據(jù)包正常過(guò)期。

由以上兩個(gè)原因，TIME_WAIT 狀態(tài)的存在是非常有意義的。

時(shí)長(zhǎng)的確定

由原因來(lái)推實(shí)現(xiàn)，TIME_WAIT 狀態(tài)的保持時(shí)長(zhǎng)也就可以理解了。確定 TIME_WAIT 的時(shí)長(zhǎng)主要考慮上文的第二種情況，保證關(guān)閉連接后這個(gè)連接在網(wǎng)絡(luò)中的所有數(shù)據(jù)包都過(guò)期。

說(shuō)到過(guò)期時(shí)間，不得不提另一個(gè)概念: 最大分段壽命（MSL, Maximum Segment Lifetime），它表示一個(gè) TCP 分段可以存在于互聯(lián)網(wǎng)系統(tǒng)中的最大時(shí)間，由 TCP 的實(shí)現(xiàn)，超出這個(gè)壽命的分片都會(huì)被丟棄。

TIME_WAIT 狀態(tài)由主動(dòng)關(guān)閉的 A 來(lái)保持，那么我們來(lái)考慮對(duì)于 A 來(lái)說(shuō)，可能接到上一個(gè)連接的數(shù)據(jù)包的最大時(shí)長(zhǎng)：A 剛發(fā)出的數(shù)據(jù)包，能保持 MSL 時(shí)長(zhǎng)的壽命，它到了 B 端后，B 端由于關(guān)閉連接了，會(huì)響應(yīng) RST 包，這個(gè) RST 包最長(zhǎng)也會(huì)在 MSL 時(shí)長(zhǎng)后到達(dá) A，那么 A 端只要保持 TIME_WAIT 到達(dá) 2MS 就能保證網(wǎng)絡(luò)中這個(gè)連接的包都會(huì)消失。

MSL 的時(shí)長(zhǎng)被 RFC 定義為 2分鐘，但在不同的 unix 實(shí)現(xiàn)上，這個(gè)值不并確定，我們常用的 CentOS 上，它被定義為 30s，我們可以通過(guò) /proc/sys/net/ipv4/tcp_fin_timeout 這個(gè)文件查看和修改這個(gè)值。

ab 的”奇怪”表現(xiàn)

猜想

由上文，我們知道由于 TIME_WAIT 的存在，每個(gè)連接被主動(dòng)關(guān)閉后，這個(gè)連接就要保留 2MSL（60s） 時(shí)長(zhǎng)，一個(gè)網(wǎng)絡(luò)四元組也要被凍結(jié) 60s。而我們機(jī)器默認(rèn)可被分配的端口號(hào)約有 30000 個(gè)（可通過(guò) /proc/sys/net/ipv4/ip_local_port_range文件查看）。

那么如果我們使用 curl 對(duì)服務(wù)器請(qǐng)求時(shí)，作為客戶端，都要使用本機(jī)的一個(gè)端口號(hào)，所有的端口號(hào)分配到 60s 內(nèi)，每秒就要控制在 500 QPS，再多了，系統(tǒng)就無(wú)法再分配端口號(hào)了。

可是在使用 ab 進(jìn)行壓測(cè)時(shí)時(shí)，以每秒 4000 的 QPS 運(yùn)行幾分鐘，起壓機(jī)照樣正常工作，使用 ss 查看連接詳情時(shí)，發(fā)現(xiàn)一個(gè) TIME_WAIT 狀態(tài)的連接都沒(méi)有。

分析

一開(kāi)始我以為是 ab 使用了連接復(fù)用等技術(shù)，仔細(xì)查看了 ss 的輸出發(fā)現(xiàn)本地端口號(hào)一直在變，到底是怎么回事呢？

于是，我在一臺(tái)測(cè)試機(jī)啟動(dòng)了一個(gè)簡(jiǎn)單的服務(wù)，端口號(hào) 8090，然后在另一臺(tái)機(jī)器上起壓，并同時(shí)用 tcpdump 抓包。

結(jié)果發(fā)現(xiàn)，第一個(gè) FIN 包都是由服務(wù)器發(fā)送的，即 ab 不會(huì)主動(dòng)關(guān)閉連接。

登上服務(wù)器一看，果然，有大量的 TIME_WAIT 狀態(tài)的連接。

但是由于服務(wù)器監(jiān)聽(tīng)的端口會(huì)復(fù)用，這些 TIME_WAIT 狀態(tài)的連接并不會(huì)對(duì)服務(wù)器造成太大影響，只是會(huì)占用一些系統(tǒng)資源。

小結(jié)

當(dāng)然，高并發(fā)情況下，太多的 TIME_WAIT 也會(huì)給服務(wù)器造成很大的壓力，畢竟維護(hù)這么多 socket 也是要消耗資源的，關(guān)于如何解決 TIME_WAIT 過(guò)多的問(wèn)題，可以看 tcp短連接TIME_WAIT問(wèn)題解決方法大全。

tcp連接是網(wǎng)絡(luò)編程中最基礎(chǔ)的概念，基于不同的使用場(chǎng)景，我們一般區(qū)分為“長(zhǎng)連接”和“短連接”，
長(zhǎng)短連接的優(yōu)點(diǎn)和缺點(diǎn)這里就不詳細(xì)展開(kāi)了，有心的同學(xué)直接去google查詢，本文主要關(guān)注如何解決tcp短連接的TIME_WAIT問(wèn)題。

短連接最大的優(yōu)點(diǎn)是方便，特別是腳本語(yǔ)言，由于執(zhí)行完畢后腳本語(yǔ)言的進(jìn)程就結(jié)束了，基本上都是用短連接。
但短連接最大的缺點(diǎn)是將占用大量的系統(tǒng)資源，例如：本地端口、socket句柄。
導(dǎo)致這個(gè)問(wèn)題的原因其實(shí)很簡(jiǎn)單：tcp協(xié)議層并沒(méi)有長(zhǎng)短連接的概念，因此不管長(zhǎng)連接還是短連接，連接建立->數(shù)據(jù)傳輸->連接關(guān)閉的流程和處理都是一樣的。

正常的TCP客戶端連接在關(guān)閉后，會(huì)進(jìn)入一個(gè)TIME_WAIT的狀態(tài)，持續(xù)的時(shí)間一般在1~4分鐘，對(duì)于連接數(shù)不高的場(chǎng)景，1~4分鐘其實(shí)并不長(zhǎng)，對(duì)系統(tǒng)也不會(huì)有什么影響，
但如果短時(shí)間內(nèi)（例如1s內(nèi)）進(jìn)行大量的短連接，則可能出現(xiàn)這樣一種情況：客戶端所在的操作系統(tǒng)的socket端口和句柄被用盡，系統(tǒng)無(wú)法再發(fā)起新的連接！

舉例來(lái)說(shuō)：假設(shè)每秒建立了1000個(gè)短連接（Web場(chǎng)景下是很常見(jiàn)的，例如每個(gè)請(qǐng)求都去訪問(wèn)memcached），假設(shè)TIME_WAIT的時(shí)間是1分鐘，則1分鐘內(nèi)需要建立6W個(gè)短連接，
由于TIME_WAIT時(shí)間是1分鐘，這些短連接1分鐘內(nèi)都處于TIME_WAIT狀態(tài)，都不會(huì)釋放，而Linux默認(rèn)的本地端口范圍配置是：net.ipv4.ip_local_port_range = 32768    61000
不到3W，因此這種情況下新的請(qǐng)求由于沒(méi)有本地端口就不能建立了。

可以通過(guò)如下方式來(lái)解決這個(gè)問(wèn)題：
1）可以改為長(zhǎng)連接，但代價(jià)較大，長(zhǎng)連接太多會(huì)導(dǎo)致服務(wù)器性能問(wèn)題，而且PHP等腳本語(yǔ)言，需要通過(guò)proxy之類的軟件才能實(shí)現(xiàn)長(zhǎng)連接；
2）修改ipv4.ip_local_port_range，增大可用端口范圍，但只能緩解問(wèn)題，不能根本解決問(wèn)題；
3）客戶端程序中設(shè)置socket的SO_LINGER選項(xiàng)；
4）客戶端機(jī)器打開(kāi)tcp_tw_recycle和tcp_timestamps選項(xiàng)；
5）客戶端機(jī)器打開(kāi)tcp_tw_reuse和tcp_timestamps選項(xiàng)；
6）客戶端機(jī)器設(shè)置tcp_max_tw_buckets為一個(gè)很小的值；

在解決php連接Memcached的短連接問(wèn)題過(guò)程中，我們主要驗(yàn)證了3）4）5）6）幾種方法，采取的是基本功能驗(yàn)證和代碼驗(yàn)證，并沒(méi)有進(jìn)行性能壓力測(cè)試驗(yàn)證，
因此實(shí)際應(yīng)用的時(shí)候需要注意觀察業(yè)務(wù)運(yùn)行情況，發(fā)現(xiàn)丟包、斷連、無(wú)法連接等現(xiàn)象時(shí)，需要關(guān)注是否是因?yàn)檫@些選項(xiàng)導(dǎo)致的。

雖然這幾種方法都可以通過(guò)google查詢到相關(guān)信息，但這些信息大部分都是泛泛而談，而且絕大部分都是人云亦云，沒(méi)有很大參考價(jià)值。
我們?cè)诙ㄎ缓吞幚磉@些問(wèn)題過(guò)程中，遇到一些疑惑和困難，也花費(fèi)了一些時(shí)間去定位和解決，以下就是相關(guān)的經(jīng)驗(yàn)總結(jié)。

多了解原理遇到問(wèn)題才能更快地找到根源解決，網(wǎng)絡(luò)相關(guān)的知識(shí)還要繼續(xù)鞏固啊。