【計算機網絡】5傳輸層

傳輸層是面向通信的最高層，也是用戶功能的最底層。?

傳輸層僅存在于主機中，路由器等中間設備只用到下三層（無傳輸層）。

傳輸層對上層應用隱藏了底層網絡的復雜細節（比如數據怎么路由、網絡怎么連接等）。

對應用程序來說，它看到的只是一條虛擬的通信通道，就像兩臺電腦之間直接連了一根線（但實際上數據可能經過了很多路由器、交換機）。
這條通道的表現取決于傳輸層協議是TCP還是UDP：像發短信，速度快但不保證一定送達（適合視頻通話、在線游戲）。

通俗比喻：

網絡層（IP）?負責把包裹（數據）送到正確的城市（主機）。
傳輸層（TCP/UDP）?負責把包裹送到城市里的具體收件人（應用進程），并決定包裹是“必須簽收”（TCP）還是“丟了不管”（UDP）。

1.端口(Port)

概念	作用	示例
IP地址	定位網絡中的主機	`192.168.1.1`
端口號	定位主機內的應用進程	80（HTTP）、443（HTTPS）
套接字	唯一標識一個通信端點	`(192.168.1.1:80)`

1.1.作用

功能：端口是應用層進程與傳輸層之間數據交互的橋梁。

端口是SAP。

各層服務訪問點SAP對比：

層	服務訪問點	示例
數據鏈路層	幀的“類型”字段	0x0800（IPv4）
網絡層	IP數據報的“協議”字段	6（TCP）、17（UDP）
傳輸層	“端口號”字段	80（HTTP）、53（DNS）
應用層	用戶界面	瀏覽器、客戶端軟件

第 $n$ 層的 $SAP$ 就是第 $n+1$ 層可以訪問第 $n$ 層服務的地方。

?軟件端口 ≠ 硬件端口

軟件端口（協議端口）	硬件端口
屬于邏輯概念，用于標識應用層進程。	物理接口（如路由器、交換機的端口），用于設備間連接。
傳輸層使用軟件端口進行進程間通信。	與軟件端口無關。

1.2.端口號

通過“端口號”標識本主機的一個特定進程。

注意：每臺主機的端口號是相互獨立的。TCP、UDP兩種協議的端口號是相互獨立的。

🦊例題

端口號長度： $16bit\left (0\sim 65535 \right ),2^{16}=65536$

類型	范圍	說明	常見示例
服務器端使用的端口號	熟知端口號（背）	0~1023	由IANA分配給TCP/IP重要應用程序	HTTP:80、FTP:21、SSH:22
登記端口號	1024~49151	供未分配熟知端口號的應用程序使用，需在IANA登記以避免沖突。	MySQL:3306、Redis:6379
客戶端使用的端口號（短暫端口號）	49152~65535	僅在客戶端程序運行時動態分配，通信結束后釋放。	隨機分配（如Chrome連接用49200）

類型

范圍

說明

常見示例

服務器端

使用的端口號

熟知端口號

（背）

0~1023

由IANA分配給TCP/IP重要應用程序

HTTP:80、FTP:21、SSH:22

登記端口號

1024~49151

供未分配熟知端口號的應用程序使用，需在IANA登記以避免沖突。

MySQL:3306、Redis:6379

客戶端

使用的端口號

（短暫端口號）

49152~65535

僅在客戶端程序運行時動態分配，通信結束后釋放。

隨機分配（如Chrome連接用49200）

1.3.套接字(Socket)

定義：唯一標識網絡中的一臺主機上的一個應用進程。一個通信端點。格式為Socket = (IP地址 : 端口號)。例如，(192.168.1.1:80)?表示主機192.168.1.1上的Web服務。

通信過程：

源Socket：發送方的IP和端口（如[ClientIP:49152]）。
目的Socket：接收方的IP和端口（如[ServerIP:80]）。
反向通信：服務器回復時，將源/目的端口號互換。

2.功能

2.1.實現端到端的通信

數據鏈路層	?提供 (鏈路上)相鄰節點之間?的邏輯通信（如交換機到路由器）	關注“這一段鏈路怎么傳”
網絡層	?提供?主機之間?的邏輯通信（如 IP 地址到 IP 地址）	關注“整個網絡怎么找到目標主機”
傳輸層	提供 (運行在不同主機上)進程之間(端之間)?的邏輯通信（如端口到端口）	關注“主機收到后交給哪個程序”
	例如：IP將數據送到主機，傳輸層確保數據交付給主機內的具體應用（如瀏覽器、微信）
	即使網絡層不可靠（如丟包、亂序），傳輸層仍能確保可靠性。

