提示：文章寫完后，目錄可以自動生成，如何生成可參考右邊的幫助文檔

---

前言

提示：這里可以添加本文要記錄的大概內容：

傳輸層協議是計算機網絡體系中的核心協議之一，位于OSI模型的第四層，主要負責端到端的數據傳輸控制。其核心功能包括數據分段、流量控制、差錯校驗和連接管理。常見的傳輸層協議主要有TCP和UDP，兩者在可靠性、效率和適用場景上存在顯著差異。

---

提示：以下是本篇文章正文內容，下面案例可供參考

一、TCP協議介紹

TCP/IP協議族的傳輸層協議

1. TCP（可靠的老大哥）

特點：

面向連接：必須先“握手”建立連接（類似打電話要先撥通）。

可靠傳輸：數據丟了會重傳（類似快遞丟了會補發）。

流量控制：根據接收方的能力調整發送速度（類似快遞站根據倉庫容量調整收件量）。

2. UDP（隨性的小弟）

特點：

無連接：直接發數據，不握手（類似發短信，不用等對方接電話）。

不可靠：數據可能丟失（類似明信片，丟了不補發）。

速度快：適合實時應用（視頻、語音、游戲）。

二、TCP報文格式

可以把TCP報文段想象成一封快遞包裹，里面裝著你要傳輸的數據。這個包裹有詳細的“快遞單”（TCP頭部），確保數據能準確、可靠地送到對方手里。以下是關鍵字段的通俗解釋：

1.快遞收發人信息（端口號）

源端口號（16位）：

→ 你的“發貨人編號”（比如你的電腦上微信用的端口號是54321）。

目標端口號（16位）：

→ 對方的“收貨人編號”（比如微信服務器的端口號是80或443）。

類比：就像快遞單上寫的“寄件人電話”和“收件人電話”。

2.包裹編號與簽收確認（序號和確認號）

序號（32位）：

→ 給數據字節編號，比如發送的第1個字節編號是100，第二個是101，依此類推。

→ 作用：防止數據亂序或丟失（類似給書頁標頁碼）。

確認號（32位）：

→ 告訴對方“我已經收到第N號之前的數據，下次請發第N號開始的”。

→ 比如：確認號=150表示“我已收到1~149，請發150開始的”。

類比：快遞員送貨時，你檢查包裹編號并簽字確認：“包裹1、2已收到，請送包裹3”。

3.控制標志位（包裹的特殊要求）

URG：緊急數據（比如快遞包裹上貼“加急”標簽）。

ACK：確認有效（相當于“我已收到你的消息”）。

PSH：催促對方立刻處理（類似“盡快拆包”）。

RST：強制斷開連接（突然拒收包裹，終止交易）。

SYN：發起連接請求（“你好，我要寄快遞”）。

FIN：禮貌結束連接（“我的包裹發完了，再見”）。

記憶口訣：

URGENT加急，ACK要確認，PSH快處理，RST斷連接，SYN打招呼，FIN說再見。

4.流量控制與糾錯（窗口和校驗和）

窗口大小（16位）：

→ 告訴對方“我的倉庫還能放多少包裹”（接收緩沖區剩余空間）。

→ 比如：窗口=5000表示“你最多再發5000字節給我”。

校驗和（16位）：

→ 檢查包裹是否損壞（計算數據完整性，發現錯誤就丟棄）。

類比：倉庫管理員說：“我這還能放5箱貨，發多了放不下！”（流量控制），同時檢查包裹是否破損（校驗和）。

5.其他字段

緊急指針（16位）：

→ 配合URG標志，標記緊急數據的位置（比如“包裹里第50字節是重要文件”）。

選項（可變長度）：

→ 特殊需求（比如協商最大報文段長度MSS）。

6.總結：TCP報文段像一份智能快遞

端口號：告訴快遞員送給誰。

序號/確認號：確保所有包裹按順序簽收。

控制標志：處理加急、簽收、終止等操作。

窗口大小：防止對方“爆倉”。

校驗和：防止包裹損壞。

關鍵點：TCP通過這種精細設計，實現了可靠傳輸——數據不亂、不丟、不重復，適合重要文件傳輸（如網頁、郵件）。而UDP則像“扔明信片”，不管對方收沒收到，適合直播、游戲等實時場景。

官方

源端口號:發送方進程的端口號。

目標端口號:接收端進程的端口號。接收端收到數據段后，根據這個端口號來確定把數據送給哪個應用程序的進程。

序號:發送端為每個字節進行編號，便于接收端正確重組。

當TCP從進程接收數據字節時，把它們分片成數據段存儲在發送緩存中，并對每一個字節進行編號。當數據到達目的地后，接收端會按照這個序號把數據重新排列，保證數據的正確性。

確認號:對發送端的確認信息。

