說起TCP中最常見最重要的問題當(dāng)然就是“三次握手”、“四次分手”了。在此之前，我們先來預(yù)熱一下TCP的基本知識。

TCP報文段結(jié)構(gòu)

TCP-Header

關(guān)于TCP報文頭部的標(biāo)志位

• URG 緊急指針
• ACK 確認(rèn)序號
• PUSH 接收方應(yīng)當(dāng)盡快將這個報文段交給應(yīng)用層
• RST 重置。重建鏈接
• SYN 同步序號用來發(fā)起一個連接
• FIN 完成發(fā)送

正確理解序號與確認(rèn)號

首先要明白TCP將數(shù)據(jù)看成是一個無結(jié)構(gòu)、有序的字節(jié)流。發(fā)送端的TCP會隱式地對數(shù)據(jù)流中的每一個字節(jié)編號。一個報文段的序號指的是該報文段首字節(jié)的字節(jié)流編號。
舉個例子，假設(shè)主機A上的一個進程向通過一條TCP連接向主機B上的一個進程發(fā)送一個數(shù)據(jù)流。假定數(shù)據(jù)流由一個包含500000字節(jié)的文件組成，其MSS（TCP數(shù)據(jù)包每次能夠傳輸?shù)淖畲髷?shù)據(jù)分段）為1000字節(jié)，數(shù)據(jù)流的首字節(jié)編號是0，該TCP將為該數(shù)據(jù)流構(gòu)建500個報文段，給第一個報文段分配序號0，第二個報文段分配序號1000，第三個分配為2000......每一個序號被填入相應(yīng)的TCP報文段首部的序號字段中。
注意的是，每一個報文段的大小不一定是MSS，而且下一個要發(fā)送的報文段大小還取決于接收方的窗口大小，這在之后的流量控制會談到。

文件數(shù)據(jù)劃分成TCP報文段

現(xiàn)在談一下確認(rèn)號。由于TCP是全雙工通信的，同一條TCP連接的兩端會相互接收和發(fā)送數(shù)據(jù)。當(dāng)主機B收到來自于主機A的一個報文段，需要給主機A回個信息說明已成功收到，這個信息就是確認(rèn)號。
主機B填充進報文段的確認(rèn)號是主機B期望從主機A收到的下一個報文段的序號，或者也可以記憶成：當(dāng)前端成功接收的數(shù)據(jù)位數(shù)。下面舉兩個例子，一個是正常情況下的數(shù)據(jù)傳輸，一個是出現(xiàn)差錯的數(shù)據(jù)傳輸。
情況一，假設(shè)主機B收到了來自主機A的編號為0~535的所有字節(jié)（此報文段序號為0），同時打算發(fā)送一個報文段給主機A，其中的確認(rèn)號字段填充為536。說明主機B等待主機A的數(shù)據(jù)流中字節(jié)編號為536及之后的所有字節(jié)，或者也可以理解為，主機B已經(jīng)成功接收到了536位數(shù)據(jù)。
情況二，假設(shè)主機A向主機B發(fā)送了字節(jié)編號為0-535，536-899，900-1000的三個報文段（報文段序號為0，536,900）。由于某種原因（報文段丟失），主機B沒有收到字節(jié)編號536-899的報文段。那么問題來了，由于第三個報文段失序到達(dá)，該怎么處理呢？如果回復(fù)的確認(rèn)號為1001，會使得主機A認(rèn)為三個報文段均安全到達(dá)，顯然這么做事不合理的。然而對于這種TCP連接中收到的失序報文段，TCPRFC并未明確規(guī)定任何規(guī)則，故需人為實現(xiàn)。現(xiàn)有兩個選擇：
1、立即丟棄失序報文段；
2、保留報文段，并采取合理的方法等待缺失的報文段補齊。
顯然，后者對網(wǎng)絡(luò)帶寬而言更為有效，具體采取什么樣的方法等待補齊，這個問題在后面的TCP重傳機制上會有深刻討論。

