一、TCP協(xié)議格式

TCP（傳輸控制協(xié)議）報文結(jié)構(gòu)是網(wǎng)絡(luò)通信中重要的基礎(chǔ)概念，用于實現(xiàn)可靠的數(shù)據(jù)傳輸

源端口與目的端口

• 作用：標(biāo)識通信的兩端進(jìn)程（范圍：0~65535）
• 示例：HTTP默認(rèn)使用80端口，HTTPS使用443端口

序號

• 作用：標(biāo)記本報文段中數(shù)據(jù)的第一個字節(jié)在整個數(shù)據(jù)流中的位置，用于保證數(shù)據(jù)有序傳輸
• 特點：SYN標(biāo)志位為1時，序號為初始序號（ISN），后續(xù)序號遞增

確認(rèn)序號

• 作用：期望收到的下一個字節(jié)的序號，表示已成功接收該序號之前的數(shù)據(jù)
• 規(guī)則：確認(rèn)號 = 已接收數(shù)據(jù)的最后一個字節(jié)序號 + 1

首部長度

• 作用：指示TCP頭部的長度（以4字節(jié)為單位），最大值為60字節(jié)（默認(rèn)20字節(jié)）
• 原因：由于選項字段的存在，頭部長度可能變化

標(biāo)志位

用來區(qū)分TCP報文的類型

• URG：緊急指針有效，通知接收方優(yōu)先處理緊急數(shù)據(jù)
• ACK：確認(rèn)號是否有效
• PSH：通知接收方立即將數(shù)據(jù)提交給上層應(yīng)用，即從TCP緩沖區(qū)讀走
• RST：重置連接，用于異常中斷
• SYN：同步序號，用于請求建立連接
• FIN：終止連接，用于斷開連接

窗口大小

• 作用：告知發(fā)送方當(dāng)前接收方的可用緩沖區(qū)大小，用于流量控制
• 單位：字節(jié)數(shù)，范圍0~65535（通過窗口擴(kuò)大因子可擴(kuò)展）

校驗和

• 作用：驗證TCP報文段（包括頭部和數(shù)據(jù)）在傳輸過程中是否損壞
• 計算范圍：TCP頭部、數(shù)據(jù)部分，以及偽首部（包含IP地址和協(xié)議號）

緊急指針

• 作用：當(dāng)URG標(biāo)志位為1時，若當(dāng)前段起始序列號為seq，緊急指針為ptr，則緊急數(shù)據(jù)的范圍就是seq到seq + ptr - 1
• 注意：緊急數(shù)據(jù)會被識別并提前處理，但緊急數(shù)據(jù)是TCP中的一種特殊機(jī)制，實際中較少使用

選項與填充

常見選項：

• 最大段長度：協(xié)商每次傳輸?shù)淖畲髷?shù)據(jù)量
• 時間戳選項：用于計算往返時間和防止序號回繞
• 填充：確保頭部長度為4字節(jié)的整數(shù)倍

數(shù)據(jù)部分

• 內(nèi)容：封裝上層協(xié)議（如HTTP、FTP）的數(shù)據(jù)
• 注意：TCP頭部不含長度字段，數(shù)據(jù)長度通過IP頭部的總長度減去IP頭部長度和TCP頭部長度計算得出

TCP與UDP的對比

通過以上結(jié)構(gòu)，TCP能夠?qū)崿F(xiàn)可靠、有序、流量可控的數(shù)據(jù)傳輸，是互聯(lián)網(wǎng)核心協(xié)議之一

二、TCP協(xié)議機(jī)制

TCP擁有發(fā)送緩沖區(qū)和接收緩沖區(qū)兩個緩沖區(qū)，發(fā)送信息的流程是：

• 寫入緩沖區(qū)：應(yīng)用程序需要發(fā)送信息時，將信息寫入用戶緩沖區(qū)
• 寫入內(nèi)核：調(diào)用wirte函數(shù)，將信息從用戶緩沖區(qū)復(fù)制到發(fā)送緩沖區(qū)
• 發(fā)送數(shù)據(jù)：通過網(wǎng)卡和內(nèi)核TCP模塊處理將數(shù)據(jù)存入另一用戶的接受緩沖區(qū)
• 寫入用戶區(qū)：調(diào)用read函數(shù)，將信息從接收緩沖區(qū)拷貝到用戶緩沖區(qū)中
• 應(yīng)用程序獲取數(shù)據(jù)：應(yīng)用程序從用戶緩沖區(qū)讀取數(shù)據(jù)

這里發(fā)送和接收的數(shù)據(jù)就是上面我們提到的協(xié)議格式下的報文

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

TCP確認(rèn)應(yīng)答機(jī)制是確保數(shù)據(jù)可靠傳輸?shù)暮诵臋C(jī)制之一，也是區(qū)別于UDP的核心特點之一，在保證可靠性的同時，盡可能優(yōu)化傳輸效率

基本概念

