timewait(timewait狀態(tài))

簡介： 壓測場景下的 TIME_WAIT 處理

1. 序

某專有云項(xiàng)目具備壓測場景，在Windows的壓測機(jī)上用 LoadRunner 進(jìn)行業(yè)務(wù)的壓力測試，壓測運(yùn)行一段時(shí)間后出現(xiàn)大量端口無法分配的報(bào)錯(cuò)。其實(shí)通過問題描述，以及 Windows的報(bào)錯(cuò)信息基本確定是壓測機(jī)的問題。但可能原因較多，一直未能達(dá)成一致。所以，趁機(jī)分析了客戶端的壓測機(jī)成為壓測瓶頸的可能，除了CPU、網(wǎng)絡(luò)、 I/O 等機(jī)器性能參數(shù)外，仍需考慮網(wǎng)絡(luò)協(xié)議引入的資源短缺問題。注：以下內(nèi)容的目的是理清TCP協(xié)議中比較模糊的內(nèi)容，對協(xié)議比較熟悉的可以忽略。

2. TIME_WAIT基礎(chǔ)：RFC 793 TCP協(xié)議

眾所周知， TCP存在三次握手，四次揮手過程。其具體設(shè)計(jì)的目的，簡而言之，是為了在不穩(wěn)定的物理網(wǎng)絡(luò)環(huán)境中確保可靠的數(shù)據(jù)傳輸；因此，TCP在具體實(shí)現(xiàn)中加入了很多異常狀況的處理，整體協(xié)議就變得比較復(fù)雜。要理解TCP協(xié)議，推薦閱讀 RFC 793，可參考文后鏈接了解詳情[1]。同時(shí)，也要理解“TCP state transition”狀態(tài)機(jī)，如下圖所示，可參考文后資料了解詳情[2]。

圖1. TCP狀態(tài)轉(zhuǎn)換圖

本文僅針對 TW 在TCP協(xié)議中的作用進(jìn)行討論，不涉及整體協(xié)議的分析。四次揮手后的TIME_WAIT 狀態(tài)，后續(xù)將以TW縮寫替代。

2.1 TW 作用

首先，主要作用是保證TCP連接關(guān)閉的可靠性。考慮下在四次揮手過程中，如果主動(dòng)關(guān)閉方發(fā)送的LAST_ACK丟失，那么被動(dòng)關(guān)閉方會(huì)重傳FIN。此時(shí)，如果主動(dòng)關(guān)閉方對應(yīng)的TCP Endpoint沒有進(jìn)入TW狀態(tài)而是直接在內(nèi)核中清理了，根據(jù)協(xié)議，主動(dòng)關(guān)閉方會(huì)認(rèn)為自己沒有打開過這個(gè)端口，而以RST響應(yīng)被動(dòng)關(guān)閉方重傳的FIN。最終該行為導(dǎo)致被動(dòng)關(guān)閉方認(rèn)為連接異常關(guān)閉，在業(yè)務(wù)上可能會(huì)收到異常報(bào)錯(cuò)等情況。其次，TW狀態(tài)同時(shí)也能避免相同的TCP端口收到在網(wǎng)絡(luò)上前一個(gè)連接的重復(fù)數(shù)據(jù)包。理論上，數(shù)據(jù)包在網(wǎng)絡(luò)上過期時(shí)間對應(yīng)即MSL（Maximal Segment Lifetime），隨著操作系統(tǒng)的不斷發(fā)展，也有例外情況，這部分搜索PAWS應(yīng)該可以看到不少類似的文章說明。再次，端口進(jìn)入 TW 狀態(tài) 同時(shí)也避免了被操作系統(tǒng)快速重復(fù)使用的可能。

2.2 TW形成的原因

當(dāng)一臺主機(jī)操作系統(tǒng)主動(dòng)關(guān)閉TCP Endpoint（socket）時(shí)，該TCP Endpoint進(jìn)入TW狀態(tài)。以Windows為例，Windows內(nèi)核會(huì)對 TCP Endpoint 數(shù)據(jù)結(jié)構(gòu)進(jìn)行相應(yīng)清理，然后放入額外的 TW queue 中，設(shè)置2MSL 的定時(shí)器，等待定時(shí)器超時(shí)后調(diào)用對應(yīng)的釋放代碼。Linux上的實(shí)現(xiàn)也是類似。目前較多的說法是"TCP連接"進(jìn)入TW ，但我們可能需要理解 "連接" 其實(shí)是抽象的概念。實(shí)際上"連接"在邏輯上存在，因?yàn)榭蛻舳撕头?wù)器端以及中間可能涉及的4層設(shè)備同時(shí)為一次傳輸創(chuàng)建了關(guān)聯(lián)的TCP資源（Endpoint，或者 Session）。準(zhǔn)確理解TW狀態(tài)，即TCP EndpointTW進(jìn)入TW狀態(tài)。

2.3 小結(jié)