邏輯通信：對等層之間的通信好像是沿水平方向傳送的，但兩個對等層之間并沒有一條水平方向的物理連接。

2.2.復用和分用

功能	復用（發送端）	分用（接收端）
傳輸層(TCP/UDP)	多個應用進程（如瀏覽器、微信）通過同一個傳輸協議（TCP/UDP）發送數據。	接收方傳輸層根據端口號（如HTTP:80、DNS:53）將數據分發給正確的目標進程。
網絡層(IP)	不同協議的數據（如TCP、UDP、ICMP）封裝成IP數據報統一傳輸。	接收方網絡層根據協議號（如TCP=6, UDP=17）將數據交給對應的傳輸層協議處理。

2.3.差錯檢測

TCP：可靠傳輸，檢測錯誤后要求重傳（如校驗和失敗）。

UDP：不可靠傳輸，直接丟棄錯誤數據報。

網絡層局限：IP僅檢查首部校驗和，不檢查數據部分。

2.4.向應用層提供兩種服務

特性	面向連接的可靠服務(TCP)	無連接的不可靠服務(UDP)
連接方式	面向連接：需三次握手建立連接，傳輸結束釋放連接	無連接：直接發送數據，無需建立連接
	有建立連接的時延	沒有建立連接的時延
	有連接狀態，需要維護	無連接狀態，所以能支持更多的活動用戶機
面向什么	面向字節流	面向報文
	每次傳輸一個報文段 TCP把應用程序交下來的數據僅視為一連串的無結構的字節流。	每次傳輸一個完整的報文（UDP 處理的最小單位）
	支持報文自動拆分、重裝，因此可以傳輸長報文。所以TCP 報文的長度則根據接收方給出的窗口值和當前網絡擁塞程度來決定。	不支持報文自動拆分、重裝，因此只能傳輸短報文。所以UDP報文的長度由發送應用進程決定。
	應用進程傳送到TCP緩存的數據塊太長 → TCP就把它劃分得短一些再傳送應用進程傳送到TCP緩存的數據塊太短 → TCP也可等到積累足夠多的字節后再構成報文段發送出去。	報文過長 → IP 層可能分片，降低效率。報文過短 → IP 數據報首部相對長度過大，同樣降低效率。

可靠性	可靠（確認、重傳）	不可靠（不確認、不重傳）→可能丟包
可靠性	可靠（確認、重傳）	并不意味著應用對數據的要求是不可靠的，應用層來維護可靠性
幾對幾	僅支持一對一傳輸(因為通信雙方的傳輸層必須先建立連接)	支持一對一(封裝成單播IP數據報) 一對多傳輸(封裝成廣播/多播IP數據報)
全雙工通信	?? 支持	?? 支持
全雙工通信	TCP 提供全雙工通信，允許通信雙方同時發送和接收數據。 TCP 連接的兩端都設有發送緩存和接收緩存，用于臨時存放雙向通信的數據。發送緩存暫存： ①發送應用程序傳送給發送方TCP準備發送的數據 ②TCP 已發送但尚未收到確認的數據接收緩存暫存： ①按序到達但尚未被接收應用程序讀取的數據 ②不按序到達的數據	UDP 本身是全雙工的，但由于無連接和不可靠性，應用層需自行管理數據流的雙向傳輸（如 RTP 協議）。
傳輸效率	慢（需確認、重傳）	快
數據順序	保證數據按序到達	不保證順序
首部開銷	$20B$	$8B$
功能	可靠傳輸	分用復用差錯檢測（校驗和，但出錯直接丟棄）
	流量控制（滑動窗口）	分用復用差錯檢測（校驗和，但出錯直接丟棄）
	擁塞控制（慢啟動、擁塞避免）	沒有擁塞控制不影響源主機發送速率，實時性，時延小
適用場景	適用于要求高可靠性的應用（如網頁瀏覽、文件傳輸、電子郵件）	適用于實時性要求高或容忍少量丟失的應用（如視頻流、DNS 查詢、實時語音）常用于一次性傳輸較少數據的網絡應用，節省開銷；常用于多媒體應用，不要求可靠，但要求時延小。
應用	HTTP（網頁瀏覽） FTP（文件傳輸） SMTP（電子郵件） TELNET（遠程登錄）	DNS（域名解析） SNMP（網絡管理） TFTP（簡單文件傳輸） RTP（實時視頻/語音） DHCP（動態IP分配）

