TCP三次握手與四次揮手的細(xì)節(jié)理解

簡介

TCP提供面向有連接的通信傳輸，面向有連接是指在數(shù)據(jù)通信開始之前先做好通信兩端之間的準(zhǔn)備工作。

TCP在數(shù)據(jù)通信之前，通過TCP首部發(fā)送一個(gè)SYN包作為建立連接的請求等待確認(rèn)應(yīng)答（TCP中發(fā)送第一個(gè)SYN包的一方叫做客戶端，接收這個(gè)的一方叫做服務(wù)端）。如果對端發(fā)來確認(rèn)應(yīng)答，則認(rèn)為可以進(jìn)行數(shù)據(jù)通信。如果對端的確認(rèn)應(yīng)答未能到達(dá)，就不會進(jìn)行數(shù)據(jù)通信。此外，在通信結(jié)束時(shí)會進(jìn)行斷開連接的處理（FIN包）。

一個(gè)連接的建立與斷開，正常過程至少需要來回發(fā)送7個(gè)包才能完成（建立一個(gè)TCP連接需要發(fā)送3個(gè)包，這個(gè)過程也稱作“三次握手”，斷開一個(gè)TCP連接需要發(fā)送4個(gè)包，這個(gè)過程也稱作“四次揮手”）。

TCP報(bào)文段首部

在具體理解三次握手與四次揮手的細(xì)節(jié)時(shí)，需要先了解一下TCP報(bào)文段的首部格式：

主要需要了解的是：

序號 seq

占4個(gè)字節(jié)，范圍[0,223-1]，共223(42 9496 7296)個(gè)序號。TCP是面向字節(jié)流的，在一個(gè)TCP連接中傳送的字節(jié)流中的每一個(gè)字節(jié)都按順序編號。

確認(rèn)號 ack

占4個(gè)字節(jié)，是期望收到對方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號。

確認(rèn) ACK

僅當(dāng)ACK=1時(shí)確認(rèn)號字段才有效，當(dāng)ACK=0時(shí)，確認(rèn)號無效。TCP規(guī)定，在建立連接后所傳送的報(bào)文都必須把ACK置1。

同步 SYN

在連接時(shí)用來同步序號，當(dāng)SYN=1而ACK=0時(shí)，表明這是一個(gè)連接請求報(bào)文段，對方若同意連接，在應(yīng)在響應(yīng)的報(bào)文段中使用SYN=1和ACK=1。因此，SYN置為1就表示這是一個(gè)連接請求或連接接受報(bào)文。

終止 FIN

用來釋放一個(gè)連接，當(dāng)FIN=1時(shí)，表明此報(bào)文段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢，并要求釋放運(yùn)輸連接。

三次握手

最初兩端的TCP進(jìn)程都處于CLOSE(關(guān)閉)狀態(tài)。上圖中A主動打開連接，B被動打開連接。

B打開連接后處于LISTEN(監(jiān)聽狀態(tài))，等待客戶的連接請求。

A向B發(fā)送請求報(bào)文，SYN=1,ACK=0,選擇一個(gè)初始序號seq=x。

B 收到連接請求報(bào)文，如果同意建立連接，則向 A 發(fā)送連接確認(rèn)報(bào)文，SYN=1，ACK=1，確認(rèn)號為ack= x+1，同時(shí)也選擇一個(gè)初始的序號 seq=y。

A 收到 B 的連接確認(rèn)報(bào)文后，還要向 B 發(fā)出確認(rèn)，確認(rèn)號為ack= y+1，序號為 seq=x+1。

B 收到 A 的確認(rèn)后，連接建立。

必須握手三次而不是兩次的原因

主要是防止已經(jīng)失效的連接請求報(bào)文突然又傳送到了服務(wù)器，從而產(chǎn)生錯(cuò)誤

如果使用的是兩次握手建立連接，假設(shè)有這樣一種場景，客戶端發(fā)送了第一個(gè)請求連接并且沒有丟失，只是因?yàn)樵?a href="http://www.ttokpm.com/v/tag/1722/" target="_blank">網(wǎng)絡(luò)結(jié)點(diǎn)中滯留的時(shí)間太長了，由于TCP的客戶端遲遲沒有收到確認(rèn)報(bào)文，以為服務(wù)器沒有收到，此時(shí)重新向服務(wù)器發(fā)送這條報(bào)文，此后客戶端和服務(wù)器經(jīng)過兩次握手完成連接，傳輸數(shù)據(jù)，然后關(guān)閉連接。此時(shí)此前滯留的那一次請求連接，網(wǎng)絡(luò)通暢了到達(dá)了服務(wù)器，這個(gè)報(bào)文本該是失效的，但是，兩次握手的機(jī)制將會讓客戶端和服務(wù)器再次建立連接，這將導(dǎo)致不必要的錯(cuò)誤和資源的浪費(fèi)。

