【當(dāng)前熱聞】TCP協(xié)議詳解 一文讀懂TCP協(xié)議段格式

文章目錄

TCP協(xié)議段格式TCP原理確認(rèn)應(yīng)答機制超時重傳機制連接管理機制三次握手：四次揮手： 滑動窗口如果出現(xiàn)丟包，如何進行重傳？ 流量控制擁塞控制延遲應(yīng)答捎帶應(yīng)答 粘包問題TCP異常情況 TCP，即Transmission Control Protocol，傳輸控制協(xié)議，對數(shù)據(jù)的傳輸進行詳細(xì)的控制。

【資料圖】

TCP協(xié)議段格式

源/目的端口號：表示數(shù)據(jù)從哪個進程來，到那個進程去。 源端口號表示報文的發(fā)送端口，源端口號和源IP地址組合起來可以表示報文的發(fā)送地址。 目的端口表示報文的接收端口，目的端口和目的IP地址組合起來可以表示報文的接收地址。 TCP協(xié)議就是根據(jù)IP協(xié)議的基礎(chǔ)上傳輸?shù)模琓CP報文中的源端口號+源IP，與TCP報文中的目的端口號+目的IP一起，組合起來唯一性的確定一條TCP連接。 序號（Sequence Number）：TCP傳輸過程中，在發(fā)送端出的字節(jié)流中，傳輸報文中的數(shù)據(jù)部分的每一個字節(jié)都有它的編號。序號（Sequence Number）占32位，發(fā)起方發(fā)送數(shù)據(jù)時，都需要標(biāo)記序號。 在數(shù)據(jù)傳輸過程中，TCP協(xié)議通過序號（Sequence Number）對上層提供有序的數(shù)據(jù)流。發(fā)送端可以用序號來跟蹤發(fā)送的數(shù)據(jù)量；接收端可以用序號識別出重復(fù)接收到的TCP包，從而丟棄重復(fù)包；對于亂序的數(shù)據(jù)包，接收端也可以依靠序號對其進行排序。 序號會根據(jù)SYN是否為1，表示不同的意思： 當(dāng)SYN為1時，當(dāng)前為建立連接階段； 當(dāng)SYN為0是，數(shù)據(jù)傳輸正式開始。 確認(rèn)序號（Acknowledgment Number）：確認(rèn)序號標(biāo)識了報文接收端期望接收的字節(jié)序列。如果設(shè)置了ACK控制位，確認(rèn)序號的值表示一個準(zhǔn)備接收的包的序列號，注意，它所指向的是準(zhǔn)備接收的包，也就是下一個期望接收的包的序列號。 4位TCP報頭長度：表示TCP頭部有多少個32位bit（4字節(jié)）；所以TCP頭部最大長度為 15 * 4 = 60字節(jié)。 6位標(biāo)志位：

URG：緊急指針是否有效；ACK：確認(rèn)號是否有效，ACK置 1 ，代表起到了確認(rèn)作用，需要填寫確認(rèn)序列號（下一次期望收到第一個字節(jié)的序列號）；PSH：提示接收端應(yīng)用程序立刻從TCP緩沖區(qū)把數(shù)據(jù)讀走；RST：對方要求重新建立連接，我們把攜帶RST標(biāo)識的稱為復(fù)位報文段；SYN：請求建立連接，我們把攜帶SYN標(biāo)識的成為同步報文段；FIN：通知對方，本端要關(guān)閉了，我們稱攜帶FIN標(biāo)識的為結(jié)束報文段。

窗口大小：長度為16位，共2個字節(jié)。此字段用來進行流量控制。流量控制的單位為字節(jié)數(shù)，這個值是本端期望一次接收的字節(jié)數(shù)。 １６位校驗和：發(fā)送端填充，CRC校驗。接收端校驗不通過，則認(rèn)為數(shù)據(jù)有問題，此處的檢驗和不光包含TCP首部，也包含TCP數(shù)據(jù)部分。 16位緊急指針：標(biāo)識那部分?jǐn)?shù)據(jù)是緊急數(shù)據(jù)。

TCP原理

TCP對數(shù)據(jù)傳輸提供的管控機制，主要體現(xiàn)在兩個方面：安全、效率。 這些機制和多線程的設(shè)計原則類似：保證數(shù)據(jù)傳輸?shù)陌踩疤嵯拢M可能地提高傳續(xù)效率。

確認(rèn)應(yīng)答機制

TCP將每個字節(jié)的數(shù)據(jù)進行了編號，即序列號。 每一個ACK都帶有對應(yīng)的確認(rèn)序列號，意思是告訴發(fā)送者，我已經(jīng)收到了那些數(shù)據(jù)，下一次你從哪里開始給我發(fā)。