• 作用：接收方通過發(fā)送確認(rèn)消息，告知發(fā)送方數(shù)據(jù)已成功接收，避免數(shù)據(jù)丟失
• 可靠性保證：發(fā)送方在超時未收到確認(rèn)消息時，會重傳數(shù)據(jù)，叫做超時重傳

工作流程

序號

• 每個TCP報文段都會攜帶一個序號，標(biāo)識該段數(shù)據(jù)在數(shù)據(jù)流中的位置

確認(rèn)號

• 接收方通過確認(rèn)消息返回確認(rèn)號，表示下一個期望接收的數(shù)據(jù)序號
• 規(guī)則：確認(rèn)號 = 已成功接收的最后一個字節(jié)序號 + 1
  • 示例：若接收方成功接收序號1000~1999的數(shù)據(jù)段，確認(rèn)號為2000，表示期望接收后續(xù)數(shù)據(jù)

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

• 單次確認(rèn)：發(fā)送方發(fā)送數(shù)據(jù)后，等待接收方的確認(rèn)消息
• 批量確認(rèn)：滑動窗口技術(shù)允許發(fā)送方連續(xù)發(fā)送多個數(shù)據(jù)段，接收方只需確認(rèn)最后一個連續(xù)收到的序號，也叫累積確認(rèn)

確認(rèn)類型

累積確認(rèn)

• 特點：接收方僅確認(rèn)最后一個連續(xù)收到的數(shù)據(jù)段，忽略中間丟失的段
• 優(yōu)點：實現(xiàn)簡單，減少確認(rèn)消息數(shù)量
• 缺點：若中間某個段丟失，發(fā)送方需重傳后續(xù)所有段，這也叫做線頭阻塞

選擇性確認(rèn)

• 機(jī)制：接收方通過選擇性確認(rèn)選項告知發(fā)送方哪些段已接收，哪些段丟失
• 優(yōu)點：發(fā)送方僅重傳丟失的段，避免冗余重傳
• 適用場景：高帶寬延遲網(wǎng)絡(luò)，如衛(wèi)星鏈路

優(yōu)化策略

延遲確認(rèn)

• 機(jī)制：接收方延遲發(fā)送確認(rèn)消息（通常最多200ms），合并多個確認(rèn)以減少網(wǎng)絡(luò)流量
• 適用場景：批量數(shù)據(jù)傳輸，如文件下載

確認(rèn)應(yīng)答壓縮

• 機(jī)制：在高速網(wǎng)絡(luò)中，減少冗余確認(rèn)消息的發(fā)送頻率

示例說明

• 發(fā)送方發(fā)送數(shù)據(jù)段：序號1000（1000字節(jié)） → 序號2000（1000字節(jié)） → 序號3000（1000字節(jié)），接收方收到序號1000和3000的段：
• 發(fā)送確認(rèn)應(yīng)答 2000（累積確認(rèn)，僅確認(rèn)連續(xù)段），那序號2000和序號3000的數(shù)據(jù)段都會重傳
• 若支持選擇性確認(rèn)，額外告知序號3000已接收，發(fā)送方根據(jù)確認(rèn)應(yīng)答和選擇性確認(rèn)，僅重傳序號2000的段

這個確認(rèn)應(yīng)答呢我有一個小技巧來記憶，發(fā)送方發(fā)送數(shù)據(jù)段之后，比如說發(fā)送了序號1000，它代表著1000~1999，那我下一個是不是就要要2000了，那么我們確認(rèn)應(yīng)答發(fā)送的就是2000

四、捎帶應(yīng)答

我們將捎帶應(yīng)答這個解釋過程簡化為兩張圖，黑色斜線表示通信雙方，正常情況下如下圖所示，左邊給右邊發(fā)送一個報文，右邊要給左邊一個應(yīng)答，表示已經(jīng)收到數(shù)據(jù)，當(dāng)然這里的應(yīng)答也是嚴(yán)格按照TCP報文結(jié)構(gòu)來的，發(fā)送的也是一個完整的TCP報文（至少有報頭），之后右邊再給左邊發(fā)送報文，左邊再給右邊發(fā)送一個應(yīng)答

但是這樣的效率會很低，在正常情況下，雙方不會這樣進(jìn)行通信，而是將應(yīng)答和要發(fā)送的TCP數(shù)據(jù)整合成一條報文，此時發(fā)送的這條報文既是應(yīng)答又是數(shù)據(jù)，減少開支

五、三次握手和四次揮手

1、應(yīng)用層行為

這邊我們舉一個客戶端和服務(wù)端的例子

三次握手