3.UDP

3.1.UDP 數據報

當接收方的傳輸層從IP層收到UDP數據報時，就根據UDP數據報首部中的目的端口，把UDP數據報通過相應的端口，上交最后的終點一一接收方的應用進程。

若接收方UDP發現收到的報文中的目的端口號不正確(不存在對應于端口號的應用進程)，則就丟棄該報文，并由ICMP發送“端口不可達”差錯報文給發送方。

3.2.UDP檢驗

3.2.1.概念

定義：數據的發送方給數據的接收方發送一個UDP數據報后，接收方如何去檢驗出UDP數據報當中是否有比特錯誤。

計算IP數據報首部檢驗和的方法和UDP計算檢驗和的方法基本相同。不同的是：IP數據報檢驗和只檢驗首部；UDP的檢驗和要將首部和數據部分一起檢驗。

偽首部：在計算檢驗和時，UDP數據報前臨時添加 $12B$ 的偽首部。偽首部不向下傳送或向上遞交，只是為了計算檢驗和。?字段內容包括源IP地址（4字節）、目的IP地址（4字節）、全0字段（1字節）、協議字段（1字節，UDP為17）、UDP長度（2字節）。

3.2.2.步驟

1??發送方添加偽首部。把全 $0$ 放入檢驗和字段。偽首部+首部+數據若不是 $16bit$ 的整數，用 $0$ 填充。

2??發送方計算檢驗和：將偽首部+首部+數據以 $16bit$ 為一組，進行二進制反碼求和(最高位產生的進位需要回卷)，加法運算的最終結果逐位取反，得到 $16bit$ “檢驗和”。

3??發送方計算完校驗和之后，拆除偽首部。將 $16bit$ “檢驗和”寫入檢驗和字段。（而若檢驗和的計算結果恰好為 $0$ ，則將檢驗和字段置為全 $1$ 。

4??發送方將UDP數據報（檢驗和字段為“檢驗和”）發送給接收方。

5??接收方在差錯檢驗之前，需要添加偽首部。

6??差錯檢驗：接收方將偽首部+首部+數據（與之前的區別是檢驗和字段為“檢驗和”）以 $16bit$ 為一組，進行二進制反碼求和(最高位產生的進位需要回卷)。如果加法結果為全 $1$ ，說明沒有差錯，就接收該UDP數據報。如果加法結果不是全 $1$ ，說明有差錯，就丟棄該UDP數據報或交付給上層并附上錯誤報告。

7??檢驗完之后，拆除偽首部。

🦄例題?

4.TCP🦊

4.1.TCP報文段/TCP段

4.2.TCP連接管理

TCP連接的端點：套接字（IP地址+端口號）

即使IP或端口重復，通過套接字對（源IP+源端口+目標IP+目標端口）仍能唯一標識一條TCP連接。

TCP連接的建立模式：客戶/服務器模式（C/S模式）

客戶（Client）：主動發起連接建立的應用進程。

服務器（Server）：被動等待連接建立的應用進程。

TCP協議的三大階段：1??建立連接(三次握手)2??數據傳輸3??釋放連接(四次揮手)

階段\字段	SYN	ACK	FIN
握手1	1	0	0
握手2	1	1	0
握手3	0	1	0
揮手1	0	1	1
揮手2	0	1	0
揮手3	0	1	1
揮手4	0	1	0

4.2.1.?建立連接（三次握手）

4.2.1.1.字段值

TCP連接建立需要解決的三個核心問題：①確認對方的存在②參數協商③資源分配

TCP通過“三次握手”機制解決上述三個問題。

階段\字段	SYN	ACK	FIN	seq	ack	特點
握手1	1	0(唯一的0)	0	x		①`SYN=1`不能攜帶數據 ②`SYN=1`要多消耗一個序號
握手1	正在建立連接	第一次握手，尚未收到對方的任何信息，所以確認號無效。	0	x		①`SYN=1`不能攜帶數據 ②`SYN=1`要多消耗一個序號
握手2	1	1	0	y	x+1	①`SYN=1`不能攜帶數據 ②`SYN=1`要多消耗一個序號
握手2	正在建立連接	1	0	y	x+1	①`SYN=1`不能攜帶數據 ②`SYN=1`要多消耗一個序號
握手3	0	1	0	x+1	y+1	可以攜帶數據
握手3	連接已建立	1	0	x+1	y+1	可以攜帶數據
雙向傳輸數據