接收端響應消息時將會用它來告訴發送端這個序號之前的數據段都已經收到，如確認號是x，就是表示前X-1個數據段都已經收到。

首部長度:用它可以確定TCP首部數據結構的字節長度。一般情況下TCP首部是20字節，但首部長度最大可以擴展為60字節。

控制位:

URG:緊急位。緊急指針有效位。

ACK: 確認位。只有當ACK=1時，確認序列號字段才有效:當ACK=0時，確認號字段無效。

PSH:急迫位。標志位為1時，要求接收方盡快將數據段送達應用層。

RST:重置位。當RST值為1時，通知重新建立TCP連接。

SYN: 同步(連接)位。同步序號位，TCP需要建立連接時將這個值設為1。

FIN: 斷開位。當TCP完成數據傳輸需要斷開連接時，提出斷開連接的一方將這個值設為1.

窗口大小:說明本地可接收數據段的數目。這個值的大小是可變的，當網絡通暢時接收端響應消息會將這個窗口值變大以加快傳輸速度，當網絡不穩定時減小這個值可保證網絡數據的可靠傳輸，TCP中的流量控制機制就是依靠變化窗口的大小實現的。

比如下載速度從一開始的幾KB逐漸提升到幾MB的過程。

校驗和:用來做差錯控制。字段檢驗的范圍包括首部和數據這兩部分。數據段在發送時和到達目的地時會進行校驗和計算，若這兩次的校驗和一致，則說明數據基本是正確的，否則將認為該數據已被破壞，接收端將丟棄該數據。

緊急指針:和URG配合使用，當URG=1時有效。

選項:在TCP首部可以有多達40字節的可選信息。例如，最大報文段長度MSS (Maximum Segment Size)。

MSS告訴對方

TCP:“我的緩存所能接收的報文段的數據字段的最大長度是MSS個字節。”

三、TCP 三次握手（建立連接）

1. 客戶端 → 服務器：“我要連接！”（SYN=1）

2. 服務器 → 客戶端：“好的，你準備好了嗎？”（SYN=1, ACK=1）

3. 客戶端 → 服務器：“準備好了，開始傳數據！”（ACK=1）

講解三次握手的過程

tcp是面向連接的，就是說每次發送數據之前都要和對方建立一條可靠的連接，這個建立連接的過程分為3個步驟，就叫做三次握手。

① 當客戶端向服務器發送請求連接的報文時：

Seq序列號=x（x為隨機）

SYN=1（表示發送連接請求）

② 服務器端收到客戶端發來的請求報文后，同意建立連接，則向客戶端發送確認報文：

Seq序列號=y（這時服務器也會產生一個序列號y，和客戶端的序號不相關）

Ack確認號=x+1（Seq序列號x+1，表示確認收到了客戶端的請求）

ACK=1（表示這是條確認請求）

SYN=1（同時也發送一個建立連接的請求）

③ 客戶端進程收到服務端進程的確認后，還要向服務端給出確認，然后連接成功建立：

Seq序列號=x+1（這時客戶端的序號為1）

Ack確認號=y+1（表示確認收到了服務器的連接請求）

ACK=1（表示這是確認報文）

打開wireshark，本機連接虛擬機，選擇捕獲vmnet1網卡否則消息太多，選擇tcp協議，觀察tcp三次握手的報文。

四、TCP 四次揮手（斷開連接）

1. A → B：“我說完了”（FIN=1）

2. B → A：“好的，等我發完剩下的”（ACK=1）

3. B → A：“我也說完了”（FIN=1）

4. A → B：“拜拜！”（ACK=1）

講解四次揮手的過程（可以用客戶端向服務器端請求一個網頁舉例）

某個應用進程首先調用close，稱該端執行“主動關閉”（active close）。該端的TCP于是發送一個FIN分節，表示數據發送完畢。

接收到這個FIN的對端執行 “被動關閉”（passive close），這個FIN由TCP確認。

一段時間后，接收到這個文件結束符的應用進程將調用close關閉它的套接字。這導致它的TCP也發送一個FIN。

接收這個最終FIN的原發送端TCP（即執行主動關閉的那一端）確認這個FIN。

1.第一次揮手：

Client發送Fin + Acknowledgement 給Server端，表示自己要斷開連接，這個時候

Client端已經沒有數據要發送了。

2.第二次揮手：

Server接收到Client發送的斷開請求連接，那么這個時候Server需要發送一個Acknowledgement=1用于確定客戶請求斷開的信息成功接收了；有時候這個過程也會和第三次握手進行合并，就像上面展示的一樣。

3.第三次揮手：

Server如果所有的數據已經接收完畢，這個時候就會發送一個Fin=1，而Acknowledgement=0用于表示Server端已經沒有數據要發送了，需要關閉連接。

4.第四次揮手：

Client端需要發送一個Acknowledgement = 1表示這個Client接收到了Server的關閉請求信息，這樣一來雙方的就都關閉了。

