5. 運輸層

1. 概述

• 第2~4章依次介紹了計算機網絡體系結構中的物理層、數據鏈路層和網絡層，它們共同解決了將主機通過異構網絡互聯起來所面臨的問題，實現了主機到主機的通信
• 然而在計算機網絡中實際進行通信的真正實體，是位于通信兩端主機中的進程
• 如何為運行在不同主機上的應用進程提供直接的邏輯通信服務，就是運輸層的主要任務，運輸層協議又稱為端到端協議

2. 端口號，復用和分用

1. 運輸層端口號

• 運行在計算機上的進程是使用進程標識符(Process ldentification,PID)來標識的。
  • 然而，因特網上的計算機并不是使用統一的操作系統，而不同操作系統(Windows、Linux、.MacOS)
    又使用不同格式的進程標識符
  • 為了使運行不同操作系統的計算機的應用進程之間能夠基于網絡進行通信，就必須使用統一的方法
    對TCPP體系的應用進程進行標識
• TCP/IP體系結構的運輸層使用端口號來標識和區分應用層的不同應用進程。端口號的長度為6比特，取
  值范圍是0~65535

端口號只具有本地意義，即端口號只是為了標識本計算機網絡協議棧應用層中的各應用進程。在因特網中，不同計算機中的相同端口號是沒有關系的，即相互獨立。另外，TCP和UDP端口號之間也是沒有關系的

2. 發送方的復用和接收方的分用

1. 復用（Multiplexing）：
   • 定義： 復用是指將多個應用程序的數據流合并到一個共享的通信通道上
   • TCP中的復用： 在TCP中，復用通過源端口號來實現。TCP連接的兩端使用IP地址和端口號來唯一標識。源端口號表示發送端的應用程序，目的端口號表示接收端的應用程序。這樣，在單個TCP連接中，多個應用程序的數據可以共享同一個物理通信通道
   • UDP中的復用： 在UDP中，復用同樣通過源端口號來實現。UDP報文的源端口號用于標識發送端的應用程序，目的端口號用于標識接收端的應用程序
2. 分用（Demultiplexing）：
   • 定義： 分用是指根據數據流中的標識信息將合并的數據流分發給正確的應用程序
   • TCP中的分用： 在TCP中，分用通過目的端口號來實現。接收端根據目的端口號將接收到的數據分發給相應的應用程序。這樣，TCP層能夠將數據正確地傳遞給目標應用程序
   • UDP中的分用： 在UDP中，同樣通過目的端口號來實現分用。接收端通過目的端口號確定應該將數據交付給哪個應用程序

常見協議的分類

運輸層端口號應用舉例

3. TCP和UDP的對比

注意：

• TCP面向連接是邏輯連接，并非真實物理連接
• TCP面向字節流，UDP面向應用報文（只是給數據報添加一個UDP首部）
• TCP只支持單播，UDP支持單播、多播和廣播
• TCP提供可靠服務，UDP提供不可靠服務

4. TCP的流量控制

1. 概述

TCP為應用程序提供了流量控制（Flow Control）機制，以解決因發送方發送數據太快而導致接收方來不及接收，造成接收方的接收緩存溢出的問題

流量控制的基本方法：接收方根據自己的接收能力（接收緩存的可用空間大小）控制發送方的發送速率

2. 流量控制方法

1. 流程

2. 例題

   

5. TCP的擁塞(se)控制

1. 基本概念

2. 4種擁塞控制方法

1. 慢開始、擁塞避免

2. 快重傳、快恢復

快重傳算法和快恢復算法（改進TCP性能，1990年Reno版本）

1. 問題：只是個別報文丟失，沒有出現擁塞，這種情況下還是會將擁塞窗口設置為1，降低了網絡利用率

2. 快重傳

   • 采用快重傳算法可以讓發送方盡早知道發生了個別TCP報文段的丟失
   • “快重傳”是指使發送方盡快（盡早）進行重傳，而不是等重傳計時器超時再重傳
     • 這就要求接收方不要等待自己發送數據時才進行捎帶確認，而是要立即發送確認，即使收到了失序的報文段也要立即發出對已收到的報文段的重復確認
     • 發送方一旦收到3個連續的重復確認，就將相應的報文段立即重傳，而不是等該報文段的重傳計時器超時再重傳

   

3. 快恢復

與快重傳算法配合使用的是快恢復算法，發送方一旦收到3個重復確認，就知道現在只是丟失了個別的報文段，于是不啟動慢開始算法，而是執行快恢復算法

• 快恢復算法：發送方將慢開始門限ssthresh的值和擁塞窗口cwnd的值都調整為當前cwnd值的一半，并開始執行擁塞避免算法
• 也有的快恢復實現是把快恢復開始時的cwnd值再增大一些，即cwnd=新ssthresh+3

6. TCP超時重傳時間的選擇

TCP超時重傳時間RTO的選擇是TCP最復雜的問題之一

問題：

• 超時重傳時間設置過小，在確認報文段發送給接收方的過程中，發送方重傳數據報文，增大了網絡負荷
• 超時重傳時間設置過大，需要重傳數據報文時，推遲時間太長，網絡空閑時間大，降低了傳輸效率
• 超時重傳時間RTO應略大于往返時間RTT

RTO的選擇

1. RTTs的計算

2. RRTd和RTO的計算

發生超時重傳時無法測準RTT

通過上述兩個例子可以看出：當發送方出現超時重傳后，收到確認報文段時是無法判斷出該確認到底是對原數據報文段的確認還是對重傳數據報文段的確認，也就是無法準確測量出RTT，進而無法正確計算RTO

Karn算法及修正

總結

7. TCP可靠傳輸的實現

• TCP的窗口以字節為單位

• 發送方
  • 發送窗口內的已發送數據如果遲遲未收到確認，會發生超時重傳
  • 只有處于發送窗口內的數據才能發送

• 接收方
  • 接收方只能對按序收到的數據中的最高序號給出累計確認，3次重復確認會導致發送方快重傳
  • 序號落入接收窗口內的數據是允許接收的數據

• 總結

8. TCP的運輸連接管理

1. TCP連接的建立

TCP雙方連接的建立要解決的三個問題

2. 三報文握手

思考：第三次確認是否多余，能不能兩報文握手？

答案：不能，如下圖所示

3. 四報文揮手

思考：為什么客戶端發送完最后一個確認報文段后不立刻關閉而是等待2個MSL時間后才關閉？

答案：如圖所示

TCP保活計時器的作用

9. TCP、UDP報文段首部格式對比

參閱思維導圖1

10. UDP的校驗

[!IMPORTANT]

偽首部只是計算校驗和的時候添加的，計算完后會拆除，不參與運輸！

11. 思維導圖和習題

第5章 運輸層（思維導圖）-1 (kdocs.cn)

第5章 運輸層（思維導圖）-2 (kdocs.cn)

第5章 運輸層 習題 (kdocs.cn)