為了更好理解序號和確認(rèn)號，可以用WireShark創(chuàng)建一個TCP流的圖形摘要。下面這個摘要圖是從網(wǎng)上copy來的，不過不影響，我們只是用來解讀的。

TCP流摘要圖

接下來就是重復(fù)類似的過程。

小Tip
從上面的圖可以看到，除了第一次握手的報文段SYN之外，其他所有報文段都必須有Ack。為什么呢？
TCP作為一個可靠的傳輸協(xié)議，其可靠性是依賴于收到對方的消息并回復(fù)確認(rèn)給對方，所以任何方發(fā)送的TCP報文段都要捎帶著ACK狀態(tài)位。ACK狀態(tài)位要有Acknowledge Number配合才行。

下面再來補充一下有關(guān)初始化序號的知識點（縮寫為ISN：Inital Sequence Number）

關(guān)于ISN

為什么ISN要動態(tài)隨機？
事實上，一條TCP連接的雙方均可以隨機地選擇初始序號，這樣可以減少將那些仍在網(wǎng)絡(luò)中存在的來自兩臺主機之間先前已經(jīng)終止的連接報文段，誤認(rèn)為是后來這兩臺主機之間新連接所產(chǎn)生的有效報文段的可能性（碰巧與舊連接使用了相同端口號）。
這句話聽起來有點繞口，舉個例子，比如：如果連接建好后始終用1來做ISN，如果client發(fā)了30個segment過去，但是網(wǎng)絡(luò)斷了，于是 client重連，又用了1做ISN，但是之前連接的那些包到了，于是就被當(dāng)成了新連接的包，此時，client的Sequence Number 可能是3，而Server端認(rèn)為client端的這個號是30了。全亂了。
再有，ISN動態(tài)隨機使得每個tcp session的字節(jié)序列號沒有重疊，如果出現(xiàn)tcp五元組沖突這種績效概率情況的發(fā)生，一個session的數(shù)據(jù)也不會被誤認(rèn)為是另一個session的。

ISN會和一個假的時鐘綁在一起，這個時鐘會在每4微秒對ISN做加一操作，直到超過2^32，又從0開始。這樣，一個ISN的周期大約是4.55個小時。因為，我們假設(shè)我們的TCP Segment在網(wǎng)絡(luò)上的存活時間不會超過Maximum Segment Lifetime（縮寫為MSL），所以，只要MSL的值小于4.55小時，那么，我們就不會重用到ISN。

TCP的連接管理

所謂TCP的連接管理也就是“三次握手”、“四次分手”的過程。在這個部分中我們會仔細(xì)的分析如何建立和拆除一條TCP連接。

tcp_open_close

建立連接

其實在前面的序號和確認(rèn)號分析中我們已經(jīng)走了一遍建立連接的三次握手流程，這里做個總結(jié)：

• 第一步：客戶端發(fā)送一個特殊的報文段給服務(wù)器端，該報文段叫SYN報文段（報文段首部僅SYN標(biāo)志位被置1），不含任何應(yīng)用層數(shù)據(jù)。另外，客戶端會隨機選擇一個初始序號x，并將此編號放置于該起始的TCP SYN報文段的序號段中，然后被封裝在一個IP數(shù)據(jù)報中，并發(fā)送給服務(wù)器。
• 第二步：包含TCP SYN報文段的IP數(shù)據(jù)報到達(dá)服務(wù)器主機，服務(wù)器會從該數(shù)據(jù)報中提取SYN報文段，并為該TCP連接分配TCP緩存和變量，同時向客戶端發(fā)送允許連接的報文段，這個報文段稱為SYNACK報文段，也不包含應(yīng)用層數(shù)據(jù)，但其首部包含3個重要的信息。首先SYN標(biāo)志位被置1，其次，確認(rèn)號Ack被置為x+1，最后服務(wù)器選擇自己的初始序號y，并將其放置到TCP報文段首部的序號字段中。
  這個允許連接的報文段實際上表明了：“我收到了你發(fā)起建立連接的SYN分組，該分組帶有初始序號x。我同意建立該連接，我自己的序號是y”。