TW 是為了保證 TCP 連接正常終止（避免端口被快速復(fù)用），也是為了保證網(wǎng)絡(luò)中迷失的數(shù)據(jù)包正常過期（防止前一個(gè)連接的數(shù)據(jù)包被錯(cuò)誤的接收）。TW暗殺術(shù)，可參考文后資料了解詳情[3]。

3. 概念澄清

歡迎討論幾個(gè)可能比較模糊的地方，明確如下：

作為連接雙方，客戶端和服務(wù)器端的TCP Endpoint都可能進(jìn)入 TW 狀態(tài)（極端情況下，可能雙方同時(shí)進(jìn)入 TW 狀態(tài)）。

該情況在邏輯上是成立的，可參考文后資料了解詳情[4]。

TW 是標(biāo)準(zhǔn)的一部分，不代表TCP端口或者連接狀態(tài)異常。（這個(gè)概念很重要，避免陷入某些不必要的陷阱。）CLOSE_WAIT 盡管也是標(biāo)準(zhǔn)的一部分，但它的出現(xiàn)預(yù)示著本端的 TCP Endpoint 處于半關(guān)閉狀態(tài)，原因常常是應(yīng)用程序沒有調(diào)用 socket 相關(guān)的 clo 或者 shutdown。可能的原因是應(yīng)用程序仍有未發(fā)送完成的數(shù)據(jù)，該情況下CLOSE_WAIT 最終還是會(huì)消失的。 具體描述這部分，長期有 CLOSE_WAIT 狀態(tài)的端口緩慢累積，這種情況是需要引起注意的，累積到一定程度，端口資源就不夠了。

針對前面的 TCP Endpoint 這個(gè)詞語，可能很多人不太了解，這邊也簡單說明下：在Windows 2008 R2之前，socket是用戶態(tài)（ur mode） 的概念，大多數(shù)Windows socket應(yīng)用程序基本都基于Winsock開發(fā)，由中間層AFD.sys 驅(qū)動(dòng)翻譯成內(nèi)核 tcpip.sys 協(xié)議棧驅(qū)動(dòng) 所能接受的TCP Endpoint數(shù)據(jù)結(jié)構(gòu)。在2008 R2之后，微軟為了方便內(nèi)核的網(wǎng)絡(luò)編程，在Windows Kernel中提供WSK，即Winsock在內(nèi)核的實(shí)現(xiàn)。文中提到的TCP Endpoint是在Windows內(nèi)核中由TCPIP.sys驅(qū)動(dòng)文件實(shí)現(xiàn)的TCP數(shù)據(jù)結(jié)構(gòu)，也對應(yīng)Linux上的socket。該文簡單以 Endpoint 代指內(nèi)核的"socket"。

4. TW 優(yōu)化手段

對于Linux，優(yōu)化手段已經(jīng)進(jìn)行了很多討論了，以Centos為例，

在timestamps啟用的情況下，配置 tcp_tw_reu 和tcp_tw_recycle。

針對客戶端，連接請求發(fā)起方。net.ipv4.tcp_timestamps = 1net.ipv4.tcp_tw_reu = 1

針對服務(wù)器端，連接請求接收方net.ipv4.tcp_timestamps = 1net.ipv4.tcp_tw_recycle = 1注：tcp_tw_recycle的啟用會(huì)帶來一些 side effect，具體在NAT地址轉(zhuǎn)換場景下，容易發(fā)生連接異常問題。可參考文后資料了解詳情[4]。

配置 max_tw_buckets，連接請求發(fā)起方接收方通用，但需要注意這個(gè)選項(xiàng)本身有違 TW 設(shè)計(jì)的初衷。

net.ipv4.tcp_max_tw_buckets = 5000

配置 ip_local_port_range，連接請求發(fā)起方。

net.ipv4.ip_local_port_range = 5000 65535

針對Windows ，資料較少，這邊借之前的工作經(jīng)驗(yàn)，總結(jié)如下：

Windows Vista / Windows Server 2008 之前的操作系統(tǒng)，注冊表

端口范圍：HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersMaxUrPort = 0n65534TW 超時(shí)時(shí)間：HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersTcpTimedWaitDelay = 0n30

Windows 7 / Windows Server 2008 R2 及其之后的版本

端口范圍：netsh int ipv4 t dynamicport tcp start=1025 num=64511TW 超時(shí)時(shí)間：HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersTcpTimedWaitDelay = 0n30

Windows Server 2012 and earlier: 30-300 (decimal)Windows 8 and earlier: 30-300 (decimal)Windows Server 2012 R2 and later: 2-300 (decimal)Windows 8.1 and later: 2-300 (decimal)注：

任何涉及注冊表的修改，只有重啟機(jī)器才會(huì)生效。與 Linux不同，Windows 沒有快速回收機(jī)制，不存在快速回收 TW 的可能，只能等待2MSL過期（即TcpTimedWaitDelay）。Windows唯一能快速回收TW狀態(tài)的Endpoint 的情況：

