[[330570]]

本來想寫運(yùn)維過程中，nginx 服務(wù)器中 time_wait 的相關(guān)測(cè)試及解決方法的，然后發(fā)現(xiàn)TCP 的狀態(tài)需要先鋪墊一下，于是就整理了這篇文章。

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

之后才會(huì)根據(jù) TCP 狀態(tài)的情況進(jìn)行抓包分析，進(jìn)一步確認(rèn)一些問題，所以我們首先看到的會(huì)是 TCP 的狀態(tài)，那么就需要很清楚的了解 TCP 的11種狀態(tài)代表著什么。

TCP 的11種狀態(tài)分別對(duì)應(yīng) TCP 三次握手過程的5種狀態(tài)和TCP四次揮手?jǐn)嚅_過程中的6種狀態(tài)。

如上圖，就是11種狀態(tài)，在整個(gè)TCP建立連接和斷開連接的整個(gè)過程

下面我用 tcpdump 抓了個(gè)完整的客戶端和服務(wù)端的三次握手和四次揮手的包，可以對(duì)應(yīng)上面的狀態(tài)圖

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

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

• 首先由 client 發(fā)出請(qǐng)求連接，即SYN=1 ACK=0，TCP 規(guī)定 SYN=1 時(shí)不能攜帶數(shù)據(jù)，但要消耗一個(gè) seq，所以聲明自己的seq=x
• 然后 Server 進(jìn)行回復(fù)確認(rèn)，即 SYN=1 ACK=1 seq=y ack=x+1
• 最后 Client 再進(jìn)行一次確認(rèn)，但不用SYN了，即ACK=1 seq=x+1 ack=y+1

整個(gè)過程中對(duì)應(yīng)的TCP狀態(tài)如下：

• CLOSED：初始狀態(tài)，表示TCP連接是”關(guān)閉著的”或”未打開的”
• LISTEN：表示服務(wù)器端的某個(gè)SOCKET處于監(jiān)聽狀態(tài)，可以接受客戶端的連接
• SYN_RCVD：表示服務(wù)器接收到了來自客戶端請(qǐng)求連接的SYN報(bào)文。這個(gè)狀態(tài)是在服務(wù)端的，但是它是一個(gè)中間狀態(tài)，很短暫，平常我們用netstat或ss的時(shí)候，不太容易看到這種狀態(tài)，但是遇到SYN flood之類的SYN攻擊時(shí)，會(huì)出現(xiàn)大量的這種狀態(tài)，即收不到三次握手最后一個(gè)客戶端發(fā)來的ACK，所以一直是這個(gè)狀態(tài)，不會(huì)轉(zhuǎn)換到ESTABLISHED
• SYN_SENT：這個(gè)狀態(tài)與SYN_RCVD狀態(tài)相呼應(yīng)，，它是TCP連接客戶端的狀態(tài)，當(dāng)客戶端SOCKET執(zhí)行connect()進(jìn)行連接時(shí)，它首先發(fā)送SYN報(bào)文，然后隨機(jī)進(jìn)入到SYN_SENT狀態(tài)，并等待服務(wù)端的SYN和ACK，該狀態(tài)表示客戶端的SYN已發(fā)送
• ESTABLISHED：表示TCP連接已經(jīng)成功建立，開始傳輸數(shù)據(jù)

以上就是三次握手的五種TCP狀態(tài)，單從客戶端服務(wù)端角度來區(qū)分的話，CLOSED和ESTABLISHED會(huì)在客戶端和服務(wù)端都出現(xiàn)，而LISTEN和SYN_RCVD通常是出現(xiàn)在服務(wù)端，SYN_SENT出現(xiàn)在客戶端

但通常在服務(wù)器和客戶端并不是絕對(duì)的，比如 Nginx 的服務(wù)器中，Nginx 通常作為 web 代理服務(wù)器，它既是服務(wù)端，也是客戶端，所以在查詢統(tǒng)計(jì) TCP 狀態(tài)的時(shí)候，最好通過匹配端口來區(qū)分是客戶端的還是服務(wù)端的，來更精確的定位問題。

接著看四次揮手的狀態(tài)