• ① 服務(wù)端應(yīng)用層行為（服務(wù)器初始化）：服務(wù)端是要先開啟的，應(yīng)用層通過調(diào)用socket分配一個文件描述符，然后調(diào)用bind函數(shù)將這個文件描述符與服務(wù)器地址端口綁定，然后調(diào)用listen函數(shù)進(jìn)入監(jiān)聽狀態(tài)，然后調(diào)用accept函數(shù)阻塞等待客戶端的連接，此時服務(wù)端開啟完畢
• ② 客戶端應(yīng)用層行為（建立連接）：客戶端后開啟，應(yīng)用層通過調(diào)用socket分配一個文件描述符，然后調(diào)用connect函數(shù)向服務(wù)器發(fā)起將文件描述符與服務(wù)器地址端口連接請求，connect函數(shù)會發(fā)出SYN段并阻塞等待服務(wù)器應(yīng)答（第一次握手）
• ③ 服務(wù)器收到客戶端SYN，會應(yīng)答一個SYN-ACK段表示同意建立連接（第二次握手）
• ④ 客戶端收到SYN-ACK后會從connect函數(shù)返回，同時應(yīng)答一個ACK段（第三次握手）

數(shù)據(jù)傳輸

• ① 建立連接后，TCP協(xié)議會提供全雙工的通信服務(wù)，即同一條連接同一時刻，通信雙方可以同時寫同時讀
• ② 服務(wù)器從accept函數(shù)返回后立刻調(diào)用read函數(shù)，讀socket就和讀管道一樣，沒有數(shù)據(jù)就阻塞等待
• ③ 這時客戶端調(diào)用write發(fā)送請求給服務(wù)器，服務(wù)器收到后從read返回，對客戶端的請求進(jìn)行處理，在此期間客戶端調(diào)用read函數(shù)阻塞等待服務(wù)器的應(yīng)答
• ④ 服務(wù)器調(diào)用write函數(shù)將處理結(jié)果發(fā)回客戶端，再次調(diào)用read函數(shù)阻塞等待下一條請求
• ⑤ 客戶端收到后從read函數(shù)返回，發(fā)送下一條請求
• ⑥ 以①~⑤循環(huán)

四次揮手

• ① 客戶端調(diào)用close關(guān)閉連接，此時客戶端會向服務(wù)器發(fā)送FIN段（第一次揮手）
• ② 服務(wù)器收到FIN后，回應(yīng)一個ACK，同時read返回0（第二次揮手）
• ③ read返回之后，服務(wù)器就知道客戶端關(guān)閉了連接，也調(diào)用close關(guān)閉連接，這個時候服務(wù)器會向客戶端發(fā)送一個FIN（第三次揮手）
• ④ 客戶端收到FIN，返回一個ACK給服務(wù)器（第四次揮手）

2、三次握手—建立連接

三次握手的機(jī)制就是建立在捎帶應(yīng)答上的，捎帶應(yīng)答不僅是通信時的一種策略，并且是建立連接時的策略

三次握手也可以是四次握手，理由和上面一樣，這里的第二次握手本來也是兩條消息合并發(fā)送而已

• 對于客戶端來說，當(dāng)我們將ACK發(fā)出了，我們就認(rèn)為連接已經(jīng)建立成功了，此時客戶端的狀態(tài)就是上上圖的ESTABLISHED，建立描述該連接的客戶端屬性結(jié)構(gòu)體就被建立了，我們TCP協(xié)議對于連接的管理當(dāng)然也是先描述后組織的，此時客戶端連接的屬性結(jié)構(gòu)體就通過指針被隊列組織管理了
• 對于服務(wù)器來說，在開啟監(jiān)聽狀態(tài)LISTEN后，收到建立連接報文SYN，會對客戶端進(jìn)行確認(rèn)并請求建立連接ACK+SYN，然后在收到客戶端確認(rèn)報文ACK之后建立描述該連接的服務(wù)器屬性結(jié)構(gòu)體，然后這個結(jié)構(gòu)體也會被管理起來

3、四次揮手—斷開連接

• 對于客戶端來說，當(dāng)沒有數(shù)據(jù)要讀取或發(fā)送的時候，發(fā)送結(jié)束報文FIN，進(jìn)入等待狀態(tài)1，FIN_WAIT1，然后一直等待，在接收到服務(wù)器的應(yīng)答ACK后進(jìn)入等待狀態(tài)2，FIN_WAIT2，然后一直等待，在收到服務(wù)器FIN報文時，發(fā)送應(yīng)答ACK并轉(zhuǎn)為TIME_WAIT狀態(tài)，等待一個2MSL（報文最大生存時間）的時間，然后進(jìn)入CLOSED狀態(tài)
• 對于服務(wù)器來說，在接收到客戶端發(fā)來的結(jié)束報文FIN之后，如果自己也沒有啥要發(fā)給客戶端的，那么發(fā)送應(yīng)答ACK并轉(zhuǎn)為等待狀態(tài)CLOSE_WAIT，處理之前的數(shù)據(jù)，處理完后向客戶端發(fā)送結(jié)束報文FIN，并轉(zhuǎn)為最終回應(yīng)狀態(tài)LAST_ACK，在接收到客戶端的ACK的報文后，關(guān)閉連接

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。 

最新評論