先說結論

• 為了實現可靠數據傳輸， TCP 協議的通信雙方， 都必須維護一個序列號， 以標識發送出去的數據包中， 哪些是已經被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值， 并確認對方已經收到了序列號起始值的必經步驟
• 如果只是兩次握手， 至多只有連接發起方的起始序列號能被確認， 另一方選擇的序列號則得不到確認

先修知識

TCP 通信流程

TCP 的通信流程

上圖中的每一個箭頭都代表著一次 TCP數據包的發送

• 需要注意的是， 上圖中出現的 ACK = x +1 的寫法很容易讓人誤以為數據包中的 ACK 域的數據值被填成了 y+1 。 ACK = x+1 的實際含義是：
  • TCP 包的 ACK 標志位（1 bit） 被置成了 1
  • TCP 包的確認號（acknowledgement number ） 的值為 x+1
• 類似的， TCP 數據包中的 SYN 標志位， 也容易與序號（sequence number） 混淆， 這點需要讀者注意

TCP 數據包結構圖

為什么 TCP 需要握手這個操作

在解答為什么 TCP 需要三次握手， 而不是兩次之前， 首先需要回答的問題是:

• 為什么需要握手這個操作， 能不能不握手？

如果讀者對比一下 UDP 的通信流程和 TCP 的通信流程， 可以發現， 在 UDP 協議中， 是沒有握手這個操作的。

這里就引出了 TCP 與 UDP 的一個基本區別， TCP 是可靠通信協議， 而 UDP 是不可靠通信協議。

• TCP 的可靠性含義： 接收方收到的數據是完整， 有序， 無差錯的。
• UDP 不可靠性含義： 接收方接收到的數據可能存在部分丟失， 順序也不一定能保證。

UDP 和 TCP 協議都是基于同樣的互聯網基礎設施， 且都基于 IP 協議實現， 互聯網基礎設施中對于數據包的發送過程是會發生丟包現象的， 為什么 TCP 就可以實現可靠傳輸， 而 UDP 不行？

TCP 協議為了實現可靠傳輸， 通信雙方需要判斷自己已經發送的數據包是否都被接收方收到， 如果沒收到， 就需要重發。 為了實現這個需求， 很自然地就會引出序號（sequence number） 和 確認號（acknowledgement number） 的使用。

發送方在發送數據包（假設大小為 10 byte）時， 同時送上一個序號( 假設為 500)，那么接收方收到這個數據包以后， 就可以回復一個確認號（510 = 500 + 10） 告訴發送方 “我已經收到了你的數據包， 你可以發送下一個數據包， 序號從 510 開始” 。

這樣發送方就可以知道哪些數據被接收到，哪些數據沒被接收到， 需要重發。

為什么需要三次握手，而非兩次

正如上文所描述的，為了實現可靠傳輸，發送方和接收方始終需要同步( SYNchronize )序號。 需要注意的是， 序號并不是從 0 開始的， 而是由發送方隨機選擇的初始序列號 ( Initial Sequence Number, ISN )開始 。 由于 TCP 是一個雙向通信協議， 通信雙方都有能力發送信息， 并接收響應。 因此， 通信雙方都需要隨機產生一個初始的序列號， 并且把這個起始值告訴對方。

于是， 這個過程就變成了下面這樣。

下面這個流程圖描述的和上面一樣， 但是更加清楚的展示了 TCP 數據包標志位， 以及數據域的命名來源。

題外話

有一位讀者關注到了三次握手中， 序列號變化的問題， 讓筆者臨時想起了曾經困擾自己的一個問題

• 為什么三次握手最后一次握手中， 在上面的示意圖中回復的 seq = x+1 。

答案： acknowledgement number 的作用是向對方表示，我期待收到的下一個序號。 如果你向對方回復了 ack = 31, 代表著你已經收到了序號截止到30的數據，期待的下一個數據起點是 31 。

TCP 協議規定SYN報文雖然不攜帶數據， 但是也要消耗1個序列號， 所以前兩次握手客戶端和服務端都需要向對方回復 x+1 或 y+1 。

值得注意的是， 如上圖所說， 最后一次握手在默認不攜帶數據的情況下， 由于SYN 不是 1 ， 是不消耗序列號的。 所以三次握手結束后，客戶端下一個發送的報文中seq 依舊是 x+1， 示意圖如下

注意到， 上圖第四步發送的 seq 和第三次握手的 seq 是一樣的， 體現了最后一次握手， 默認不消耗序列號的特點。

原文鏈接：TCP 為什么三次握手而不是兩次握手（正解版）

總結

以上是生活随笔為你收集整理的pythonsocket中tcp通信接收不到数据_TCP 为什么三次握手而不是两次握手（正解版）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。