• FIN_WAIT_1：這個(gè)狀態(tài)在實(shí)際工作中很少能看到，當(dāng)客戶端想要主動(dòng)關(guān)閉連接時(shí)，它會(huì)向服務(wù)端發(fā)送FIN報(bào)文，此時(shí)TCP狀態(tài)就進(jìn)入到FIN_WAIT_1的狀態(tài)，而當(dāng)服務(wù)端回復(fù)ACK，確認(rèn)關(guān)閉后，則客戶端進(jìn)入到FIN_WAIT_2的狀態(tài)，也就是只有在沒有收到服務(wù)端ACK的情況下，F(xiàn)IN_WAIT_1狀態(tài)才能看到，然后長時(shí)間收不到ACK，通常會(huì)在默認(rèn)超時(shí)時(shí)間60s(由內(nèi)核參數(shù)tcp_fin_timeout控制)后，直接進(jìn)入CLOSED狀態(tài)
• FIN_WAIT_2：這個(gè)狀態(tài)相比較常見，也是需要注意的一個(gè)狀態(tài)，F(xiàn)IN_WAIT_1在接收到服務(wù)端ACK之后就進(jìn)入到FIN_WAIT_2的狀態(tài)，然后等待服務(wù)端發(fā)送FIN，所以在收到對(duì)端FIN之前，TCP都會(huì)處于FIN_WAIT_2的狀態(tài)，也就是，在主動(dòng)斷開的一端發(fā)現(xiàn)大量的FIN_WAIT_2狀態(tài)時(shí)，需要注意，可能時(shí)網(wǎng)絡(luò)不穩(wěn)定或程序中忘記調(diào)用連接關(guān)閉，F(xiàn)IN_WAIT_2也有超時(shí)時(shí)間，也是由內(nèi)核參數(shù)tcp_fin_timeout控制，當(dāng)FIN_WAIT_2狀態(tài)超時(shí)后，連接直接銷毀
• CLOSE_WAIT：表示正在等待關(guān)閉，該狀態(tài)只在被動(dòng)端出現(xiàn)，即當(dāng)主動(dòng)斷開的一端調(diào)用close()后發(fā)送FIN報(bào)文給被動(dòng)端，被動(dòng)段必然會(huì)回應(yīng)一個(gè)ACK(這是由TCP協(xié)議層決定的)，這個(gè)時(shí)候，TCP連接狀態(tài)就進(jìn)入到CLOSE_WAIT
• LAST_ACK：當(dāng)被動(dòng)關(guān)閉的一方在發(fā)送FIN報(bào)文后，等待對(duì)方的ACK報(bào)文的時(shí)候，就處于LAST_ACK的狀態(tài)，當(dāng)收到對(duì)方的ACK之后，就進(jìn)入到CLOSED狀態(tài)了
• TIME_WAIT：該狀態(tài)是最常見的狀態(tài)，主動(dòng)方在收到對(duì)方FIN后，就由FIN_WAIT_2狀態(tài)進(jìn)入到TIME_WAIT狀態(tài)
• CLOSING：這個(gè)狀態(tài)是一個(gè)比較特殊的狀態(tài)，也比較少見，正常情況下不會(huì)出現(xiàn)，但是當(dāng)雙方同時(shí)都作為主動(dòng)的一方，調(diào)用 close() 關(guān)閉連接的時(shí)候，兩邊都進(jìn)入FIN_WAIT_1 的狀態(tài)，此時(shí)期望收到的是ACK包，進(jìn)入 FIN_WAIT_2 的狀態(tài)，但是卻先收到了對(duì)方的FIN包，這個(gè)時(shí)候，就會(huì)進(jìn)入到 CLOSING 的狀態(tài)，然后給對(duì)方一個(gè)ACK，接收到 ACK 后直接進(jìn)入到 CLOSED 狀態(tài)。

以上就是四次揮手的6種狀態(tài)，了解了每個(gè)狀態(tài)的詳細(xì)含義，就可以在性能調(diào)優(yōu)及故障排查中快速定位問題，調(diào)整相關(guān)參數(shù)。

如文章開頭說的一樣，整理這篇主要是鋪墊后面想整理的 nginx 中常見的 TIME_WAIT 的問題，TIME_WAIT 必須快速回收處理嗎？TIME_WAIT 多少算多，會(huì)有什么影響，什么時(shí)候會(huì)產(chǎn)生大量的 TIME_WAIT，除了快速回收和重復(fù)利用，還有什么方法可以解決TIME_WAIT 的問題，下篇文章繼續(xù)！