• 第三步：客戶端在收到SYNACK報文段之后，客戶端也要給該TCP連接分配緩存和變量?？蛻舳讼蚍?wù)器發(fā)送另外一個報文段，表示對服務(wù)器的允許連接進行了確認(rèn)，由于已經(jīng)建立了連接，所以SYN置0（此時可以攜帶有效數(shù)據(jù)了）。三次握手的第三個階段可以在報文段負(fù)載中攜帶客戶到服務(wù)器的數(shù)據(jù)。

關(guān)于TCP3次握手的幾個討論：
1、為什么需要初始化序號？
首先要明白，對于建鏈接的3次握手，實際上在握什么？握的是數(shù)據(jù)原點的序號。通信的雙方要互相通知對方自己的初始化的序號（上面的x和y）。這個號要作為以后的數(shù)據(jù)通信的序號，以保證應(yīng)用層接收到的數(shù)據(jù)不會因為網(wǎng)絡(luò)上的傳輸?shù)膯栴}而亂序（TCP會用這個序號來拼接數(shù)據(jù)）。

2、三次握手的第一次為什么不可以攜帶數(shù)據(jù)？
因為握手還沒成功。
那難道不可以將數(shù)據(jù)緩存下來等握手成功再提交嗎？
不行，這樣容易受到SYN FLOOD攻擊。如果第一次可攜帶數(shù)據(jù)，攻擊者會偽造成千上萬的握手報文，每個報文攜帶大量數(shù)據(jù)，那么接收端要開辟大量內(nèi)存來緩存這些巨大的數(shù)據(jù)，內(nèi)存容易耗盡，從而拒絕服務(wù)。

3、第三次為什么可以攜帶數(shù)據(jù)？
能夠發(fā)出第三次握手報文段的主機肯定接收到了第二次的握手報文段，因為偽造IP的主機是不會收到第二次報文的（為啥呢？）。所以能夠發(fā)出第三次握手報文的主機應(yīng)該是合法用戶。
再次，經(jīng)過三次握手，通信雙方已確認(rèn)初始序列，也為對方開辟了臨時內(nèi)存與變量?？蛻舳税l(fā)出第三次報文段的瞬間進入“ESTABLISHED”狀態(tài)，單方面宣告連接建立，可發(fā)送數(shù)據(jù)，盡管服務(wù)器側(cè)狀態(tài)還沒“建立”，但接收到第三次握手的瞬間就會切換到“ESTABLISHED”，里面攜帶的數(shù)據(jù)就會按正常流程走好。
4、為什么是三次握手而不是兩次或者四次？
試想一下兩次握手的過程：
Client：SYN+Client ISN
Server：SYN+Server ISN+Server Ack
這里有一個問題，Client與Server就Client的初始序列號達(dá)成了一致，但是Server無法知道Client是否收到自己的初始序號和確認(rèn)號，如果丟失，Client與Server就Server的初始序列號無法達(dá)成一致。

于是TCP設(shè)計者將標(biāo)志位SYN（FIN）設(shè)計成占用一個字節(jié)的編號，既然是一個字節(jié)的數(shù)據(jù)，按照TCP對有數(shù)據(jù)的TCP報文段必須確認(rèn)的原則，這里Client必須給Server一個確認(rèn)，以確認(rèn)Client已經(jīng)收到Server的同步信號SYN。

這里還有一個問題，就是如果Client發(fā)給Server的確認(rèn)中途丟失了怎么辦，Client會重傳這個ACK嗎？不會的，TCP不會為不帶數(shù)據(jù)的ACK執(zhí)行重傳！解決的辦法是，Server會重傳自己的SYN同步信號，直至收到Client的ACK信號。

再想想四次握手的過程：
Client：SYN+Client ISN
Server：SYN+Server ISN+Server ACK
Client：SYN+Client ISN+Client ACK
Server：SYN+Server ISN+Server ACK
......
然后沒完沒了了，其實四次和五次六次七次八次是一個道理。
只有三次剛剛好保證數(shù)據(jù)的可靠傳輸和傳輸?shù)男省?br> 下面是一個繪聲繪色的段子供大家理解（來自某乎）：

