本來(lái)想寫(xiě)運維過(guò)程中，nginx 服務(wù)器中 time_wait 的相關(guān)測試及解決方法的，然后發(fā)現TCP 的狀態(tài)需要先鋪墊一下，于是就整理了這篇文章。
網(wǎng)上很多大佬整理 TCP 三次握手、四次揮手，看到過(guò)很多人寫(xiě)，但其實(shí)從運維角度來(lái)說(shuō)，我們分析 TCP 鏈接狀態(tài)的時(shí)候，首先是用 netstat 或 ss 來(lái)查看。
之后才會(huì )根據 TCP 狀態(tài)的情況進(jìn)行抓包分析，進(jìn)一步確認一些問(wèn)題，所以我們首先看到的會(huì )是 TCP 的狀態(tài)，那么就需要很清楚的了解 TCP 的11種狀態(tài)代表著(zhù)什么。TCP 的11種狀態(tài)分別對應 TCP 三次握手過(guò)程的5種狀態(tài)和TCP四次揮手斷開(kāi)過(guò)程中的6種狀態(tài)。
如上圖，就是11種狀態(tài)，在整個(gè)TCP建立連接和斷開(kāi)連接的整個(gè)過(guò)程下面我用 tcpdump 抓了個(gè)完整的客戶(hù)端和服務(wù)端的三次握手和四次揮手的包，可以對應上面的狀態(tài)圖：
下面分開(kāi)來(lái)詳細看，首先是三次握手：
上面這個(gè)圖就是完整的三次握手過(guò)程：
首先由 client 發(fā)出請求連接，即SYN=1 ACK=0，TCP 規定 SYN=1 時(shí)不能攜帶數據，但要消耗一個(gè) seq，所以聲明自己的seq=x
然后 Server 進(jìn)行回復確認，即 SYN=1 ACK=1 seq=y ack=x+1
最后 Client 再進(jìn)行一次確認，但不用SYN了，即ACK=1 seq=x+1 ack=y+1
整個(gè)過(guò)程中對應的TCP狀態(tài)如下：
CLOSED：初始狀態(tài)，表示TCP連接是”關(guān)閉著(zhù)的”或”未打開(kāi)的”
LISTEN：表示服務(wù)器端的某個(gè)SOCKET處于監聽(tīng)狀態(tài)，可以接受客戶(hù)端的連接
SYN_RCVD：表示服務(wù)器接收到了來(lái)自客戶(hù)端請求連接的SYN報文。這個(gè)狀態(tài)是在服務(wù)端的，但是它是一個(gè)中間狀態(tài)，很短暫，平常我們用netstat或ss的時(shí)候，不太容易看到這種狀態(tài)，但是遇到SYN flood之類(lèi)的SYN攻擊時(shí)，會(huì )出現大量的這種狀態(tài)，即收不到三次握手最后一個(gè)客戶(hù)端發(fā)來(lái)的ACK，所以一直是這個(gè)狀態(tài)，不會(huì )轉換到ESTABLISHED
SYN_SENT：這個(gè)狀態(tài)與SYN_RCVD狀態(tài)相呼應，，它是TCP連接客戶(hù)端的狀態(tài)，當客戶(hù)端SOCKET執行connect()進(jìn)行連接時(shí)，它首先發(fā)送SYN報文，然后隨機進(jìn)入到SYN_SENT狀態(tài)，并等待服務(wù)端的SYN和ACK，該狀態(tài)表示客戶(hù)端的SYN已發(fā)送
ESTABLISHED：表示TCP連接已經(jīng)成功建立，開(kāi)始傳輸數據
以上就是三次握手的五種TCP狀態(tài)，單從客戶(hù)端服務(wù)端角度來(lái)區分的話(huà)，CLOSED和ESTABLISHED會(huì )在客戶(hù)端和服務(wù)端都出現，而LISTEN和SYN_RCVD通常是出現在服務(wù)端，SYN_SENT出現在客戶(hù)端。
但通常在服務(wù)器和客戶(hù)端并不是絕對的，比如 Nginx 的服務(wù)器中，Nginx 通常作為 web 代理服務(wù)器，它既是服務(wù)端，也是客戶(hù)端，所以在查詢(xún)統計 TCP 狀態(tài)的時(shí)候，最好通過(guò)匹配端口來(lái)區分是客戶(hù)端的還是服務(wù)端的，來(lái)更精確的定位問(wèn)題。
接著(zhù)看四次揮手的狀態(tài)
FIN_WAIT_1：這個(gè)狀態(tài)在實(shí)際工作中很少能看到，當客戶(hù)端想要主動(dòng)關(guān)閉連接時(shí)，它會(huì )向服務(wù)端發(fā)送FIN報文，此時(shí)TCP狀態(tài)就進(jìn)入到FIN_WAIT_1的狀態(tài)，而當服務(wù)端回復ACK，確認關(guān)閉后，則客戶(hù)端進(jìn)入到FIN_WAIT_2的狀態(tài)，也就是只有在沒(méi)有收到服務(wù)端ACK的情況下，FIN_WAIT_1狀態(tài)才能看到，然后長(cháng)時(shí)間收不到ACK，通常會(huì )在默認超時(shí)時(shí)間60s(由內核參數tcp_fin_timeout控制)后，直接進(jìn)入CLOSED狀態(tài)
FIN_WAIT_2：這個(gè)狀態(tài)相比較常見(jiàn)，也是需要注意的一個(gè)狀態(tài)，FIN_WAIT_1在接收到服務(wù)端ACK之后就進(jìn)入到FIN_WAIT_2的狀態(tài)，然后等待服務(wù)端發(fā)送FIN，所以在收到對端FIN之前，TCP都會(huì )處于FIN_WAIT_2的狀態(tài)，也就是，在主動(dòng)斷開(kāi)的一端發(fā)現大量的FIN_WAIT_2狀態(tài)時(shí)，需要注意，可能時(shí)網(wǎng)絡(luò )不穩定或程序中忘記調用連接關(guān)閉，FIN_WAIT_2也有超時(shí)時(shí)間，也是由內核參數tcp_fin_timeout控制，當FIN_WAIT_2狀態(tài)超時(shí)后，連接直接銷(xiāo)毀
CLOSE_WAIT：表示正在等待關(guān)閉，該狀態(tài)只在被動(dòng)端出現，即當主動(dòng)斷開(kāi)的一端調用close()后發(fā)送FIN報文給被動(dòng)端，被動(dòng)端必然會(huì )回應一個(gè)ACK(這是由TCP協(xié)議層決定的)，這個(gè)時(shí)候，TCP連接狀態(tài)就進(jìn)入到CLOSE_WAIT
LAST_ACK：當被動(dòng)關(guān)閉的一方在發(fā)送FIN報文后，等待對方的ACK報文的時(shí)候，就處于LAST_ACK的狀態(tài)，當收到對方的ACK之后，就進(jìn)入到CLOSED狀態(tài)了
TIME_WAIT：該狀態(tài)是最常見(jiàn)的狀態(tài)，主動(dòng)方在收到對方FIN后，就由FIN_WAIT_2狀態(tài)進(jìn)入到TIME_WAIT狀態(tài)
CLOSING：這個(gè)狀態(tài)是一個(gè)比較特殊的狀態(tài)，也比較少見(jiàn)，正常情況下不會(huì )出現，但是當雙方同時(shí)都作為主動(dòng)的一方，調用 close() 關(guān)閉連接的時(shí)候，兩邊都進(jìn)入FIN_WAIT_1 的狀態(tài)，此時(shí)期望收到的是ACK包，進(jìn)入 FIN_WAIT_2 的狀態(tài)，但是卻先收到了對方的FIN包，這個(gè)時(shí)候，就會(huì )進(jìn)入到 CLOSING 的狀態(tài)，然后給對方一個(gè)ACK，接收到 ACK 后直接進(jìn)入到 CLOSED 狀態(tài)。
以上就是四次揮手的6種狀態(tài)，了解了每個(gè)狀態(tài)的詳細含義，就可以在性能調優(yōu)及故障排查中快速定位問(wèn)題，調整相關(guān)參數。
如文章開(kāi)頭說(shuō)的一樣，整理這篇主要是鋪墊后面想整理的 nginx 中常見(jiàn)的 TIME_WAIT 的問(wèn)題，TIME_WAIT 必須快速回收處理嗎？TIME_WAIT 多少算多，會(huì )有什么影響，什么時(shí)候會(huì )產(chǎn)生大量的 TIME_WAIT，除了快速回收和重復利用，還有什么方法可以解決TIME_WAIT 的問(wèn)題，下篇文章繼續！
來(lái)源：本文來(lái)源于公眾號運維研習社。
