終於搞懂了 TCP 的 11 種狀態 ，太不容易了…

本來想寫運維過程中，nginx 服務器中 time_wait 的相關測試及解決方法的，然後發現TCP 的狀態需要先鋪墊一下，於是就整理了這篇文章。

網上很多大佬整理TCP三次握手、四次揮手，看到過很多人寫，但其實從運維角度來說，我們分析 TCP 鏈接狀態的時候，首先是用 netstat 或 ss 來查看。

之後纔會根據 TCP 狀態的情況進行抓包分析，進一步確認一些問題，所以我們首先看到的會是 TCP 的狀態，那麼就需要很清楚的瞭解 TCP 的11種狀態代表着什麼。

TCP 的11種狀態分別對應 TCP 三次握手過程的5種狀態和TCP四次揮手斷開過程中的6種狀態。

如上圖，就是11種狀態，在整個TCP建立連接和斷開連接的整個過程

下面我用 tcpdump 抓了個完整的客戶端和服務端的三次握手和四次揮手的包，可以對應上面的狀態圖

下面分開來詳細看，首先是三次握手

上面這個圖就是完整的三次握手過程

• 首先由 client 發出請求連接，即SYN=1 ACK=0，TCP 規定 SYN=1 時不能攜帶數據，但要消耗一個 seq，所以聲明自己的seq=x

• 然後 Server 進行回覆確認，即 SYN=1 ACK=1 seq=y ack=x+1

• 最後 Client 再進行一次確認，但不用SYN了，即ACK=1 seq=x+1 ack=y+1

整個過程中對應的TCP狀態如下：

• CLOSED ：初始狀態，表示TCP連接是”關閉着的”或”未打開的”

• LISTEN ：表示服務器端的某個SOCKET處於監聽狀態，可以接受客戶端的連接

• SYN_RCVD ：表示服務器接收到了來自客戶端請求連接的SYN報文。這個狀態是在服務端的，但是它是一箇中間狀態，很短暫，平常我們用netstat或ss的時候，不太容易看到這種狀態，但是遇到SYN flood之類的SYN攻擊時，會出現大量的這種狀態，即收不到三次握手最後一個客戶端發來的ACK，所以一直是這個狀態，不會轉換到ESTABLISHED

• SYN_SENT ：這個狀態與SYN_RCVD狀態相呼應，，它是TCP連接客戶端的狀態，當客戶端SOCKET執行connect()進行連接時，它首先發送SYN報文，然後隨機進入到SYN_SENT狀態，並等待服務端的SYN和ACK，該狀態表示客戶端的SYN已發送

• ESTABLISHED ：表示TCP連接已經成功建立，開始傳輸數據

以上就是三次握手的五種TCP狀態，單從客戶端服務端角度來區分的話，CLOSED和ESTABLISHED會在客戶端和服務端都出現，而LISTEN和SYN_RCVD通常是出現在服務端，SYN_SENT出現在客戶端

但通常在服務器和客戶端並不是絕對的，比如 Nginx 的服務器中，Nginx 通常作爲 web 代理服務器，它既是服務端，也是客戶端，所以在查詢統計 TCP 狀態的時候，最好通過匹配端口來區分是客戶端的還是服務端的，來更精確的定位問題。

接着看四次揮手的狀態

• FIN_WAIT_1：這個狀態在實際工作中很少能看到，當客戶端想要主動關閉連接時，它會向服務端發送FIN報文，此時TCP狀態就進入到FIN_WAIT_1的狀態，而當服務端回覆ACK，確認關閉後，則客戶端進入到FIN_WAIT_2的狀態，也就是隻有在沒有收到服務端ACK的情況下，FIN_WAIT_1狀態才能看到，然後長時間收不到ACK，通常會在默認超時時間60s(由內核參數tcp_fin_timeout控制)後，直接進入CLOSED狀態

• FIN_WAIT_2：這個狀態相比較常見，也是需要注意的一個狀態，FIN_WAIT_1在接收到服務端ACK之後就進入到FIN_WAIT_2的狀態，然後等待服務端發送FIN，所以在收到對端FIN之前，TCP都會處於FIN_WAIT_2的狀態，也就是，在主動斷開的一端發現大量的FIN_WAIT_2狀態時，需要注意，可能時網絡不穩定或程序中忘記調用連接關閉，FIN_WAIT_2也有超時時間，也是由內核參數tcp_fin_timeout控制，當FIN_WAIT_2狀態超時後，連接直接銷燬

• CLOSE_WAIT：表示正在等待關閉，該狀態只在被動端出現，即當主動斷開的一端調用close()後發送FIN報文給被動端，被動段必然會回應一個ACK(這是由TCP協議層決定的)，這個時候，TCP連接狀態就進入到CLOSE_WAIT

• LAST_ACK：當被動關閉的一方在發送FIN報文後，等待對方的ACK報文的時候，就處於LAST_ACK的狀態，當收到對方的ACK之後，就進入到CLOSED狀態了

• TIME_WAIT ：該狀態是最常見的狀態，主動方在收到對方FIN後，就由FIN_WAIT_2狀態進入到TIME_WAIT狀態

• CLOSING ：這個狀態是一個比較特殊的狀態，也比較少見，正常情況下不會出現，但是當雙方同時都作爲主動的一方，調用 close() 關閉連接的時候，兩邊都進入FIN_WAIT_1 的狀態，此時期望收到的是ACK包，進入 FIN_WAIT_2 的狀態，但是卻先收到了對方的FIN包，這個時候，就會進入到 CLOSING 的狀態，然後給對方一個ACK，接收到 ACK 後直接進入到 CLOSED 狀態。

以上就是四次揮手的6種狀態，瞭解了每個狀態的詳細含義，就可以在性能調優及故障排查中快速定位問題，調整相關參數。

如文章開頭說的一樣，整理這篇主要是鋪墊後面想整理的 nginx 中常見的 TIME_WAIT 的問題，TIME_WAIT 必須快速回收處理嗎？TIME_WAIT 多少算多，會有什麼影響，什麼時候會產生大量的 TIME_WAIT，除了快速回收和重複利用，還有什麼方法可以解決TIME_WAIT 的問題，下篇文章繼續！

來源：本文來源於公衆號運維研習社。

倒計時1天，GNSEC 2020 全球新一代軟件工程線上峯會馬上就要開始了！

抓緊最後的機會，掃描下方二維碼立即報名

近期好文：

一個因 CA 根證書過期引起的故障，真相竟然是…

一文搞懂什麼是 vlan、三層交換機、網關、DNS、子網掩碼、MAC地址

投稿郵箱：jiachen@greatops.net，或添加聯繫人微信：greatops1118.

點擊閱讀原文，進入“GNSEC 線上峯會”官網

點個“在看”，一年不宕機