個人主頁 ： 個人主頁
個人專欄 ： 《數(shù)據(jù)結(jié)構(gòu)》 《C語言》《C++》《Linux》《網(wǎng)絡(luò)》

---

前言

本文是我對于TCP協(xié)議-報頭字段的知識總結(jié)

---

一、TCP協(xié)議格式

16位源端口號 和 16位目的端口號

16位源端口號：標(biāo)識發(fā)送方應(yīng)用程序的端口號，是一個16位的字段。通過源端口和目的端口，可以唯一確定一個TCP連接。
16位目的端口號：標(biāo)識接收方應(yīng)用程序的端口號，同樣是一個16位的字段。與源端口一起，用于確定數(shù)據(jù)應(yīng)被哪個應(yīng)用程序接收。

4位首部長度

TCP協(xié)議如何解決 報頭和有效載荷分離的問題？ 其中 報頭 為 TCP標(biāo)準(zhǔn)報頭長度(20字節(jié)) + 選項。
TCP標(biāo)準(zhǔn)報頭長度是固定長度好分離，但選項的長度不確定，該怎么辦？
4位首部長度表示 TCP標(biāo)準(zhǔn)報頭 + 選項 的大小。
4位首部長度的取值范圍為[ 0000, 1111 ]轉(zhuǎn)化為10進(jìn)制也就是[ 0, 15 ]，那這不還沒有TCP標(biāo)準(zhǔn)報頭長度大嗎？我們還規(guī)定首部長度的基本單位是4字節(jié)，也就說4位首部長度的取值范圍是[ 0, 60 ]，選項最多40個字節(jié)。
現(xiàn)在我們算一下TCP標(biāo)準(zhǔn)報頭的4位首部長度，TCP標(biāo)準(zhǔn)報頭是20字節(jié)，那4位首部長度是5，轉(zhuǎn)化為2進(jìn)制就是0101 。
注意：TCP的報頭長度必須是4的整數(shù)倍，因為基本單位是4字節(jié)。

16位窗口大小

• 16位窗口大小：表示接收方愿意并能夠接收多少數(shù)據(jù)。用于實現(xiàn)TCP的流量控制機(jī)制。

那我們?nèi)绾卫斫?6位窗口大小？我們先看下圖。

我們都知道，TCP具有發(fā)送和接受緩沖區(qū)，即TCP是全雙工通信。發(fā)送數(shù)據(jù)就是把數(shù)據(jù)拷貝到操作系統(tǒng)內(nèi)的發(fā)送緩沖區(qū)，再從發(fā)送緩沖區(qū)到接收方的接受緩沖區(qū)。

那如果發(fā)送方一直瘋狂的向接收方發(fā)送數(shù)據(jù)，此時發(fā)送方不清楚接收方的接受能力(接受緩沖區(qū)的剩余空間大小為接受能力)，發(fā)送方發(fā)送數(shù)據(jù)太快，導(dǎo)致接收方來不及接受數(shù)據(jù)，接收方的接受緩沖區(qū)滿了。發(fā)送方還是發(fā)送數(shù)據(jù)，那接收方接受到數(shù)據(jù)，就會直接丟棄。雖然TCP有重傳機(jī)制，可以重新發(fā)送數(shù)據(jù)，保證可靠性。但這不合理且不高效，數(shù)據(jù)千辛萬苦從網(wǎng)絡(luò)到接收方，接收方卻直接丟棄了。

那要如何使這樣的情況合理？如果接收方來不及接受數(shù)據(jù)了，發(fā)送方就慢點發(fā)，甚至等會再發(fā)。我們把這種如果對方來不及接受，就要求發(fā)送方發(fā)送變慢，甚至停止發(fā)送的策略，叫做流量控制。
對于流量控制的前提是：發(fā)送方可以知道接收方的接受能力。那發(fā)送方有如何知道接收方的接受能力呢？

這就要先簡單的看看確認(rèn)應(yīng)答機(jī)制了。如 client給server發(fā)送一條消息，TCP為了保證可靠性，要求接收方對發(fā)送方發(fā)過來的消息進(jìn)行確認(rèn)，即只要client收到server發(fā)送的確認(rèn)，client就會認(rèn)為server收到 “hello” 這條消息，保證client 到 server 的可靠性。

要注意其中"hello"這條消息是TCP報文。

現(xiàn)在發(fā)送方每發(fā)送一條消息，都會收到接收方的應(yīng)答消息。那么發(fā)送方就可以從應(yīng)答消息中的16位窗口大小來判斷，接收方的接受能力，從而避免發(fā)送方發(fā)送的數(shù)據(jù)因為接收方緩沖區(qū)滿了，而直接丟棄的問題。
注意：16位窗口大小，是指自身的接受緩沖區(qū)中剩余空間的大小。

