第三章 傳輸層
目錄
一、傳輸層協議
1.為執行在不同Host上的程序提供了一種邏輯通訊機制。
2.端系統執行傳輸層協議
傳送方: 將應用遞交的訊息分成一個或多個的Segment, 並向下傳給網路層。
接收方:將接收到的segment組裝成訊息，並向上交給應用層。
3.傳輸層可以為應用提供多種協議：
Internet上的TCP：可靠、按序的交付服務
擁塞控制、流量控制、連線建立
Internet上的UDP：不可靠的交付服務
基於“盡力而為(Best-effort)”的網路層；沒有做(可靠性方面的)擴充套件公
兩種服務均不保證：延遲、頻寬
二、多路複用和多路分用
分用如何工作？
1）主機接收到IP資料報(datagram)：
每個資料報攜帶源IP地址、 目的IP地址。
每個資料報攜帶一個傳輸層的段(Segment)
每個段攜帶源埠號和目的埠號
2）主機收到Segment之後，傳輸層協議提取IP地址和埠號資訊，將Segment導向相應的Socket。TCP做更多處理
無連線分用？
1）利用埠號建立Socket
DatagramSocket mySocket1 = new DatagramSocket (99111) ;
DatagramSocket mySocket2 = new DatagramSocket (99222) ;
2）UDP的Socket用二元組標識：(目的IP地址，目的埠號)
3）主機收到UDP段後
檢查段中的目的埠號；
將UDP段導向繫結在該埠號的Socket；
4）來自不同源IP地址和/或源埠號的IP資料包被導向同一個Socket
面向連線的分用？
1）TCP的Socket用四元組標識：源IP地址 源埠號 目的IP地址 目的埠號
2）接收端利用所有的四個值將Segment導向合適的Socket
3）伺服器可能同時支援多個TCPSocket。每個Socket用自己的四元組標識。
4）Web伺服器為每個客戶端開不同的Socket
三、UDP
User Datagram Protocol
1.基於Internet IP協議，實現功能：
複用/分用
簡單的錯誤校驗
2.“Best effort”的服務模型，UDP段可能丟失、非按序到達
3.無連線
UDP傳送方和接收方之間不需要握手
每個UDP段的 處理獨立於其他段
4.UDP為什麼存在?
無需建立連線(減少延遲)；
實現簡單:無需維護連線狀態；
頭部開銷少；
沒有擁塞控制:應用可更好地控制傳送時間和速率。
5.常用於流媒體應用：容忍丟失、速率敏感
6.UDP還用於DNS、SNMP
7.在UDP上實現可靠資料傳輸?
在應用層增加可靠性機制
應用特定的錯誤恢復機制
8.報文段格式：
9.UDP校驗和(checksum)
目的:檢測UDP段在傳輸中是否發生錯誤(如位翻轉)
傳送方
1）將段的內容視為16-bit整數。
2）校驗和計算:計算所有整數的和，進位加在和的後面，將得到的值按位求反，得到校驗和。
3）傳送方將校驗和放入校驗和欄位。
接收方
1）計算所收到段的校驗和
2）將其與校驗和欄位進行對比
不相等:檢測出錯誤
相等:沒有檢測出錯誤(但可能有錯誤)
四、可靠資料傳輸的基本原理
Rdt1.0（理想）:可靠通道的可靠傳輸，不會發生錯誤，不會丟棄分組
Rdt2.0:不可靠通道（可能翻轉位）；差錯檢測（利用校驗和檢）；接收方反饋控制訊息（確認機制ACK、NAK，停等協議）；重傳。
Rdt2.1:增加序列號；需校驗ACK/NAK訊息是否發生錯誤。
Rdt2.2:無NAK訊息協議；顯式地加入被確認分組的序列號。
Rdt3.0:定時器；
五、滑動視窗協議
用滑動視窗協議實現流水線機制。
GBN和SR
| GBN | SR | |
| 特點 | 累計確認（傳送擁有最高序列號的、已被正確接收的分組的ACK） | 單獨進行確認，為每個分組設定定時器。 多了接收方視窗。 |
| 超時事件 | 重傳序列號大於等於n，還未收到ACK的所有分組。設定一個計時器。 | 只重傳超時的分組，併為每個分組設定定時器。 |
| 分組亂序到達 | 丟棄，並重新確認序列號最大的、按序到達的分組。 | 快取機制，快取亂序到達的分組（在視窗範圍內） |
| 傳送方 | 首先將資料按定義的格式打包。傳送分組，等待確認分組到達。如果發生超時，則重發分組。當收到ACK時， 若收到重複確認, 此處應當立即重發；若沒有重複，滑動視窗則向後移動。當確認到最後一個 分組時，結束。 | 將視窗中資料發出，如果超時，則重傳並重新設定計時器；如果傳輸視窗中資料 分組亂序到達，也能將資料分組快取，如果視窗最小序列號的分組被確認，則視窗滑動。 |
| 接收方 | 當接收到資料傳輸時，因為是累積確認，所以要判斷當前到達的序列號是否是期待的序列號，同時如果檢查校驗和未出錯，則產生確認分組，返回確認分組並期待下一個序列號分組，同時滑動視窗；如果出錯或者資料包丟失，收到的不是所期待的資料分組，則重複傳送ACK；如果最後一個數據包確認即標誌位為1的資料包被確認，結束。 | 接受到接受視窗中的資料則會返回ACK確認，不在視窗中的資料不接收；如果視窗最小序列號的分組被接受，則視窗滑動。 |
SR困境：如圖
此時，無法區分序號為0的分組是重傳還是下一個資料。
序列號空間大小與視窗尺寸關係：Ns+Nr<=2^k
六、面向連線傳輸協議-TCP
概述：點對點；可靠的、按序的；流水線機制；傳送方/接收方快取；全雙工；面向連線；流量控制機制；擁塞控制機制
TCP段結構
注：
序列號：segment中第一個位元組的編號，不是segment的編號；建立TCP連線時，雙方隨機選擇序列號。
ACKs：希望接收的下一個位元組序列號；該序列號之前所有的位元組均已被正確接收。
舉例：
關於超時和重傳：
定時器超時時間設定
累積確認
單一重傳定時器：與SR不一樣
快速重傳機制：傳送方收到同一資料3個ACK
TCP流量控制：
告訴傳送方還有多少；Receiver告知Sender RcvWindow=0，傳送方仍然可以傳送一個很小的段攜帶回新的RcvWindow資訊，可以避免死鎖。
TCP連線管理：
三次握手：
第一次：客戶端向伺服器端傳送TCP SYN段
選擇初始序列號；不攜帶資料；SYN=1，表示要建立連線；
第二次：伺服器端收到SYN，回覆SYNACK段
伺服器分配快取；選擇初始序列號
第三次：客戶端收到SYNACK，回覆ACK段
幷包含資料；SYN=0，表示確認我收到同意建立連線的報文段。
注：ACK表示我想要的下一個段。
例：
關閉連線：
第一步：客戶向伺服器傳送TCP FIN控制端；
第二步：伺服器收到FIN，回覆ACK，關閉連線，傳送FIN；
第三步：客戶收到FIN，回覆ACK；進入等待狀態，如果再次收到FIN，重新發送ACK
第四步：伺服器收到ACK，真正連線關閉
例：
擁塞控制原理：
表現：
分組丟失（路由器快取溢位）
分組延遲過大（在路由器快取中排隊）
擁塞控制方法：
1）端到端擁塞控制
網路層不需要顯式的提供支援
端系統通過觀察loss，delay等網路行為判斷是否發生擁塞
TCP採用這種方法
2）網路輔助的擁塞控制
擁塞指示：SNA，DECbit，TCP/IP ECN，ATM
路由器向傳送方顯式地反饋網路擁塞資訊
指示傳送方應採取何種速率
案例：ATM ABR擁塞控制
ABR
彈性服務
如果傳送方路徑沒有擁塞，使用可用頻寬
如果傳送方路徑擁塞，將傳送速率降到最低保障速率
RM cells
傳送方傳送
交換機設定RM cell位（網路輔助）
NI bit：rate不許增長
CI bit：擁塞指示
RMcell由接收方返回給傳送方
TCP擁塞控制原理：
傳送方限制傳送速率：
LastByteSent-LastByteAcked<=CongWin
CongWin：
動態調整以改變傳送速率；反映所感知到的網路擁塞
感知網路擁塞：
Loss事件：timeout或收到3個重複ACK
發生loss事件後，傳送方降低速率
合理地調整發送速率：
AIMD（加性增-乘性減）、SS（慢啟動）
AIMD（加性增-乘性減）
線性加：每個RTT將CongWin增大一個MSS（擁塞避免）
乘性減：發生loss後將CongWin減半
SS（慢啟動）
當連線開始時，指數增長
轉換：
當CongWIn達到loss事件前值的一半時，從指數增長切換為線性增長；
Loss事件發生時，如果是3個重複ACK：CongWin切到一半，然後線性增長；Timeout事件：CongWin直接設為1個MSS，然後指數增長，達到threshold後，再線性增長。
TCP效能分析
TCP吞吐率（粗略）
給定擁塞視窗大小和RTT，TCP的平均吞吐率時多少？（忽略SS）
假定發生超時時CongWin大小為W，吞吐率是W/RTT；
超時後，CongWin=W/2，吞吐率是W/2RTT；
平均吞吐率0.75W/RTT；
TCP具有公平性
與UDP一起時不保證公平性，多個TCP時也不保證公平性。