一、TCP協(xié)議格式

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

源端口與目的端口

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

序號(hào)

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

確認(rèn)序號(hào)

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

首部長度

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

標(biāo)志位

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

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

窗口大小

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

校驗(yàn)和

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

緊急指針

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

選項(xiàng)與填充

常見選項(xiàng)：

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

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

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

TCP與UDP的對比

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

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

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

• 寫入緩沖區(qū)：應(yīng)用程序需要發(fā)送信息時(shí)，將信息寫入用戶緩沖區(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é)議格式下的報(bào)文

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

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

基本概念

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

工作流程

序號(hào)

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

確認(rèn)號(hào)

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

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

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

確認(rèn)類型

累積確認(rèn)

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

選擇性確認(rèn)

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

優(yōu)化策略

延遲確認(rèn)

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

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

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

示例說明

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

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

四、捎帶應(yīng)答

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

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

五、三次握手和四次揮手

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

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

三次握手

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

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

• ① 建立連接后，TCP協(xié)議會(huì)提供全雙工的通信服務(wù)，即同一條連接同一時(shí)刻，通信雙方可以同時(shí)寫同時(shí)讀
• ② 服務(wù)器從accept函數(shù)返回后立刻調(diào)用read函數(shù)，讀socket就和讀管道一樣，沒有數(shù)據(jù)就阻塞等待
• ③ 這時(shí)客戶端調(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)閉連接，此時(shí)客戶端會(huì)向服務(wù)器發(fā)送FIN段（第一次揮手）
• ② 服務(wù)器收到FIN后，回應(yīng)一個(gè)ACK，同時(shí)read返回0（第二次揮手）
• ③ read返回之后，服務(wù)器就知道客戶端關(guān)閉了連接，也調(diào)用close關(guān)閉連接，這個(gè)時(shí)候服務(wù)器會(huì)向客戶端發(fā)送一個(gè)FIN（第三次揮手）
• ④ 客戶端收到FIN，返回一個(gè)ACK給服務(wù)器（第四次揮手）

2、三次握手—建立連接

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

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

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

3、四次揮手—斷開連接

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

總結(jié)

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

最新評(píng)論