4.2.1.2.狀態轉換

4.2.1.3.耗時分析

4.2.2.?釋放連接（四次揮手）

4.2.2.1.字段值

階段\字段	SYN	ACK	FIN	seq	ack	特點
揮手1	0	1	1(只有這兩個)	x	y	①一般不攜帶數據，但是可以 ②`FIN=1`要多消耗一個序號
揮手1	0	1	一方發送完了	x	y	①一般不攜帶數據，但是可以 ②`FIN=1`要多消耗一個序號
揮手2	0	1	0	y	x+1	可以攜帶數據
單向傳輸數據
揮手3	0	1	1(只有這兩個)	z	x+1	①一般不攜帶數據，但是可以 ②`FIN=1`要多消耗一個序號
揮手3	0	1	另一方發送完了	z	x+1	①一般不攜帶數據，但是可以 ②`FIN=1`要多消耗一個序號
揮手4	0	1	0	x+1	z+1	不可以攜帶數據

4.2.2.2.狀態轉換

注意：客戶機和服務器都可以先發出揮手。

4.2.2.3.耗時分析

4.3.TCP可靠傳輸(接收方反饋,端到端,局部)

4.3.1.檢驗

和UDP檢驗一樣

4.3.2.序號seq

每個字節分配唯一序號，起始序號在建立連接時確定。

作用：標識數據位置，確保有序傳輸。

示例：客戶端初始序號=599，服務器初始序號=199。

4.3.3.確認seq_ack

累積確認規則：接收方返回確認號ack=n，表示序號n-1及之前的所有數據已正確接收。

專門確認（非術語）	攜帶確認
只有首部，沒有數據	若接收方有數據需發送，可攜帶在ACK段中（減少報文數量）。屬于立即確認。

專門確認（非術語）

攜帶確認

只有首部，沒有數據

若接收方有數據需發送，可攜帶在ACK段中（減少報文數量）。

屬于立即確認。

推遲確認（默認）

立即確認

1??推遲確認就是ACK等一會再發送，如果又收到了一個報文段，那么可以累計確認。推遲時間最多不能超過0.5秒(TCP標準規定)

2??如果自己也有數據要傳送給對方，那么不推遲，立即返回ACK段，并“捎帶”自己的數據。

3??若連續收到兩個長度為MSS的報文段（就是允許范圍內的最大報文段），就應該立即返回ACK段。因為重傳代價很大，要讓這件事盡快塵埃落定。

每收到一個TCP報文段，就立即返回一個ACK段

即使收到一個失序報文段，也要立即返回ACK段
(失序報文段會導致冗余ACK)

4.3.4.重傳

超時重傳（默認）

快重傳

每發出一個報文段，就設置一個計時器。

若計時器到期還沒收到確認，就重傳這一報文段，并重置計時器。

配套機制：立即確認

作用：讓可能出錯的報文段盡早重傳，而不是非要等到超時再重傳。

當發送方連續收到三個確認號相同的冗余ACK（1+3個確認號相同的ACK）時，就立即重傳該確認號對應的報文段

4.4.TCP流量控制(接收方反饋,端到端,局部)

接收緩沖區的數據交給應用層后要保證有序（比如說應用層的數組有1~17的字節，要交上去18~20的字節可以，20~22的字節不行）

4.5.TCP擁塞控制(控制發送方,整個網絡,全局)

發送窗口的上限值=min[rwnd接收窗口(流量控制)，cwnd擁塞窗口(擁塞控制)]

每臺主機都有自己的發送窗口、接收窗口、擁塞窗口。

現象	網絡是否擁塞?	怎么辦?	算法
發出的每個報文段，都能順利地收到ACK確認	不擁塞	小心翼翼調大cwnd擁塞窗口
收到冗余ACK，引發快重傳	有點擁塞	迅速減少發送的數據量適當縮小cwnd擁塞窗口	快重傳算法和快恢復算法
發出的報文段未能按時收到ACK，引發超時重傳	嚴重擁塞	迅速減少發送的數據量迅速縮小cwnd擁塞窗口	慢開始算法和擁塞避免算法