32位序號 和 32位確認(rèn)序號

我們先來看兩種TCP發(fā)送數(shù)據(jù)的方式：

先看串行發(fā)送，client每發(fā)送一條數(shù)據(jù)后，必須得到server發(fā)送的ACK，才能繼續(xù)發(fā)送數(shù)據(jù)。這樣client可以清晰的知道每個ACK對應(yīng)的是那條數(shù)據(jù)。這樣雖然保證了可靠性，但效率低。

再看并行發(fā)送，client可以一次發(fā)送多條數(shù)據(jù)，那么server也要發(fā)送對應(yīng)數(shù)量的應(yīng)答給client(原則上要求server對每一條消息做出應(yīng)答)。這樣client發(fā)送時間，進(jìn)行了重疊，效率得到提升。但這也引來了幾個問題。

• client怎么知道那個ACK是哪個發(fā)送數(shù)據(jù)的應(yīng)答？如果client接受到的ACK與發(fā)送數(shù)據(jù)數(shù)量相同，那至少表明client發(fā)送的數(shù)據(jù)，server都收到了。但如果client收到的ACK數(shù)量少于發(fā)送數(shù)據(jù)的數(shù)量呢？此時client就不清楚那個發(fā)送數(shù)據(jù)沒有被server接受到。
• 因為網(wǎng)絡(luò)環(huán)境復(fù)雜，server接受到數(shù)據(jù)的順序不一定是按照client發(fā)送數(shù)據(jù)的順序。此時，如果client把報文分兩次發(fā)送，server就有可能先收到數(shù)據(jù)，再收到報頭；這就不可靠了。

對于上面兩個問題，我們可以對發(fā)送的數(shù)據(jù) 和 ACK 進(jìn)行編號。

此時client就可以根據(jù)每個ACK的編號，來確定哪個發(fā)送數(shù)據(jù)被server接受到了。而server也可以根據(jù)發(fā)送數(shù)據(jù)的序號，進(jìn)行排序，從而保證數(shù)據(jù)的按序到達(dá)。

上面的序號就是 32位序號 和 32位確認(rèn)序號。

• 32位序號：用于對TCP報文段進(jìn)行編號和排序。每個TCP報文段都有一個唯一的序列號，確保數(shù)據(jù)的唯一性和可識別性。
• 32位確認(rèn)序號：用于標(biāo)識接收端確認(rèn)收到的數(shù)據(jù)段。它是成功收到的數(shù)據(jù)序列號加1，表示接收端已經(jīng)成功接收了序列號小于該確認(rèn)序號的所有數(shù)據(jù)。

注意：32位確認(rèn)序號還表示，確認(rèn)序號之前的所有的報文已經(jīng)被對方全部收到了。為什么要這樣規(guī)定？允許少量報文的丟失，提高了效率。
如上圖，如果server發(fā)送的3個ACK，只有序號為301的ACK被client接受到了，那client就會認(rèn)為發(fā)送的3條數(shù)據(jù)都被server接受到了，效率提升了。

那這里，我們可能會有一個問題？32位序號 和 32位確認(rèn)序號 可以同一個字段嗎？答案是不能。

向上圖，client 和 server互相發(fā)送信息。在情況1 server對client的回應(yīng)是發(fā)送兩條信息，那server可不可以將這兩條信息作為一條信息發(fā)送？要知道發(fā)送的消息都是完整的TCP報文，而ACK只是一個ACK標(biāo)志位置1的報頭，那將報頭和 “hello” 數(shù)據(jù)合并不也是一個完整報文嗎？這樣不僅對client發(fā)送的"hello"進(jìn)行了應(yīng)答，而且還對client的信息進(jìn)行了回復(fù)。這些效率進(jìn)行了提升。像這樣報文大都既是數(shù)據(jù)(需要32位序號，保證按序到達(dá))，又是對歷史報文的確認(rèn)(需要32位確認(rèn)序號)，32位序號 和 32位確認(rèn)序號 同事使用，不能是同一個字段。

6種標(biāo)記位 和 16位緊急指針

我們知道一個server會被多個client連接，這么多連接，總會有不同的鏈接請求。

即server一定會同時收到各種各樣不同類型的TCP報文，也就表示報文要有類型，如何表示報文的類型？TCP中是6種標(biāo)記位來表示報文類型。

• URG：緊急指針是否有效
• ACK：確認(rèn)序號是否有效
• PSH：提示接收端應(yīng)用程序立刻從TCP緩沖區(qū)把數(shù)據(jù)讀走
• RST：對方要求重新建立連接，我們把攜帶RST標(biāo)識的稱為復(fù)位報文段
• SYN：請求建立連接；我們把攜帶SYN標(biāo)識的稱為同步報文段
• FIN：通知對方，本端要關(guān)閉了，我們稱攜帶FIN標(biāo)識的為結(jié)束報文段

