1. 先搞清楚TCP狀態(tài)機到底在解決什么問題如果你寫過網(wǎng)絡(luò)應(yīng)用或者排查過連接超時、端口占用、連接數(shù)過多的問題那你一定遇到過ESTABLISHED、TIME_WAIT、CLOSE_WAIT這些狀態(tài)。很多人知道這些名詞但一到線上出問題比如服務(wù)器出現(xiàn)大量CLOSE_WAIT導(dǎo)致無法新建連接或者TIME_WAIT過多占滿端口就不知道從何下手。TCP狀態(tài)機就是用來精確描述一個TCP連接從建立到銷毀中間所經(jīng)歷的所有可能狀態(tài)以及狀態(tài)之間轉(zhuǎn)換規(guī)則的模型。它不是一個可以“下載”的獨立軟件或庫而是TCP協(xié)議實現(xiàn)比如Linux內(nèi)核中的TCP/IP協(xié)議棧必須嚴格遵循的一套核心邏輯。理解它你就能精準定位網(wǎng)絡(luò)問題看到一個連接狀態(tài)立刻知道它卡在了握手、數(shù)據(jù)傳輸還是揮手環(huán)節(jié)該查服務(wù)端還是客戶端。理解內(nèi)核參數(shù)調(diào)優(yōu)為什么tcp_fin_timeout可以調(diào)整TIME_WAIT的時長為什么tcp_tw_reuse和tcp_tw_recycle后者已廢棄能影響端口復(fù)用這些參數(shù)都是在影響狀態(tài)機的行為。設(shè)計更健壯的網(wǎng)絡(luò)程序知道什么時候該優(yōu)雅關(guān)閉發(fā)送FIN而不是粗暴close知道連接池里的連接處于什么狀態(tài)才是真正可用的。所以這篇文章不是給你列一遍11種狀態(tài)的名稱就完了。我會結(jié)合Linux內(nèi)核以5.x版本為例的視角帶你走一遍數(shù)據(jù)包如何驅(qū)動狀態(tài)變遷并告訴你每個關(guān)鍵狀態(tài)在netstat或ss命令里出現(xiàn)時對應(yīng)的實際場景和排查方向。最終目標(biāo)是讓你下次看到CLOSE_WAIT時能立刻反應(yīng)出是應(yīng)用程序沒有調(diào)用close而不是去重啟網(wǎng)絡(luò)服務(wù)。2. 狀態(tài)機的核心一張圖與兩個視角所有關(guān)于TCP狀態(tài)機的討論都繞不開那張經(jīng)典的狀態(tài)轉(zhuǎn)換圖。但死記硬背那張圖沒用關(guān)鍵是要建立兩個視角協(xié)議視角這是RFC標(biāo)準定義的理想化的狀態(tài)轉(zhuǎn)換。它定義了SYN,ACK,FIN,RST這些標(biāo)志位如何驅(qū)動狀態(tài)變化。內(nèi)核實現(xiàn)視角這是Linux內(nèi)核或其他操作系統(tǒng)如何具體實現(xiàn)這個狀態(tài)機包括定時器、隊列、系統(tǒng)調(diào)用如connect,accept,close如何與協(xié)議狀態(tài)交互。我們重點關(guān)注內(nèi)核視角因為這才是你通過命令能觀測到的、能調(diào)參的真實世界。2.1 協(xié)議視角下的狀態(tài)清單先快速過一遍協(xié)議定義的11個標(biāo)準狀態(tài)方便后續(xù)對照LISTEN服務(wù)器端調(diào)用listen()后等待客戶端連接。SYN-SENT客戶端調(diào)用connect()發(fā)送SYN后等待對端SYN-ACK。SYN-RECEIVED服務(wù)器收到SYN并回復(fù)SYN-ACK后等待客戶端的ACK。ESTABLISHED連接建立成功可以雙向傳輸數(shù)據(jù)。FIN-WAIT-1主動關(guān)閉方先調(diào)用close()的一方發(fā)送FIN后進入。FIN-WAIT-2主動關(guān)閉方收到對端對FIN的ACK后進入等待對端的FIN。CLOSE-WAIT被動關(guān)閉方收到對端的FIN并回復(fù)ACK后進入等待本地上層應(yīng)用調(diào)用close()。CLOSING一種罕見情況雙方幾乎同時發(fā)送FIN并都進入了FIN-WAIT-1然后都收到了對方的FIN。LAST-ACK被動關(guān)閉方調(diào)用close()發(fā)送自己的FIN后等待對方對這個FIN的ACK。TIME-WAIT主動關(guān)閉方收到被動方的FIN并回復(fù)ACK后進入。這個狀態(tài)會持續(xù)2MSLMaximum Segment Lifetime報文最大生存時間。CLOSED連接完全關(guān)閉。2.2 內(nèi)核視角狀態(tài)是如何被驅(qū)動的在Linux內(nèi)核中TCP狀態(tài)機不是一個孤立的模塊。它緊密耦合在協(xié)議棧處理網(wǎng)絡(luò)數(shù)據(jù)包的流程里。簡單來說驅(qū)動狀態(tài)變遷的核心引擎是接收數(shù)據(jù)包處理路徑網(wǎng)卡驅(qū)動 - IP層 - TCP層。在TCP層會根據(jù)當(dāng)前連接的狀態(tài)存儲在struct sock中和收到的TCP標(biāo)志位調(diào)用對應(yīng)的狀態(tài)處理函數(shù)如tcp_rcv_state_process。本地系統(tǒng)調(diào)用當(dāng)應(yīng)用程序調(diào)用connect(),accept(),close(),shutdown()時內(nèi)核會生成相應(yīng)的TCP段如SYN, FIN并發(fā)送同時更新本地連接狀態(tài)。定時器每個TCP連接有多個定時器重傳、?；?、TIME_WAIT等。超時事件會強制觸發(fā)狀態(tài)變遷例如重傳超時可能導(dǎo)致連接重置RST。舉個例子當(dāng)內(nèi)核為一個處于ESTABLISHED狀態(tài)的連接收到一個FIN包時它會確認這個FIN的序列號有效?；貜?fù)一個ACK。將連接狀態(tài)從ESTABLISHED改為CLOSE_WAIT。通知上層應(yīng)用程序通過socket可讀事件告知“對端已經(jīng)關(guān)閉了發(fā)送通道”。此時如果你用ss -antp命令查看就會看到這個連接的狀態(tài)是CLOSE-WAIT。3. 從三次握手到數(shù)據(jù)傳輸狀態(tài)變遷實戰(zhàn)拆解我們以一次完整的客戶端-服務(wù)器通信為例結(jié)合strace和tcpdump的視角看看狀態(tài)如何一步步變化。3.1 連接建立三次握手假設(shè)服務(wù)器在 8080 端口監(jiān)聽。步驟1服務(wù)器啟動監(jiān)聽# 服務(wù)器程序調(diào)用 socket() - bind() - listen()此時服務(wù)器監(jiān)聽 socket 的狀態(tài)是LISTEN。用ss -lnt可以看到State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:8080 *:*步驟2客戶端發(fā)起連接# 客戶端程序調(diào)用 socket() - connect(server_ip:8080)內(nèi)核為這個新socket生成一個SYN包發(fā)送出去?？蛻舳藄ocket狀態(tài)變?yōu)镾YN-SENT。tcpdump抓包能看到[S]標(biāo)志。步驟3服務(wù)器響應(yīng)SYN服務(wù)器內(nèi)核收到SYN包。創(chuàng)建一個新的socket用于這個連接狀態(tài)置為SYN-RECEIVED?；貜?fù) SYN-ACK。此時這個新socket在服務(wù)器端還不完全是ESTABLISHED它處在半連接隊列syn queue中。步驟4客戶端完成握手客戶端收到SYN-ACK狀態(tài)從SYN-SENT變?yōu)镋STABLISHED?；貜?fù)ACK給服務(wù)器?？蛻舳说腸onnect()系統(tǒng)調(diào)用成功返回。步驟5服務(wù)器接受連接服務(wù)器收到ACK。將socket狀態(tài)從SYN-RECEIVED變?yōu)镋STABLISHED。將該socket從半連接隊列移到全連接隊列accept queue。服務(wù)器應(yīng)用程序調(diào)用accept()會從這個全連接隊列中取出socket返回給應(yīng)用層使用。關(guān)鍵排查點如果服務(wù)器accept()很慢全連接隊列滿了客戶端可能會卡住。此時用ss -lnt看監(jiān)聽端口的Send-Q全連接隊列當(dāng)前長度會很大。相關(guān)內(nèi)核參數(shù)是net.core.somaxconn和listen()調(diào)用時的backlog參數(shù)。3.2 數(shù)據(jù)傳輸ESTABLISHED連接建立后雙方進入ESTABLISHED狀態(tài)。這是最?？吹降臓顟B(tài)。此時send()和recv()調(diào)用都是在操作內(nèi)核的發(fā)送和接收緩沖區(qū)由內(nèi)核負責(zé)組包、確認、重傳。這個階段的狀態(tài)機邏輯相對簡單主要處理數(shù)據(jù)確認和窗口管理。但資源監(jiān)控很重要ss -ant可以看到大量ESTABLISHED連接。通過/proc/net/sockstat或ss -s可以查看總的TCP socket內(nèi)存使用情況。如果應(yīng)用不讀取數(shù)據(jù)接收緩沖區(qū)滿會導(dǎo)致對方的發(fā)送窗口為0傳輸暫停。3.3 連接關(guān)閉四次揮手這是狀態(tài)機最復(fù)雜也最容易出問題的部分。我們假設(shè)客戶端先調(diào)用close()。步驟1客戶端主動關(guān)閉# 客戶端程序調(diào)用 close(fd); // 或 shutdown(SHUT_WR)客戶端內(nèi)核發(fā)送一個FIN包。客戶端socket狀態(tài)從ESTABLISHED變?yōu)镕IN-WAIT-1。步驟2服務(wù)器確認FIN服務(wù)器內(nèi)核收到FIN知道客戶端不再發(fā)送數(shù)據(jù)?；貜?fù)一個ACK。服務(wù)器socket狀態(tài)從ESTABLISHED變?yōu)镃LOSE-WAIT。這是第一個關(guān)鍵故障點如果服務(wù)器應(yīng)用程序因為BUG死鎖、阻塞、邏輯錯誤沒有及時調(diào)用close()來關(guān)閉這個socket這個連接就會一直停留在CLOSE-WAIT狀態(tài)。積累多了會耗盡服務(wù)器文件描述符導(dǎo)致無法新建連接。用ss -ant看到大量CLOSE-WAIT基本可以斷定是服務(wù)器程序的問題。步驟3客戶端收到ACK客戶端收到對FIN的ACK。狀態(tài)從FIN-WAIT-1變?yōu)镕IN-WAIT-2。此時客戶端到服務(wù)器的單向通道已關(guān)閉但還可以接收服務(wù)器發(fā)來的數(shù)據(jù)。步驟4服務(wù)器被動關(guān)閉服務(wù)器應(yīng)用程序終于調(diào)用close()。服務(wù)器內(nèi)核發(fā)送自己的FIN包。服務(wù)器socket狀態(tài)從CLOSE-WAIT變?yōu)長AST-ACK。步驟5客戶端確認服務(wù)器的FIN客戶端收到服務(wù)器的FIN?；貜?fù)ACK?？蛻舳藸顟B(tài)從FIN-WAIT-2變?yōu)門IME-WAIT。步驟6服務(wù)器收到最終ACK服務(wù)器收到ACK。服務(wù)器socket狀態(tài)從LAST-ACK變?yōu)镃LOSED并釋放資源。步驟7客戶端等待2MSL后關(guān)閉客戶端在TIME-WAIT狀態(tài)需要等待 2MSL默認60秒由net.ipv4.tcp_fin_timeout影響但更準確地說TIME-WAIT的時長是固定的tcp_tw_timeout實際上現(xiàn)代Linux內(nèi)核中TIME-WAIT狀態(tài)由專門的tw_bucket管理其超時時間通常是TCP_TIMEWAIT_LEN(60秒)不受tcp_fin_timeout直接影響。tcp_fin_timeout控制的是FIN-WAIT-2狀態(tài)的超時。等待的目的是1. 確保最后一個ACK能到達服務(wù)器如果丟失服務(wù)器會重傳FIN。2. 讓本次連接的所有報文都在網(wǎng)絡(luò)中消失避免影響后續(xù)使用相同四元組源IP、源端口、目的IP、目的端口的新連接。超時后客戶端socket狀態(tài)變?yōu)镃LOSED資源釋放。關(guān)鍵排查點TIME-WAIT狀態(tài)本身是正常的但高并發(fā)短連接服務(wù)如HTTP服務(wù)器可能會在短時間內(nèi)產(chǎn)生大量TIME-WAIT占用大量端口和內(nèi)存。此時可以考慮開啟net.ipv4.tcp_tw_reuse允許將TIME-WAITsocket重新用于新的出向連接需同時開啟tcp_timestamps。切勿再使用已廢棄且危險的net.ipv4.tcp_tw_recycle。使用連接池減少短連接。讓客戶端承擔(dān)關(guān)閉連接的責(zé)任作為主動關(guān)閉方將TIME-WAIT分散到大量客戶端。4. 通過內(nèi)核日志和工具觀察狀態(tài)機理論懂了怎么驗證除了用netstat或ss我們還可以深入內(nèi)核。4.1 使用ss命令替代netstatss(socket statistics) 是更現(xiàn)代、更快的工具來自iproute2包。# 查看所有TCP連接 ss -ant # 查看監(jiān)聽端口 ss -lnt # 查看進程和連接關(guān)系 ss -antp # 查看指定狀態(tài)如TIME-WAIT的連接 ss -ant state time-wait4.2 開啟內(nèi)核動態(tài)追蹤需要root對于更底層的問題可以開啟內(nèi)核的TCP調(diào)試日志。這會產(chǎn)生大量輸出僅用于臨時調(diào)試。# 開啟所有TCP事件的調(diào)試信息非常詳細 echo 1 /proc/sys/net/ipv4/tcp_debug # 然后使用 dmesg -w 或 tail -f /var/log/kern.log 查看日志 # 你會看到類似 TCP: xxx [State] ... 的信息記錄了狀態(tài)變遷和數(shù)據(jù)包處理。 # 調(diào)試完成后務(wù)必關(guān)閉 echo 0 /proc/sys/net/ipv4/tcp_debug更精細的控制可以通過sysctl設(shè)置net.ipv4.tcp_*系列參數(shù)例如調(diào)整重傳次數(shù)、超時時間等這些參數(shù)直接影響狀態(tài)機中定時器的行為。4.3 狀態(tài)異常排查清單當(dāng)網(wǎng)絡(luò)連接出現(xiàn)異常時可以按以下順序結(jié)合狀態(tài)機進行排查連接建立失敗現(xiàn)象connect()超時或拒絕。查客戶端ss -ant看是否有大量SYN-SENT可能是網(wǎng)絡(luò)不通、防火墻攔截、服務(wù)器端口未監(jiān)聽。查服務(wù)器ss -lnt確認端口在LISTEN。dmesg看是否有syn flood或listen queue overflow日志檢查net.ipv4.tcp_max_syn_backlog半連接隊列和net.core.somaxconn全連接隊列大小。大量CLOSE-WAIT現(xiàn)象服務(wù)器負載不高但無法新建連接ss顯示大量CLOSE-WAIT。結(jié)論幾乎肯定是服務(wù)器應(yīng)用程序BUG。應(yīng)用沒有對檢測到對端關(guān)閉的socket調(diào)用close()。行動用ss -antp找到持有這些socket的進程PID審查其代碼的socket關(guān)閉邏輯尤其是異常處理分支。大量TIME-WAIT現(xiàn)象壓測后客戶端或服務(wù)器出現(xiàn)大量TIME-WAIT。判斷這是正常協(xié)議行為。如果影響新連接建立考慮調(diào)整net.ipv4.tcp_tw_reuse僅對客戶端有效或優(yōu)化架構(gòu)使用長連接。連接卡在FIN-WAIT-1或FIN-WAIT-2FIN-WAIT-1長時間存在對端沒有回復(fù)ACK?？赡苁菍Χ顺绦虮罎?、網(wǎng)絡(luò)問題或防火墻丟棄了ACK。FIN-WAIT-2長時間存在對端沒有發(fā)送FIN?？赡苁菍Χ顺绦蛲岁P(guān)閉連接或者正在發(fā)送剩余數(shù)據(jù)。內(nèi)核參數(shù)net.ipv4.tcp_fin_timeout定義了FIN-WAIT-2狀態(tài)的超時時間默認60秒超時后內(nèi)核會強制關(guān)閉連接。收到RST復(fù)位包狀態(tài)機遇到RST會直接跳到CLOSED。產(chǎn)生RST的原因可能是向一個未監(jiān)聽的端口發(fā)起連接、連接已關(guān)閉后仍收到數(shù)據(jù)、程序崩潰導(dǎo)致socket未正常關(guān)閉等。抓包tcpdump看到[R]標(biāo)志可以幫助定位問題端。5. 狀態(tài)機與高性能網(wǎng)絡(luò)編程理解狀態(tài)機對編程有直接指導(dǎo)意義。5.1 優(yōu)雅關(guān)閉Graceful Shutdown粗暴地調(diào)用close()會立即發(fā)送RST丟棄緩沖區(qū)數(shù)據(jù)。優(yōu)雅關(guān)閉使用shutdown()// 告知對端“我發(fā)完了”但還可以收 shutdown(sockfd, SHUT_WR); // 然后繼續(xù)讀取對端可能發(fā)來的剩余數(shù)據(jù) while (read(sockfd, buffer, sizeof(buffer)) 0) { /* ... */ } // 最后再close close(sockfd);這個過程清晰地對應(yīng)了狀態(tài)機SHUT_WR發(fā)送FIN進入FIN-WAIT-1讀完數(shù)據(jù)后close()完成最終清理。5.2 連接池健康檢查連接池里的連接不能只看socket是否可寫最好能驗證其TCP狀態(tài)。一個簡單的方法是發(fā)送一個0字節(jié)的TCP?；钐綔y如果開啟了SO_KEEPALIVE或者應(yīng)用層心跳。一個處于ESTABLISHED狀態(tài)但實際網(wǎng)絡(luò)已斷開的“僵死”連接會在下次讀寫時失敗。更高級的做法是定期用getsockopt(fd, SOL_SOCKET, SO_ERROR, ...)檢查socket錯誤。5.3 理解“端口占用”問題重啟服務(wù)時提示“Address already in use”通常是因為原連接還處于TIME-WAIT狀態(tài)。設(shè)置socket選項SO_REUSEADDR可以允許綁定處于TIME-WAIT狀態(tài)的地址這對服務(wù)器重啟非常有用。而SO_REUSEPORT則允許多個socket綁定到相同的IP地址和端口用于多進程服務(wù)器。6. 總結(jié)把狀態(tài)機變成你的排查直覺TCP狀態(tài)機不是抽象理論而是內(nèi)嵌在每一次connect()、accept()、read()、write()、close()調(diào)用背后的精確規(guī)則。我建議你把排查思路固化成以下流程出問題時先看狀態(tài)ss -antp | grep 端口或IP或ss -ant state 狀態(tài)。狀態(tài)直接告訴你連接生命周期的階段。結(jié)合狀態(tài)推斷角色CLOSE-WAIT在誰那里誰就是被動關(guān)閉方且沒調(diào)用close。TIME-WAIT在誰那里誰就是最后一次發(fā)送ACK的主動關(guān)閉方。根據(jù)狀態(tài)查對應(yīng)環(huán)節(jié)SYN-SENT/SYN-RECV問題 - 查握手、防火墻、隊列。ESTABLISHED無數(shù)據(jù) - 查應(yīng)用讀寫邏輯、網(wǎng)絡(luò)帶寬、緩沖區(qū)。CLOSE-WAIT堆積 - 查應(yīng)用代碼關(guān)閉邏輯。TIME-WAIT過多 - 評估是否正常考慮調(diào)整參數(shù)或架構(gòu)。借助工具深挖tcpdump抓包看標(biāo)志位序列strace跟蹤應(yīng)用系統(tǒng)調(diào)用sysctl查看和調(diào)整內(nèi)核參數(shù)。最后記住Linux內(nèi)核的TCP實現(xiàn)非常復(fù)雜包含了擁塞控制、滑動窗口、快速重傳等大量優(yōu)化狀態(tài)機是它的骨架。把這個骨架摸清網(wǎng)絡(luò)問題的迷霧就散開了一大半。下次再遇到連接異常別急著重啟服務(wù)先用狀態(tài)機的視角看一眼你很可能就能直接命中問題的根源。