TCP

? 之前我們已經提到過TCP/IP五層模型，TCP協議屬于傳輸層協議，其是以太網協議和 IP 協議的上層協議，也是應用層協議的下層協議，同時，我們簡單的知道，資料從應用層發下來，會在每一層都會加上頭部資訊，進行封裝，然后再發送到資料接收端，這次，我將詳細給大家講解一下TCP的報文資料格式，

1. TCP欄位

首先，我們先來看一下 TCP 的報文格式

下面分別對其中的欄位進行介紹

1.1 埠號

• 源埠:源埠和IP地址的作用是標識報文的回傳地址，
• 目的埠:指明接收方計算機上的應用程式介面，

其各占2個位元組，這兩個值加上IP首部中的源端IP地址和目的端IP地址唯一確定一個TCP連接，

1.2 序號(seq)

? 占4個位元組，是本報文段所發送的資料專案組第一個位元組的序號，在TCP傳送的資料流中，每一個位元組都有一個序號，例如，一報文段的序號為500，而且資料共500位元組，則下一個報文段的序號就是1000(500+500=1000),其確保了TCP傳輸的有序性，之后將講到其作用，

1.3 確認序號(ack)

? 占4位元組，是期望收到對方下次發送的資料的第一個位元組的序號，也就是期望收到的下一個報文段的首部中的序號；確認序號應該是上次已成功收到資料位元組序號+1，只有ACK標志為1時，確認序號才有效，

1.4 資料偏移

? 占4位元，表示資料開始的地方離TCP段的起始處有多遠，實際上就是TCP段首部的長度，由于首部長度不固定，因此資料偏移欄位是必要的，資料偏移以32位為長度單位，也就是4個位元組，因此TCP首部的最大長度是60個位元組，即偏移最大為15個長度單位=1532位=154位元組，

1.5 保留

6位元，供以后應用，現在置為0，

1.6 6個標志位

1.7 校驗和

? 奇偶校驗，此校驗和是對整個的 TCP 報文段，包括 TCP 頭部和 TCP 資料，以 16 位字進行計算所得，由發送端計算和存盤，并由接收端進行驗證，

1.8 視窗大小

這個將在下一節結合滑動視窗重點介紹！！！

其余部分暫不介紹

在網路中，我們發送資料需要考慮到以下問題：

• 我們發送的資料對方是否能收到？
• 如果收到，收到的資料有沒有發送錯誤？
• 如果發送多條資料，對方接收的順序是否按照發送的順序？
• 如果接收方收到了多條重復資料，是否能丟掉重復資料？

接下來，將給大家講解TCP協議如何解決這些問題

2. 重點分析

2.1 序號和確認序號

假設現在A同學想去B同學家里玩游戲，于是他給B同學發訊息，如果訊息沒有出現錯誤且順序正確，結果如下所示

但是，由于資料的長度不同或者傳輸網路不同，先發送的資料不一定先到達，也就是說，接收方接收到的資料可能是亂序的，所以可能出現下面這種情況

? 如果訊息正確且順序正確，那么A同學就能找B同學玩游戲了，但是如果出現了第二種情況，那么A同學就不能找B同學玩游戲了，為了避免出現這種問題，在TCP中就引入了序號、確認序號的欄位，如下所示，A同學的訊息標注了序號，B同學在回復時訊息時，將帶上其回復的是A同學哪序號對應的訊息，這就保證了訊息的傳輸的準確性，

但是，真正的序號和確認序號不是這么簡單

序號(seq)

• 初始序號是隨機的，為了防止網路攻擊
• 如果發送多個資料，每個資料都會帶著一個序號

確認序號(ack)

• 接收方收到資料后，是知道資料所帶著的序號的，根據序號給出確認序號（告訴發送方下次給我發的序號），發送給發送方，發送方就知道接收方收到了哪些資料

真正的傳輸，如下所示，(初始序號125為隨機值)

2.2 確認應答和超時重傳

同樣，假設現在A同學想去B同學家里玩游戲，于是他給B同學發訊息，你在家嗎？但是A同學沒有收到回復的訊息，那么B同學可能會有以下幾種情況

• B同學不想回A同學訊息
• B同學沒收到訊息
• B同學回復了訊息A同學沒收到

如果B同學回復了，且回復了A同學，那么這就是類似于確認應答機制，當主機B收到主機A發送的資料后，會給主機A回一個ACK，表示我收到了你的資料，并且向主機A發送ASN，告訴主機A我希望你下次發送的序號，

對于上述的后兩種情況，由于不知道B同學是否收到訊息，所以A同學在等待十分鐘后，再次給B同學發了條同樣的訊息，這就類似于超時重傳，

如果是第一種情況，B同學將洗掉A同學發送的訊息的其中一個，只保留一份，這就類似于TCP協議丟掉重復發送的資料，

2.3 建立連接-三次握手

? 為了保證連接的正常，TCP采用“三次”握手機制，舉個類似的例子，這次以A同學給B同學打電話為例，想要確保雙方都能聽到對方的話，剛開始需要以下程序