超時重傳機制

主機A給主機B發(fā)送了數(shù)據(jù)之后，可能會因為網(wǎng)絡(luò)擁堵等原因，數(shù)據(jù)無法發(fā)送到B，如果A在一個特定的時間間隔內(nèi)沒有收到B發(fā)來的確認(rèn)應(yīng)答，就會重新發(fā)送。 當(dāng)然，A沒有收到確認(rèn)應(yīng)答，也可能是ACK丟了。因此，主機B會收到很多重復(fù)數(shù)據(jù)，可以利用序列號做到去重的效果。 那么超時時間如何確定？

TCP為了保證無論在任何環(huán)境下都能比較高效地通信，因此會動態(tài)計算這個最大超時時間。

連接管理機制

在正常情況下，TCP要經(jīng)過三次握手建立連接，四次揮手?jǐn)嚅_連接

三次握手：

第一次握手：客戶端進入SYN_SENT狀態(tài)，發(fā)送一個SYN幀來主動打開傳輸通道，該幀的SYN標(biāo)志位被設(shè)置為1，同時會帶上Client分配好的SN序列號，該SN是根據(jù)時間產(chǎn)生的一個隨機值。第二次握手：服務(wù)端在收到SYN幀之后，會進入SYN_RCVD狀態(tài)，同時返回SYN+ACK幀給客戶端，主要目的在于通知客戶端，服務(wù)端已經(jīng)收到SYN消息，現(xiàn)在需要進行確認(rèn)。 服務(wù)端發(fā)出的SYN+ACK幀的ACK標(biāo)志位被設(shè)置為1，其確認(rèn)序號ASN值被設(shè)置為客戶端的SN+1；SYN+ACK幀的SYN標(biāo)志位被設(shè)置為1，SN值為服務(wù)端生成的SN序號。第三次握手：客戶端在收到服務(wù)端的第二次握手的SYN+ACK確認(rèn)幀之后，首先將自己的狀態(tài)會從SYN_SENT變成ESTABLISHED，表示自己方向的連接通道已經(jīng)建立成功，客戶端可以發(fā)送數(shù)據(jù)給服務(wù)端了。然后，客戶端發(fā)ACK幀給服務(wù)端，該ACK幀的ACK標(biāo)志位被設(shè)置為1，其確認(rèn)序號ASN值被設(shè)置為服務(wù)端的SN序列號+1。服務(wù)端收到客戶端的ACK之后，會從SYN_RCVD狀態(tài)變成ESTABLISHED狀態(tài)，至此，TCP全雙工連接建立完成。

四次揮手：

第一次揮手：主動斷開方向?qū)Ψ桨l(fā)送一個FIN結(jié)束請求報文，此報文的FIN位被設(shè)置為1，發(fā)送完成后，主動斷開方進入FIN_WAIT_1狀態(tài)，這表示主動斷開方?jīng)]有業(yè)務(wù)數(shù)據(jù)要發(fā)送給對方，準(zhǔn)備關(guān)閉SOCKET連接了。第二次揮手：正常情況下，在收到了主動斷開方發(fā)送的FIN斷開請求報文后，被動斷開方會發(fā)送一個ACK響應(yīng)報文，之后，被動斷開方就進入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)，TCP協(xié)議服務(wù)會通知高層的應(yīng)用進程，對方向本地方向的連接已經(jīng)關(guān)閉，對方已經(jīng)沒有數(shù)據(jù)要發(fā)送了，若本地還要發(fā)送數(shù)據(jù)給對方，對方依然會接受。被動斷開方的CLOSE-WAIT（關(guān)閉等待）還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。第三次揮手：在發(fā)送完成ACK報文后，被動斷開方還可以繼續(xù)完成業(yè)務(wù)數(shù)據(jù)的發(fā)送，待剩余數(shù)據(jù)發(fā)送完成后，或者CLOSE-WAIT（關(guān)閉等待）截止后，被動斷開方會向主動斷開方發(fā)送一個FIN+ACK結(jié)束響應(yīng)報文，表示被動斷開方的數(shù)據(jù)都發(fā)送完了，然后，被動斷開方進入LAST_ACK狀態(tài)。第四次揮手：主動斷開方收在到FIN+ACK斷開響應(yīng)報文后，還需要進行最后的確認(rèn)，向被動斷開方發(fā)送一個ACK確認(rèn)報文，然后，自己就進入TIME_WAIT狀態(tài)，等待超時后最終關(guān)閉連接。處于TIME_WAIT狀態(tài)的主動斷開方，在等待完成2MSL的時間后，如果期間沒有收到其他報文，則證明對方已正常關(guān)閉，主動斷開方的連接最終關(guān)閉。 被動斷開方在收到主動斷開方的最后的ACK報文以后，最終關(guān)閉了連接。

