??作者：一只愛打拳的程序猿，Java領域新星創(chuàng)作者，CSDN、阿里云社區(qū)優(yōu)質(zhì)創(chuàng)作者。

??專欄收錄于：計算機網(wǎng)絡原理

---

本篇主要講解：TCP協(xié)議段格式，TCP的序列號，SYN、ACK標志位，確認應答機制。

目錄

1、TCP協(xié)議段格式

1.1 TCP格式段

1.2?TCP協(xié)議段格式

2、確認應答機制

2.1 后發(fā)先至

2.2 確認序號

1、TCP協(xié)議段格式

1.1 TCP格式段

TCP協(xié)議段（Segment）是在數(shù)據(jù)傳輸層中，用于實現(xiàn)兩個進程之間可靠的數(shù)據(jù)傳輸。

源端口/目的端口：源端口為數(shù)據(jù)的發(fā)送者，目的端口為數(shù)據(jù)的接受者。

32位序號/確認號：TCP將每個字節(jié)的數(shù)據(jù)都進行了編號即為序列號。

TCP標志位：TCP的6位標志位默認為0，當返回相應的報文時，會把該報文位設置位1。

URG（Urgent）：表示是否包含緊急數(shù)據(jù)。

ACK（Acknowledgment）：表示確認號是否有效。

PSH（Push）：表示是否立即推送。

RST（Reset）：表示連接是否復位。攜帶RST標識的稱為復位報文段。

SYN（Synchronize）：表示同步請求/應答。攜帶SYN標識的稱為同步報文段

FIN（Finish）：表示傳輸結(jié)束。攜帶FIN標識的為結(jié)束報文段。

了解到 TCP 的協(xié)議格式段后，我們來模擬觀察網(wǎng)絡通信過程：

通過上圖，我們觀察到 主機A? 向 主機B 傳輸數(shù)據(jù)時，提供了以 1000 為單位的編號。這些編號稱為 序列號。

我們可認為 主機A 向 主機B 發(fā)送數(shù)據(jù)為一個請求 即 SYN。TCP給這個請求隨機分配一個序列號。

并且 主機B 在收到 主機A 的數(shù)據(jù)后會作出回應，這個回應稱之為 即 ACK。只有接收方返回 ACK 后，這樣的通信才算完成。

確認序列號?的是序列號的下一個字節(jié)數(shù)。當 SYN 請求序列號為 1000，則 ACK 確認序列號為 1001，對照上圖、下圖進行理解。

注意，當ACK=1時，表示TCP報文段中確認號字段有效，因此需要對它進行確認應答。ACK的應答是 TCP 可靠傳輸 機制的關(guān)鍵。

1.2?TCP協(xié)議段格式

TCP協(xié)議段格式如下所示：

16位源端口號   16位目的端口號
--------------------------------
32位序列號
--------------------------------
32位確認號
--------------------------------
4位數(shù)據(jù)偏移    6位保留    6位標志位
--------------------------------
16位窗口大小
--------------------------------
16位校驗和    16位緊急指針
--------------------------------
選項（可選，長度不定）

源端口號和目的端口號：分別表示發(fā)送方和接收方的端口號。

序列號：表示發(fā)送方發(fā)送數(shù)據(jù)的序列號，用于接收方確認收到的數(shù)據(jù)是否完整。

確認號：表示期望接收到的下一個數(shù)據(jù)的序列號。

數(shù)據(jù)偏移：表示TCP頭部長度占多少個32位字長。

保留：用于將頭部填充到32位字長的長度。

標志位：包括6個標志位，分別為URG、ACK、PSH、RST、SYN和FIN，用于控制TCP連接的建立、維護和關(guān)閉等操作。

窗口大小：表示接收方緩存區(qū)的大小。

校驗和：用于檢查TCP頭部和數(shù)據(jù)的完整性。

緊急指針：表示數(shù)據(jù)中包含的緊急數(shù)據(jù)在數(shù)據(jù)流中的位置。

選項：可選的TCP頭部選項，用于支持一些額外的功能。

2、確認應答機制

TCP 在通信過程中，TCP認為發(fā)送方發(fā)送的數(shù)據(jù)為： SYN ，即發(fā)出一個請求。接受方返回的數(shù)據(jù)為：ACK，即確切請求有效。

當我們進行信息傳輸時，我發(fā)信息給張三：“你吃飯了嗎？”，張三回復：“吃了，你呢？”。

網(wǎng)絡應當是以下場景：

但網(wǎng)絡通信的過程中由于特殊情況難免會出差錯，則會造成 先發(fā)后至 的情況，即先發(fā)的消息被后返回的消息回應。

2.1 后發(fā)先至

有以下通信場景：

我：“一起吃個飯嗎，我請客？”，張三回復：“好啊，好啊”。

我：“你借我 500 塊錢”，張三回復：“滾蛋”。

正常情況如下所示：

由于先發(fā)后置：

由于先發(fā)后至，導致：

我：“一起吃個飯，我請客？”，張三回復“滾蛋”。

我：“你借我 500 塊錢”，張三回復“好啊，好啊”。

這樣就會造成數(shù)據(jù)不可靠傳輸。因此，TCP協(xié)議在網(wǎng)絡通信中會將信息傳輸?shù)倪^程引入一個 確認序號 來保證數(shù)據(jù)傳輸可靠性。

2.2 確認序號

TCP 在網(wǎng)絡通信過程中，會根據(jù)信息的發(fā)送順序來引入相應的確認號。即發(fā)送方序列號，接受方為確認序列號，確認序列號為序列號下一個字節(jié)數(shù)。

在上圖中，1000序列號對應的消息只會被1001確認序列號回復，2000序列號的消息只會被2001確認序列號回復。

注意，TCP在通信的過程中會?隨機?給發(fā)送方提供序列號，接收方根據(jù)序列號來返回確認序列號這樣在傳輸過程中就相對安全了。

以上TCP通信過程中，引入了序列號來保證數(shù)據(jù)可靠傳輸，但還有在網(wǎng)絡通信中由于網(wǎng)絡不好（丟包，網(wǎng)卡等）會造成數(shù)據(jù)傳輸不了，因此TCP還會通過 超時重傳 機制來保證數(shù)據(jù)安全傳輸。在下期博文我會詳細講解。

?本編博文到這里就結(jié)束了，感謝點贊、評論、收藏、關(guān)注~文章來源地址http://www.zghlxwxcb.cn/news/detail-485671.html

到了這里，關(guān)于【網(wǎng)絡原理】TCP協(xié)議如何實現(xiàn)可靠傳輸(確認應答機制)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！