某乎截圖

斷開連接

對建立連接有了理解之后，斷開連接的道理也就很好懂了。舉個例子，假設(shè)某客戶端打算關(guān)閉連接：

• 第一步：客戶應(yīng)用進程發(fā)出一個關(guān)閉連接命令，這會引起客戶TCP想服務(wù)器進程發(fā)送一個特殊的TCP報文段，稱為FIN報文段（首部只有一個標(biāo)志位FIN置1）。
• 第二步：服務(wù)器收到FIN報文段后就向客戶端會送一個確認(rèn)報文段；
• 第三步：服務(wù)器發(fā)送自己的終止報文段，F(xiàn)IN置為1；
• 第四步：最后，客戶端對這個服務(wù)器的終止報文段進行確認(rèn)，此時，兩臺主機上用于該連接的所有資源都被釋放了。

我們再來分析一下這四次的過程：
Client：FIN ， Server：ACK
Client屬于主動關(guān)閉方，當(dāng)Client收到來自Server的ACK之后，進入半關(guān)閉狀態(tài)，這時候，Client不能再發(fā)送數(shù)據(jù)了。這時Server還可以單向發(fā)送數(shù)據(jù)，Server數(shù)據(jù)發(fā)送完了，也做關(guān)閉動作。

Server：FIN ， Client：ACK
Client收到Server發(fā)送的FIN后，馬上回復(fù)確認(rèn)關(guān)閉ACK，等待2MSL時間后，連接正式關(guān)閉，客戶端所有資源（包括端口號）將被釋放。（為什么需要等待2MSL？下面接著分析）

有個小問題：為什么第二次和第三次分手不合在一起呢？也就是Server的ACK和FIN不一起發(fā)送？
其實，當(dāng)客戶主動請求關(guān)閉連接，說明客戶端已經(jīng)不再請求數(shù)據(jù)了，得到服務(wù)器端的確認(rèn)后，服務(wù)器并沒有馬上發(fā)起自己的關(guān)閉，是因為服務(wù)器端還有一些剩余的數(shù)據(jù)未發(fā)完，直到數(shù)據(jù)發(fā)送完畢后再發(fā)起關(guān)閉動作。

客戶端經(jīng)歷的TCP狀態(tài)序列

其實，網(wǎng)絡(luò)上的傳輸是沒有連接的，包括TCP也是一樣的。而TCP所謂的“連接”，其實只不過是在通訊的雙方維護一個“連接狀態(tài)”，讓它看上去好像有連接一樣。所以，TCP的狀態(tài)變換是非常重要的。
在一個TCP連接的生命周期內(nèi)，運行在每臺主機中的TCP協(xié)議在各種TCP狀態(tài)之間變遷。TCP的狀態(tài)是由TCP報文段的標(biāo)志位控制的。下圖說明了客戶TCP會經(jīng)歷的一系列典型TCP狀態(tài)。

客戶TCP經(jīng)歷的典型的TCP狀態(tài)

現(xiàn)在我們來走一下這個狀態(tài)流程：

• CLOSED-->ESTABLISHED
  客戶TCP開始處于CLOSED（關(guān)閉狀態(tài)），客戶端的應(yīng)用進程發(fā)起一個新的TCP連接，這引起客戶中的TCP向服務(wù)器中的TCP發(fā)送一個SYN報文段，在發(fā)送SYN報文段過后，客戶TCP進入SYN_SENT狀態(tài)。此時客戶TCP等待來自服務(wù)器TCP的對客戶所發(fā)送報文段進行確認(rèn)且SYN被置1的一個報文段。收到這個報文段之后，客戶TCP單方面進入ESTABLISHED（已建立）狀態(tài)。當(dāng)處在ESTABLISHED狀態(tài)時，TCP客戶就能發(fā)送和接收包含有效載荷數(shù)據(jù)（即應(yīng)用層產(chǎn)生的數(shù)據(jù)）的TCP報文段了。