TCP狀態(tài)轉(zhuǎn)換匯總：

滑動窗口

剛才我們討論了確認(rèn)應(yīng)答策略，對每一個發(fā)送的數(shù)據(jù)段，都要給一個ACK確認(rèn)應(yīng)答。收到ACK后再發(fā)送下一個數(shù)據(jù)段。這樣做有一個比較大的缺點，就是性能較差。尤其是數(shù)據(jù)往返的時間較長的時候。 既然這樣一發(fā)一收的方式性能較低，那么我們一次發(fā)送多條數(shù)據(jù)，就可以大大的提高性能（其實是將多個段的等待時間重疊在一起了）。

如果出現(xiàn)丟包，如何進行重傳？

情況一：數(shù)據(jù)包已經(jīng)抵達，ACK被丟了

情況二：數(shù)據(jù)包就直接丟了

流量控制

接收端處理數(shù)據(jù)的速度是有限的。如果發(fā)送端發(fā)的太快，導(dǎo)致接收端的緩沖區(qū)被打滿，這個時候如果發(fā)送端繼續(xù)發(fā)送，就會造成丟包，繼而引起丟包重傳等等一系列連鎖反應(yīng)。 因此TCP支持根據(jù)接收端的處理能力，來決定發(fā)送端的發(fā)送速度。這個機制就叫做流量控制（Flow Control）。

接收端如何把窗口大小告訴發(fā)送端呢？回憶我們的TCP首部中，有一個16位窗口字段，就是存放了窗口大小信息。

擁塞控制

TCP引入 慢啟動 機制，先發(fā)少量的數(shù)據(jù)，探探路，摸清當(dāng)前的網(wǎng)絡(luò)擁堵狀態(tài)，再決定按照多大的速度傳輸數(shù)據(jù)。慢啟動，只是初始時慢，增長的很快

少量的丟包，我們僅僅是觸發(fā)超時重傳；大量的丟包，我們就認(rèn)為網(wǎng)絡(luò)擁塞; 當(dāng)TCP通信開始后，網(wǎng)絡(luò)吞吐量會逐漸上升；隨著網(wǎng)絡(luò)發(fā)生擁堵，吞吐量會立刻下降; 擁塞控制，歸根結(jié)底是TCP協(xié)議想盡可能快的把數(shù)據(jù)傳輸給對方，但是又要避免給網(wǎng)絡(luò)造成太大壓力的折中方案。

延遲應(yīng)答

如果接收數(shù)據(jù)的主機立刻返回ACK應(yīng)答，這時候返回的窗口可能比較小。

每隔N個包就要應(yīng)答一次，或者超過最大應(yīng)答時間也要應(yīng)答一次。 N一般取2，超時時間取200ms。 窗口越大，網(wǎng)絡(luò)吞吐量就越大，傳輸效率就越高。我們的目標(biāo)是在保證網(wǎng)絡(luò)不擁塞的情況下盡量提高傳輸效率。

捎帶應(yīng)答

粘包問題

對于定長的包，保證每次都按固定大小讀取即可；例如上面的Request結(jié)構(gòu)，是固定大小的，那么就從緩沖區(qū)從頭開始按sizeof（Request）依次讀取即可；對于變長的包，可以在包頭的位置，約定一個包總長度的字段，從而就知道了包的結(jié)束位置；對于變長的包，還可以在包和包之間使用明確的分隔符。

TCP異常情況

進程終止：進程終止會釋放文件描述符，仍然可以發(fā)送FIN。和正常關(guān)閉沒有什么區(qū)別。 機器重啟：和進程終止的情況相同。 機器掉電/網(wǎng)線斷開：接收端認(rèn)為連接還在，一旦接收端有寫入操作，接收端發(fā)現(xiàn)連接已經(jīng)不在了，就會進行reset。即使沒有寫入操作，TCP自己也內(nèi)置了一個保活定時器，會定期詢問對方是否還在。如果對 方不在，也會把連接釋放。

另外，應(yīng)用層的某些協(xié)議，也有一些這樣的檢測機制。例如HTTP長連接中，也會定期檢測對方的狀態(tài)。 例如QQ，在QQ斷線之后，也會定期嘗試重新連接。

TCP ： 可靠、有連接、面向字節(jié)流