在四次揮手中有一個半關閉的概念，我們如何理解在 TCP 斷開連接過程中，有一個半關閉的概念。TCP 一方（通常是客戶端）可以終止發送數據，但仍然可以接收數據，稱為半關閉

當僅完成兩次揮手之后，服務端能否給客戶端發送數據呢？

答案是可以。從兩個方向去理解

思考：

1、為什么是四次揮手不是三次揮手？

因為當服務端還有數據沒有傳完的情況

2、誰可以中斷連接？客戶端還是服務端還是都可以？

都可以中斷連接

其實在最后一步客戶端收到服務端的ACK之后實際上是不會立馬關閉連接的，它進入了TIME_WAIT狀態，為什么不立即關閉？

為了這種情況： B向A發送 FIN = 1 的釋放連接請求，但這個報文丟失了， A沒有接到不會發送確認信息，B 超時會重傳，這時A在 WAIT_TIME 還能夠接收到這個請求，這時再回復一個確認就行了。（A收到 FIN =1 的請求后 WAIT_TIME會重新記時）

另外服務器B存在一個保活狀態，即如果A突然故障死機了，那B那邊的連接資源什么時候能釋放呢？? 就是保活時間到了后，B會發送探測信息， 以決定是否釋放連接。

為什么TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假想網絡是不可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

5.常見 TCP 應用

網頁（HTTP/HTTPS，端口 80/443）

文件傳輸（FTP，端口 21 ）

郵件（SMTP，端口 25）

遠程登錄（TELNET，23）

郵件的接收（POP3 110）

dns–域名服務 （53）

mysql數據庫 （3306）

五、UDP協議介紹（隨性的小弟）

1.無連接：

直接發數據，不握手（類似發短信，不用等對方接電話）。

2.不可靠：

數據可能丟失（類似明信片，丟了不補發）。

3.速度快：

適合實時應用（視頻、語音、游戲）。

4.常見 UDP 應用

DNS 查詢（端口 53）

視頻通話（Zoom、微信通話）

在線游戲（王者榮耀、吃雞）

六、常見的udp協議端口號

NTP--網絡時間協議 123

DHCP--動態主機配置協議 67

SNMP--簡單網絡管理協議161

TFTP--簡單文件傳輸協議 69

RPC--遠程調用協議 111

七、TCP與UDP的不同

1. 連接方式

TCP：像打電話

→ 先撥號（三次握手），確認對方在線才開始聊，掛斷時還要說再見（四次揮手）。

UDP：像發微信消息

→ 直接發，不管對方收沒收到，也不等回復。

2. 可靠性

TCP：強迫癥快遞員

→ 必須簽收確認，丟件必重發，包裹按順序送到。

UDP：隨性派送員

→ 包裹扔門口就走，丟了不管，順序亂了不整理。

3. 速度與效率

TCP：穩但慢

→ 因為要確認、排隊、重發，像高鐵安檢——安全但耗時。

UDP：快但可能丟

→ 像外賣小哥跑著送餐，快但湯可能灑。

4. 適用場景

用TCP：

? 重要文件傳輸（如合同、軟件安裝包）

? 需要長連接的服務（如網頁、遠程登錄）

用UDP：

? 實時性優先（如視頻通話、吃雞游戲）

? 少量數據查詢（如DNS解析）

一句話總結

TCP：可靠的老管家，適合細心活。

UDP：麻利的小哥，適合急活兒。

附：日常類比

官方總結

UDP和TCP協議的主要區別是兩者在如何實現信息的可靠傳遞方面不同：

TCP 是面向連接的傳輸控制協議；而UDP 提供了無連接的數據報服務。

TCP 具有高可靠性，確保傳輸數據的正確性，不出現丟失或亂序；UDP 在傳輸數據前不建立連接，不對數據報進行檢查與修改，無須等待對方的應答，所以會出現分組丟失、重復、亂序，應用程序需要負責傳輸可靠性方面的所有工作。

UDP 具有較好的實時性，工作效率較 TCP 協議高。UDP 段結構比 TCP 的段結構簡單，因此網絡開銷也小。

TCP 協議可以保證接收端毫無差錯地接收到發送端發出的字節流，為應用程序提供可靠的通信服務。對可靠性要求高的通信系統往往使用 TCP 傳輸數據。

TCP 協議傳輸更加穩定可靠，UDP 協議傳輸效率更高。這兩個協議各有特點，在實際應用 中，根據實際應用的需要，選擇不同的傳輸層協議。

---

總結

提示：這里對文章進行總結：

實際例子：

訪問百度：

1. DNS（UDP） 查詢 “www.baidu.com” 的 IP。

2. TCP 三次握手 建立連接。

3. HTTP（TCP） 請求網頁數據。

4. TCP 四次揮手 斷開連接。