• 第一次握手：剛開始，由于A同學不知道自己和B同學 手機的聽筒和麥克風是否正常，所以A同學說“你能聽到嗎?”
• 第二次握手：B同學聽到后，說明A同學的麥克風和B同學的聽筒正常，但是B同學不知道A同學的聽筒和自己的麥克風是否正常，所以為了確認，B同學說：“我能聽到，你能聽到嗎？”，這里的**“我能聽到”**，同時也向A同學表示A同學的麥克風和B同學的聽筒正常，
• 第三次握手：A同學收到B同學的訊息后，就證明了A同學聽筒正常，B同學麥克風正常

以上三次握手就保證了A、B同學的聽筒和麥克風都正常，這就保證了通話的正常~這就類似于網路建立連接時的三次握手

接下來，我們詳細介紹一下網路中的三次握手

**第一次握手：**客戶端TCP行程也先建立傳輸控制塊TCB，然后向服務端發送連接請求報文段，此時SYN=1,隨機選定一個初始序號seq=x,，此報文不能攜帶資料，但是要消耗掉一個序號，發送完畢后，客戶端進入SYN-SENT（同步已發送）狀態

**第二次握手：**服務端收到客戶端請求連接報文段后，若同意建立連接，則發送確認報文，確認報文中SYN=1、ACK=1,確認號ack=x+1,同時隨機選定一個自己序號seq=y,確認報文段同樣不能攜帶資料，但是也要消耗掉一個序號，發送完畢后服務端進入SYN-RCVD（同步收到）狀態

**第三次握手：**客戶端收到確認報文后，檢查ACK=1，ack=x+1是否正確，若正確，則向服務端發送確認報文，確認報文中ACK=1,ack=y+1,seq=x+1,發送后進入ESTAB-LISHED狀態，服務端收到確認報文后，也進入ESTAB-LISHED狀態，此時雙方TCP連接正式建立，

在打電話例子中的“我能聽到，你能聽得到嗎？”中，“我能聽到”相當于ACK, “你能聽得到嗎”相當于SYN

當服務器端呼叫 new ServerSocket后,就會系結端號，并進入LISTEN狀態

當客戶端呼叫 new Socket后，進入SYN-SENT狀態，就會嘗試和服務器建立連接并觸發三次握手，

上面的連接建立程序就是TCP三次握手，具體程序如下，(此圖來自公眾號《程式IT圈》)

兩次握手可以嗎？

不可以，如果沒有第三次，服務器端將不知道客戶端能不能收到自己的訊息，

如果使用的是兩次握手建立連接，假設有這樣一種場景，客戶端發送了第一個請求連接并且沒有丟失，只是因為在網路結點中滯留的時間太長了，由于TCP的客戶端遲遲沒有收到確認報文，以為服務器沒有收到，此時重新向服務器發送這條報文，此后客戶端和服務器經過兩次握手完成連接，傳輸資料，然后關閉連接，此時此前滯留的那一次請求連接，網路通暢了到達了服務器，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端和服務器再次建立連接，這將導致不必要的錯誤和資源的浪費，

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

2.4 斷開連接-四次揮手

為了更好的理解，我們再次使用打電話的例子來解釋一下，如下圖所示

看了這個圖，大家可能會有疑問，為什么要把 好的 再見 這兩個分開呢？

當 服務器收到FIN(即我們明天再聊)，系統內核將立刻發回一個ACK**(好的)，這時B的接受緩沖區中可能還有沒有處理完的任務，必須等B將其處理完畢后才能關閉客戶端連接，發送一個FIN(再見)**給客戶端，

具體流程：

資料傳輸完畢后，雙方都可釋放連接，最開始的時候，客戶端和服務器都是處于ESTABLISHED狀態，然后客戶端主動關閉，服務器被動關閉，

• TCP客戶端發送一個FIN，用來關閉客戶到服務器的資料傳送，此時，客戶端進入FIN-WAIT-1（終止等待1）狀態
• 服務器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態，客戶端收到ACK后，就進入FIN-WAIT-2（終止等待2）狀態，
• 服務器關閉客戶端的連接，發送一個FIN給客戶端，此時，服務器就進入了LAST-ACK（最后確認）狀態，
• 客戶端發回ACK報文確認，并將確認序號設定為收到序號加1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態，注意此時TCP連接還沒有釋放，必須經過2MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態，

為什么TIME-WAIT狀態要等待2MSL呢？

? 由于當客戶端給服務器端發送ACK可能出現丟包情況，這時服務器端會沒收到客戶端的ACK，將會訊息重傳FIN,如果此時客戶端關閉連接，將導致服務器端無法關閉，所以等待2MSL,而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出回應報文，并且會重啟2MSL計時器，

三次揮手行不？

通常情況下不行，因為FIN 和ACK的觸發時機不同，但如果觸發了延時應答機制，可以三次，

致服務器端無法關閉，所以等待2MSL,而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出回應報文，并且會重啟2MSL計時器，

三次揮手行不？

通常情況下不行，因為FIN 和ACK的觸發時機不同，但如果觸發了延時應答機制，可以三次，