新連接請求的SEQ序列號>TW狀態(tài)的Endpoint記錄的SEQ序列號。此時(shí)，內(nèi)核會(huì)認(rèn)為該 SYN 請求合法。 這里，這個(gè)TW 狀態(tài)的 TCP Endpoint 一定是在服務(wù)端（通過socket accept 打開的 服務(wù)端口）。（為了這個(gè)能力，Windows 的 RFC 1323 選項(xiàng)必須打開，內(nèi)容可以自行搜索。）

5. 壓測客戶端無法分配端口的原因分析

端口無法分配有兩種可能：

完全隨機(jī)的動(dòng)態(tài)端口請求，報(bào)錯(cuò)端口分配異常，基本是操作系統(tǒng)沒有可用端口。指定端口的綁定申請報(bào)錯(cuò)端口分配異常，可能存在端口使用沖突問題。

針對第一種情況，首先需要通過 netstat -ano 進(jìn)行快速檢查，分析是否存在端口占滿的情況，以及占滿端口的TCP Endpoint狀態(tài)。針對不同的狀態(tài)，考慮不同的方案。比如，極端情況下，沒有任何異常的服務(wù)器上，端口分配失敗問題，可參考文后資料了解詳情[5]。以Windows操作系統(tǒng)TW狀態(tài)Endpoint占滿可用端口場景為例（在Linux上發(fā)生的可能性較低），分析問題前需要大概了解 Windows 上端口分配原理。

Windows和Linux在動(dòng)態(tài)分配端口的機(jī)制上有很大的不同。Linux以粗淺的理解應(yīng)該是針對五元組的分配，即可能存在相同的動(dòng)態(tài)端口訪問不同服務(wù)器的服務(wù)端口。Windows的動(dòng)態(tài)端口分配實(shí)現(xiàn)基于Bitmap查找，無論訪問哪里，動(dòng)態(tài)端口的池子最大為 1025 – 65536，即64511個(gè)。考慮到最短30秒的 TW 超時(shí)時(shí)間，如果按照 64511/29 = 2225 ports/s 的速度去創(chuàng)建端口，那么很可能在30秒后持續(xù)發(fā)生端口無法分配的問題。這還是在連接處理比較快速的情況下，如果連接建立后不關(guān)閉，或者關(guān)閉時(shí)間比較久，創(chuàng)建端口的速度仍需持續(xù)下降來規(guī)避端口問題。

理解了 TW 的形成原因，相應(yīng)的解決方案也就比較清楚了。

降低應(yīng)用程序創(chuàng)建端口的速度。考慮連接持續(xù)時(shí)間和TW超時(shí)時(shí)間，計(jì)算相對合理的連接建立速度。不過，物理機(jī)操作系統(tǒng)、CPU/內(nèi)存、網(wǎng)絡(luò)IO等均可能影響連接狀態(tài)，精確計(jì)算很難；同時(shí)，就應(yīng)用程序而言，降低端口創(chuàng)建速度需要額外的邏輯，可能性不大。在這個(gè)壓測場景下，通過增加機(jī)器的方式來變相減少端口的需求。壓測一般考慮某個(gè)固定閾值下整體系統(tǒng)的響應(yīng)情況。在壓力固定的情況下，可以通過分散壓力的方式來減少端口資源的占用。改變連接的行為，使用持久連接（注：非HTTP的長連接），例如針對500個(gè)并發(fā)，僅建立 500 個(gè)連接。好處顯而易見，但壞處也很明顯，持久連接不大符合用戶真實(shí)行為，壓測結(jié)果可能失真。同時(shí)，該方法需要應(yīng)用程序上的支持。不讓機(jī)器的TCP Endpoint進(jìn)入TW狀態(tài)，可參考以下2種方案。a) 不讓該機(jī)器主動(dòng)關(guān)閉連接，而讓對方主動(dòng)關(guān)閉。這樣，該主機(jī)進(jìn)入被動(dòng)關(guān)閉進(jìn)程，在應(yīng)用關(guān)閉TCP Endpoint之后，可直接釋放端口資源。一些協(xié)議本身就有控制是否保持連接或者請求對方關(guān)閉連接的行為或者參數(shù)，在考慮這類問題的時(shí)候，可以適當(dāng)進(jìn)行利用。比如 HTTP 的長短連接，可參考文后資料了解詳情[4]。b) 通過TCP Ret強(qiáng)制釋放端口。TCP Ret可以由任何一方發(fā)出，無論是發(fā)送方還是接收方，在看到TCP Ret之后會(huì)立刻將對應(yīng)TCP Endpoint拆除。

這里，可設(shè)置 socket 的 SO_LINGER選項(xiàng)，比如配置Nginx，可參考文后官方文檔了解詳情[6]。

圖2：Nginx Lingering配置參考說明

針對壓測工具本身，官方網(wǎng)站上也有類似 ABRUPT 選項(xiàng)，可參考文后官方文檔了解詳情[7]。

圖3：LoadRunner ABRUPT配置選項(xiàng)說明

作者：陳鴿

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載