• ESTABLISHED-->CLOSED
  假設(shè)客戶應(yīng)用進程決定關(guān)閉該連接（注意到服務(wù)器也能選擇關(guān)閉該連接）。這引起客戶TCP發(fā)送一個FIN特殊報文段，并進入FIN_WAIT_1狀態(tài)，等待一個來自服務(wù)器帶有確認(rèn)的TCP報文段。當(dāng)收到該報文段時，客戶TCP進入FIN_WAIT_2狀態(tài)，此時客戶TCP處于半關(guān)閉狀態(tài)，不能再發(fā)送數(shù)據(jù)了。處于FIN_WAIT_2狀態(tài)的客戶TCP等待來自服務(wù)器的FIN特殊報文段，當(dāng)收到該報文段后，客戶TCP對服務(wù)器進行確認(rèn)，并進入TIME_WAIT狀態(tài)。經(jīng)過2MSL等待之后，連接正式關(guān)閉，客戶端釋放所有資源。

  
  
  關(guān)閉一條TCP連接

現(xiàn)在來解釋一下為什么主動關(guān)閉方最后為什么要等待2MSL之后才關(guān)閉連接？
主要有兩點：
（1）可靠的實現(xiàn)TCP全雙工連接的終止；
（2）語序來到重復(fù)的分節(jié)在網(wǎng)絡(luò)中消逝；
先說第一點，當(dāng)客戶端發(fā)送ACK確認(rèn)報文段給服務(wù)器之后，客戶端無法得知服務(wù)器是否收到ACK，所以我們定一個規(guī)則：在客戶端發(fā)送ACK確認(rèn)報文段之后的2MSL的期間內(nèi)未收到服務(wù)器發(fā)送的FIN報文段，則認(rèn)為服務(wù)器已成功接收到了該ACK確認(rèn)報文段，所以TCP連接可完全關(guān)閉。
為什么是2MSL呢？這只是一個保守的估計時間。所謂MSL是Maximum Segment Life，這是TCP 對TCP Segment 生存時間的限制，任何報文段在丟棄之前在網(wǎng)絡(luò)中內(nèi)的最大生存時間。假如ACK沒有到達(dá)服務(wù)端，服務(wù)端會為FIN這個消息超時重傳 timeout retransmit ，那如果客戶端等待時間足夠，又收到FIN消息，說明ACK沒有到達(dá)服務(wù)端，于是再發(fā)送ACK，直到在足夠的時間內(nèi)沒有收到FIN，說明ACK成功到達(dá)。這個等待時間至少是：服務(wù)端的timeout + FIN的傳輸時間，為了保證可靠，采用更加保守的等待時間2MSL。

再說第二點，如果Client直接CLOSED，然后又再向Server發(fā)起一個新連接，我們不能保證這個新連接與剛關(guān)閉的連接的端口號是不同的。也就是說有可能新連接和老連接的端口號是相同的。一般來說不會發(fā)生什么問題，但是還是有特殊情況出現(xiàn)：假設(shè)新連接和已經(jīng)關(guān)閉的老連接端口號是一樣的，如果前一次連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡(luò)中，這些延遲數(shù)據(jù)在建立新連接之后才到達(dá)Server，由于新連接和老連接的端口號是一樣的，又因為TCP協(xié)議判斷不同連接的依據(jù)是socket pair，于是，TCP協(xié)議就認(rèn)為那個延遲的數(shù)據(jù)是屬于新連接的，這樣就和真正的新連接的數(shù)據(jù)包發(fā)生混淆了。所以TCP連接還要在TIME_WAIT狀態(tài)等待2倍MSL，這樣可以保證本次連接的所有數(shù)據(jù)都從網(wǎng)絡(luò)中消失。

服務(wù)器經(jīng)歷的TCP狀態(tài)序列

服務(wù)器TCP經(jīng)歷的典型TCP狀態(tài)

服務(wù)器的TCP狀態(tài)比較好解釋，大家可以對著圖自行理解。

至此，關(guān)于TCP的一點點點點知識算是講完了，不過后續(xù)的還有流量控制，擁塞控制等等，敬請關(guān)注！
推薦公眾號：車小胖談網(wǎng)絡(luò)