這里我們介紹URG，PSH，RST。

---

URG 和 16位緊急指針

在client 和 server 雙方通訊時，TCP報文要按照32位序號排序，按序處理，也就是排隊。如果此時 服務(wù)器通訊雙方有一些緊急數(shù)據(jù)時，因為TCP報文是有序號的，那該緊急數(shù)據(jù)也要按序處理嗎？這就不好了，我們應(yīng)該盡快處理緊急數(shù)據(jù)，即該報文要提前處理，也就是要插隊。
此時，我們就需要 URG 和 16位緊急指針。

• URG標(biāo)記位被置 1 ，表示該報文是緊急報文
• 16位緊急指針表示，在當(dāng)前報文中，緊急數(shù)據(jù)在有效載荷中的偏移量

注意：只有URG無效，16位緊急指針也就無效；只有URG被置1,16位緊急指針也要被查看

這就有一個問題。緊急數(shù)據(jù)的大小是多少？畢竟16位緊急指針只是給了一個地址，并沒有給緊急數(shù)據(jù)有多少個字節(jié)。答案是 1個字節(jié)。
緊急任務(wù)都有哪些？

---

PSH

當(dāng)client 給 server 發(fā)送 “hello” 時，server要給 client 發(fā)送 ACK；但不僅僅只發(fā)送 ACK 還會同步 窗口大小。比較發(fā)送的是一個完整報文。
如果server因為上層http 處理一個比較耗時的任務(wù)，導(dǎo)致進(jìn)程卡主了。client 給 server 發(fā)送 “hello”， server 給 client 發(fā)送 ACK ，同時更新窗口大小為 0；

此時表示，server的接受緩沖區(qū)滿了，client知道不能發(fā)送消息了，只能等待。那以后client 如何知道 server 緩沖區(qū)的情況，這會不會出現(xiàn)雙方互相等待的情況？
并不會，此時client會定期向server發(fā)送詢問報文(只有報頭)，根據(jù)TCP的確認(rèn)應(yīng)答機(jī)制，server要給client發(fā)送ACK(攜帶了server的窗口大小)。同時 當(dāng)上層將接受緩沖區(qū)的數(shù)據(jù)取走，也就是server接受緩沖區(qū)的剩余空間 從 0 變?yōu)?非0。server 會主動給client發(fā)送窗口大小更新報文。

上面兩種策略同時使用，那種方式先被client收到，client就會繼續(xù)發(fā)送信息。

其中，client發(fā)送的詢問報文，就是一個PSH標(biāo)記位被置1的報頭。

注意：PSH不僅僅使用在上述場景中，在所有數(shù)據(jù)需要盡快交付的場景下，都可以使用。如Linux的指令輸入

---

RST

我們知道TCP通訊的前提，必須進(jìn)行三次握手。這里有個問題，TCP是保證可靠性的，那是不是三次握手必須成功？不是，三次握手可能失敗。那TCP保證可考性是怎么回事，該可靠性不是保證數(shù)據(jù)100%發(fā)送到，而是數(shù)據(jù)被接收方收到，發(fā)送方要知道；數(shù)據(jù)發(fā)送出現(xiàn)問題，發(fā)送方也要知道。

現(xiàn)在我們以三次握手出現(xiàn)問題為例，介紹RST出現(xiàn)場景。

我們先要知道對于client 和 server 來說， 什么時候，連接建立好了。

• 對于client，是發(fā)出ACK就認(rèn)為連接建立好了
• 對于server，是要收到client發(fā)送的ACK，才認(rèn)為連接建立好了

注意：這里client 和 server 認(rèn)為建立好鏈接有一定的時間差

了解上面這點，我們再往下看。其中SYN 和 SYN + ACK 如果丟包，我們不擔(dān)心。因為SYN 和 SYN + ACK都有對應(yīng)的應(yīng)答，但 ACK 如果丟失，就不好辦了。如果client發(fā)送的ACK丟包了，但client認(rèn)為TCP連接已經(jīng)建立好了，而server因為還沒有收到client的ACK，認(rèn)為還沒有建立TCP鏈接。這就存在了 連接建立認(rèn)知不一致 。此時client給server發(fā)送數(shù)據(jù)，server會給client發(fā)送一個重新建立鏈接的報文(RST標(biāo)記位被置1 的報文)，此時client會知道發(fā)送的ACK丟包了，會重新建立鏈接。

還有很多其它例子。

---

下圖就是linux-2.6.11.10中tcp的報頭字段

---

總結(jié)

TCP保證可靠性，但又不僅僅保證可靠性，還會進(jìn)行各種提高效率的設(shè)定。
以上就是我對于TCP協(xié)議的知識總結(jié)