TCP協(xié)議（Transmission Control Protocol，傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層協(xié)議。
TCP協(xié)議不僅確保數(shù)據(jù)的完整性，還設(shè)計了一套完整的連接管理機制：
? 三次握手（建立連接）；
? 四次揮手（斷開連接）。
其中，TCP協(xié)議四次揮手是TCP連接斷開時的關(guān)鍵步驟，確保雙方都能正確釋放源，避免數(shù)據(jù)丟失或連接異常終止。
TCP是全雙工通信，意味著數(shù)據(jù)可以同時在兩個方向傳輸。因此，連接的斷開不僅需要客戶端通知服務(wù)器自己不再發(fā)送數(shù)據(jù)，還需要服務(wù)器通知客戶端自己也不再發(fā)送數(shù)據(jù)。這就導(dǎo)致了四次揮手的過程，而不是簡單的三次握手。
客戶端發(fā)送FIN（終止請求）：客戶端發(fā)送一個FIN（Finish）報文，表示自己不再發(fā)送數(shù)據(jù)，進入FIN-WAIT-1狀態(tài)。此時，客戶端仍然可以接收數(shù)據(jù)，但不會再主動發(fā)送數(shù)據(jù)。
服務(wù)器回復(fù)ACK（確認(rèn)）：服務(wù)器收到FIN后，發(fā)送一個ACK（Acknowledgment）報文，確認(rèn)收到客戶端的終止請求，進入CLOSE-WAIT狀態(tài)。此時，服務(wù)器仍然可以繼續(xù)發(fā)送數(shù)據(jù)。
服務(wù)器發(fā)送FIN（終止請求）：服務(wù)器在完成數(shù)據(jù)傳輸后，發(fā)送FIN報文，表示自己也不再發(fā)送數(shù)據(jù)，進入LAST-ACK狀態(tài)。
客戶端回復(fù)ACK（確認(rèn)）：客戶端收到服務(wù)器的FIN 后，發(fā)送ACK報文，確認(rèn)收到服務(wù)器的終止請求，進入TIME-WAIT狀態(tài)。此時，客戶端會等待一段時間（通常是2MSL，即最大報文生存時間的兩倍），確保服務(wù)器收到ACK 后才徹底關(guān)閉連接。
? TIME-WAIT狀態(tài)的存在是為了確保最后一個ACK能夠被服務(wù)器正確接收，防止舊的TCP報文影響新的連接。通常，TIME-WAIT狀態(tài)會持續(xù)2MSL（最大報文生存時間），以確保所有可能的延遲數(shù)據(jù)包都被清除。
? TIME-WAIT還可以防止已失效的連接請求報文段影響新的連接。如果客戶端在發(fā)送完最后一個ACK后立即釋放連接，那么可能會導(dǎo)致服務(wù)器的FIN報文丟失，進而影響新的連接建立。
下圖為完整流程的展示
簡單的來講，基于TCP穩(wěn)定的通信，在連接斷開時不僅要終止數(shù)據(jù)的發(fā)送，還要確保對方的數(shù)據(jù)已經(jīng)完全接收。同時tcp是全雙工通信，所以每個通道都需要單獨關(guān)閉，這導(dǎo)致請求回復(fù)的機制需要重復(fù)兩遍，也就是4次是這個確認(rèn)機制的最小步驟。
總的來說，三次握手是建立可靠連接，而四次揮手則是為了保證數(shù)據(jù)傳輸?shù)耐暾?/strong>性。但是在實際的應(yīng)用中如高并發(fā)服務(wù)器環(huán)境中：
? TIME-WAIT狀態(tài)可能會導(dǎo)致大量端口占用，影響服務(wù)器性能。為了解決這個問題，許多系統(tǒng)會采用TCP連接復(fù)用或縮短TIME-WAIT時間 的方式來優(yōu)化連接釋放過程。
? 某些系統(tǒng)在socket選項中也提供了SO_REUSEADDR選項，允許新的連接在TIME-WAIT狀態(tài)下復(fù)用舊的端口，從而提高服務(wù)器的并發(fā)能力。
今天的分享就到這里啦，EBYTE每一天都致力于更好的助力物聯(lián)化、智能化、自動化的發(fā)展，提升資源利用率，更多以太網(wǎng)模組產(chǎn)品和無線通信技術(shù)資料，感興趣的小伙伴可以登錄我們的億佰特官網(wǎng)和企業(yè)公眾號（微信號：cdebyte）進行了解，也可以直接撥打400電話咨詢技術(shù)專員！
相關(guān)閱讀：
1、TCP粘包怎么產(chǎn)生的以及TCP粘包問題解決方案
2、什么是TCP協(xié)議粘包以及如何解決TCP粘包問題
