[[330570]]

本來想寫運維過程中，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 的問題，下篇文章繼續！