如果采用的是三次握手，就算是那一次失效的報(bào)文傳送過來了，服務(wù)端接受到了那條失效報(bào)文并且回復(fù)了確認(rèn)報(bào)文，但是客戶端不會再次發(fā)出確認(rèn)。由于服務(wù)器收不到確認(rèn)，就知道客戶端并沒有請求連接。

建立連接后，客戶端出現(xiàn)故障時(shí)的機(jī)制

TCP設(shè)有一個(gè)?；钣?jì)時(shí)器，顯然，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費(fèi)資源。服務(wù)器每收到一次客戶端的請求后都會重新復(fù)位這個(gè)計(jì)時(shí)器，時(shí)間通常是設(shè)置為2小時(shí)，若2小時(shí)還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會發(fā)送一個(gè)探測報(bào)文段，以后每隔75秒發(fā)送一次。若一連發(fā)送10個(gè)探測報(bào)文仍然沒反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接。

四次揮手

A 發(fā)送連接釋放報(bào)文，F(xiàn)IN=1。

B 收到之后發(fā)出確認(rèn)，此時(shí) TCP 屬于半關(guān)閉狀態(tài)，B 能向 A 發(fā)送數(shù)據(jù)但是 A 不能向 B 發(fā)送數(shù)據(jù)。

當(dāng) B 不再需要連接時(shí)，發(fā)送連接釋放報(bào)文，F(xiàn)IN=1。

A 收到后發(fā)出確認(rèn)，進(jìn)入 TIME-WAIT 狀態(tài)，等待 2 MSL（最大報(bào)文存活時(shí)間）后釋放連接。

B 收到 A 的確認(rèn)后釋放連接。

四次揮手的細(xì)節(jié)

CLOSE-WAIT

客戶端發(fā)送了 FIN 連接釋放報(bào)文之后，服務(wù)器收到了這個(gè)報(bào)文，就進(jìn)入了 CLOSE-WAIT 狀態(tài)。這個(gè)狀態(tài)是為了讓服務(wù)器端發(fā)送還未傳送完畢的數(shù)據(jù)，傳送完畢之后，服務(wù)器會發(fā)送 FIN 連接釋放報(bào)文。

TIME-WAIT

客戶端接收到服務(wù)器端的 FIN 報(bào)文后進(jìn)入此狀態(tài)，此時(shí)并不是直接進(jìn)入 CLOSED 狀態(tài)，還需要等待一個(gè)時(shí)間計(jì)時(shí)器設(shè)置的時(shí)間 2MSL。原因有二：

為保證A發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)B

A發(fā)送的這個(gè)ACK報(bào)文段有可能丟失，如果 B 沒收到 A 發(fā)送來的確認(rèn)報(bào)文，那么A就會重新發(fā)送連接釋放請求報(bào)文，A 等待一段時(shí)間就是為了處理這種情況的發(fā)生。

防止“已經(jīng)失效的連接請求報(bào)文段”出現(xiàn)在本鏈接中

A在發(fā)送完最后一個(gè)ACK報(bào)文段后，再經(jīng)過時(shí)間2MSL，就可以使本連接的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣下一個(gè)新的連接中就不會出現(xiàn)這種舊的連接請求報(bào)文段。

為何建立連接協(xié)議是三次握手，而關(guān)閉連接卻是四次揮手？

因?yàn)榉?wù)端B的LISTEN狀態(tài)下的SOCKET當(dāng)收到SYN報(bào)文的連接請求后，它可以把ACK和SYN（ACK起應(yīng)答作用，而SYN起同步作用）放在一個(gè)報(bào)文里來發(fā)送。但關(guān)閉連接時(shí)，當(dāng)B收到對方A的FIN報(bào)文通知時(shí)，它僅表示客戶端A沒有數(shù)據(jù)發(fā)送給B了；但未必B的數(shù)據(jù)都全部發(fā)送給A了，所以B可能未必會馬上會關(guān)閉SOCKET，而是先發(fā)送一個(gè)ACK應(yīng)答信號，繼續(xù)將剩余的數(shù)據(jù)發(fā)送給A之后，再發(fā)送FIN報(bào)文給A表示B同意現(xiàn)在可以關(guān)閉連接了，所以它這里的ACK報(bào)文和FIN報(bào)文多數(shù)情況下都是分開發(fā)送的。

原文標(biāo)題：TCP的三次握手與四次揮手

文章出處：【微信公眾號：玩轉(zhuǎn)單片機(jī)】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq