學習目標
-
理解傳輸層服務的基本理論和基本機制
- 復用/分用
- 可靠數據傳輸機制
- 流量控制機制
- 擁塞控制機制
-
掌握Internet的傳輸層協議
- UDP：無連接傳輸服務
- TCP：面向連接的傳輸服務
- TCP擁塞控制
傳輸層服務概述
傳輸層服務和協議
- 傳輸層協議為運行在不同Host上的進程提供了一種邏輯通信機制，兩個進程之間仿佛是直接連接的，也是一種端到端的連接
- 端系統按照傳輸層協議使用傳輸層功能
- 發送方傳輸層：將應用遞交的消息分成一個或多個的Segment，並向下傳給網絡層。
- 接收方傳輸層：將接收到的segment組裝成消息，並向上交給應用層。
- 傳輸層可以為應用提供多種協議
- Internet上的TCP
- Internet上的UDP
傳輸層 vs. 網絡層
- 區分
- 網絡層：提供主機（IP地址）之間的邏輯通信機制
- 傳輸層：提供應用進程（IP：port）之間的邏輯通信機制，相對於網絡層，傳輸層的目標是更明確的，是更細分的。
- 聯系
- 傳輸層位於網絡層之上
- 傳輸層依賴於網絡層服務
- 傳輸層對網絡層服務進行（可能的）增強
Internet傳輸層協議
- 可靠、按序的交付服務(TCP)
- 擁塞控制
- 流量控制
- 連接建立
- 不可靠的交付服務(UDP)
- 基於“盡力而為(Best-effort)”的網絡層，盡力做到最好，但是沒有保證可靠性
- 兩種服務均不保證
- 延遲
- 帶寬
多路復用和多路分用
多路復用/分用
多路復用和多路分用的區別？
多路分用：接受
多路復用：發送
分用如何工作？
- 主機接收到IP數據報(datagram)（==報文段）
- 每個數據報攜帶源IP地址、目的IP地址。
- 每個數據報攜帶一個傳輸層的段(Segment）。
- 每個段攜帶源端口號和目的端口號
- 主機收到Segment之后，傳輸層協議提取IP地址和端口號信息，將Segment導向相應的Socket
- TCP做更多處理
- 網絡層不關心端口號
無連接分用（UDP）
- 利用端口號創建Socket
DatagramSocket mySocket1 = new DatagramSocket(99111);
DatagramSocket mySocket2 = new DatagramSocket(99222);
- UDP的報文段中的目的Socket用二元組標識
- (目的IP地址，目的端口號)
- 主機收到UDP段后
- 檢查段中的目的端口號
- 將UDP段導向綁定在該端口號的Socket
- 來自不同源IP地址和/或源端口號的IP數據包被導向同一個Socket
- SP：源
- DP：目的
面向連接的分用
- TCP的Socket用四元組標識
- 源IP地址
- 源端口號
- 目的IP地址
- 目的端口號
- 接收端利用所有的四個值將Segment導向合適的Socket
- 服務器可能同時支持多個TCPSocket
- 每個Socket用自己的四元組標識
- Web服務器為每個客戶端開不同的Socket
面向連接的分用：多線程Web服務器
一個進程創建多個線程，可以重復利用進程，不再是單tcp兩邊必須是獨占進程。
但是注意，多個tcp連接到某個進程的多個線程，其目的ip、port是相同的。
UDP
UDP: User Datagram Protocol [RFC 768]
功能
- 基於Internet IP協議
- 復用/分用
- 簡單的錯誤校驗
- “Best effort”服務，UDP段可能
- 丟失
- 非按序到達
- 無連接
- UDP發送方和接收方之間不需要握手
- 每個UDP段的處理獨立於其他段
UDP為什么存在?
- 無需建立連接 (減少延遲)
- 實現簡單：無需維護連接狀態
- 頭部開銷少
- 沒有擁塞控制: 應用可更好地控制發送時間和速率
應用場景
- 常用於流媒體應用
- 容忍丟失
- 速率敏感
- UDP還用於
- DNS
- SNMP
- 在UDP上實現可靠數據傳輸？
- 在應用層增加可靠性機制
- 應用特定的錯誤恢復機制
報文格式
UDP校驗和(checksum)
目的：檢測UDP段在傳輸中是否發生錯誤（如位翻轉）
- 發送方
- 將段的內容視為16-bit整數
- 校驗和計算：計算所有整數的和，進位加在和的后面，將得到的值按位求反，得到校驗和
- 發送方將校驗和放入校驗和字段
- 接收方
- 計算所收到段的校驗和
- 將其與校驗和字段進行對比
- 不相等：檢測出錯誤
- 相等：沒有檢測出錯誤（但可能有錯誤）
校驗和計算示例
可靠數據傳輸
- 什么是可靠？
- 准確（沒有bit錯誤）、完整（沒有丟包而不知道導致真正丟失）、有序（分組有序）
- 可靠數據傳輸協議
- 可靠數據傳輸對應用層、傳輸層、鏈路層都有很高的要求
- 被列為網絡Top-10問題之一
- 信道的不可靠特性決定了可靠數據傳輸協議(rdt)的復雜性
- 使用rdt縮寫可靠數據傳輸協議
可靠數據傳輸協議基本結構:接口
注意觀察四個協議箭頭的方向。
可靠數據傳輸協議
- 下面的學習過程中我們漸進地設計可靠數據傳輸協議的發送方和接收方
- 我們建立假設：只考慮單向數據傳輸。畢竟雙向是單向的擬合。
- 但控制信息雙向流動，即控制信息和數據傳輸不同。我們的控制信息還是雙向考察。
- 選擇有限狀態機(Finite State Machine, FSM)這個工具來刻畫rdt
Rdt 1.0: 可靠信道上的可靠數據傳輸
我們漸進式考察復雜rdt的第一步，先看看最簡單的情況
- 底層信道完全可靠
- 不會發生錯誤(bit error)
- 不會丟棄分組
- 發送方和接收方的FSM（有限狀態機）獨立
Rdt 2.0: 僅產生位錯誤的信道（無丟包和亂序）
- 底層信道可能翻轉分組中的位(bit)，需要檢測錯誤
- 利用校驗和檢測位錯誤
- 如何從錯誤中恢復？
- 確認機制(Acknowledgements, ACK): 接收方顯式地告知發送方分組已正 確接收
- NAK:接收方顯式地告知發送方分組有錯誤（和ack是不同的機制，兩個機制組合起來成為完整ARQ）
- 發送方收到NAK后，重傳分組==
- 基於這種重傳機制的rdt協議稱為ARQ(Automatic Repeat reQuest)自動重傳請求協議
- Rdt 2.0中引入的新機制
- 差錯檢測（如校驗和）
- 接收方反饋控制消息: ACK/NAK
- 重傳
Rdt 2.0: FSM規約
Rdt 2.0: 無錯誤場景
Rdt 2.0: 有錯誤場景
Rdt 2.1
Rdt 2.0有什么缺陷？
- 如果ACK/NAK消息發生錯誤/被破壞(corrupted)，發送方不知道接收方發生了什么會怎么樣？
- 方法1：為ACK/NAK增加校驗和，檢錯並回復錯誤（很難，不能保證100%，或者要額外代價）
- 方法2：發送方收到被破壞ACK/NAK時不知道接收方發生了什么，回復額外的控制消息。這個仍然不可以，因為控制消息也可能被破壞
- 方法3：發送方收到壞的ACK/NAK，發送方重傳全部數據
- 不能簡單的重傳數據，否則會產生重復分組
- 如何解決重復分組問題？
- 序列號(Sequence number): 發送方給每個分組增加序列號
- 接收方丟棄重復分組
- 2.0：序列號、ACK/NAK
Rdt 2.1: 發送方, 應對ACK/NAK破壞
01兩個序列號就夠了，停等協議
Rdt 2.1: 接收方, 應對ACK/NAK破壞
Rdt 2.1 vs. Rdt 2.0
- 發送方：
- 為每個分組增加了序列號
- 兩個序列號(0, 1)就夠用，為什么？因為是停等協議
- 需校驗ACK/NAK消息是否發生錯誤
- 狀態數量翻倍
- 狀態必須“記住”“當前”的分組序列號
- 接收方
- 需判斷分組是否是重復
- 當前所處狀態提供了期望收到分組的序列號
- 注意：接收方無法知道ACK/NAK是否被發送方正確收到
Rdt 2.2: 無NAK消息協議
- 我們真的需要兩種確認消息(ACK + NAK)嗎？
- 與rdt 2.1功能相同，但是只使用ACK
- 如何實現？
- 接收方通過ACK告知最后一個被正確接收的分組
- 在ACK消息中顯式地加入被確認分組的序列號
- 發送方收到重復ACK之后，采取與收到NAK消息相同的動作
- 重傳當前分組
Rdt 2.2 FSM片段
Rdt 3.0
- 如果信道既可能發生錯誤，也可能丟失分組，怎么辦？
- “校驗和 + 序列號 + ACK + 重傳”夠用嗎？
- 發送的數據：ack、數據
- ack丟失、發送數據都是都會導致停工
- “校驗和 + 序列號 + ACK + 重傳”夠用嗎？
- 方法：發送方等待“合理”時間
- 如果沒收到ACK，重傳
- 時間很難設定，如果分組或ACK只是延遲而不是丟了
- 重傳會產生重復，序列號機制能夠處理
- 接收方需在ACK中顯式告知所確認的分組
- 需要定時器
Rdt 3.0發送方FSM
Rdt 3.0示例(1)
Rdt 3.0示例(2)
Rdt 3.0性能分析
功能正確了，性能如何呢？
性能比較差！
- Rdt 3.0能夠正確工作，但性能很差
- 示例：1Gbps鏈路，15ms端到端傳播延遲，1KB分組
- 發送方利用率：發送方發送時間百分比（停等協議）
- 停等協議導致（包含ack機制），在1Gbps鏈路上每30毫秒才發送一個分組33KB/sec
- 還有重發，導致性能下降。但主要是停等協議導致的，因為並發的發送並不占用市場，而且重發是小概率事件。
- 網絡協議限制了物理資源的利用
Rdt 3.0: 停等操作
流水線機制與滑動窗口協議
流水線機制：提高資源利用率
同時發送多個不同的分組。本質上就是提升了分組大小同時保存分組的並發優勢。
翻倍提升。
流水線協議
- 允許發送方在收到ACK之前連續發送多個分組
- 更大的序列號范圍
- 發送方和/或接收方需要更大的存儲空間以緩存分組
- 為每個小分組發送ACK。發送多個ack
滑動窗口協議概述
實現流水線機制的方法。
- 滑動窗口協議: Sliding-window protocol
- 窗口是什么？
- 允使用的序列號范圍
- 窗口尺寸為N：最多有N個等待確認的消息
- 滑動窗口
- 隨着協議的運行，窗口在序列號空間內向前滑動
- 兩種滑動窗口協議：GBN, SR
Go-Back-N協議
Go-Back-N(GBN)協議: 發送方
- 分組頭部包含k-bit序列號，共2^n個序號可用
- 窗口尺寸為N，最多允許N個分組未確認
- 綠色：發送並已經確認
- 黃色：發送未確認
- 藍色：可用序列號
- 白色：可以使用的序列號
- base：尚未確認的最小號
- nextseqnum：尚未用但是可以用的最小號
- ACK(n): 序列號n及n之前(包含n)的分組均已被正確接收
- 可能收到重復ACK，不是問題
- 為空中的分組設置計時器(timer)
- 超時Timeout(n)事件: 重傳序列號未收到對應ACK的所有分組（為什么不先發第一個？退化到了rdt3.0）
GBN: 發送方擴展FSM
refuse：拒絕為上層發送，因為無序號可用。
注意觀察timer。
GBN: 接收方擴展FSM
- ACK機制: 發送擁有最高序列號的、已被正確接收的分組的ACK
- 可能產生重復ACK
- 只需要記住唯一的expectedseqnum，即現在想要的。
- 流水線機制下可能有亂序到達的分組：
- gbn下直接丟棄（接收方不設置緩存）
- 接受正確序號后，重新確認序列號最大的、按序到達的分組
GBN示例
N=4下。
練習題
數據鏈路層采用后退N幀（GBN）協議，發送方已經發送了編號為0～7的幀。當計時器超時時，若發送方只收到0、2、3號幀的確認，則發送方需要重發的幀數是多少？分別是那幾個幀？
解：根據GBN協議工作原理，GBN協議的確認是累積確認，所以此時發送端需要重發的幀數是4個，依次分別是4、5、6、7號幀。
SR（Selective Repeat）協議
- GBN有什么缺陷？重傳很多分組。
如何解決？
- 接收方窗口
- 接收方對每個分組單獨反饋ACK。
- 接收方設置緩存機制，緩存亂序到達的分組
- 發送方只重傳那些一定時間內，沒收到ACK的分組，為每個分組設置定時器。
- 發送方窗口和gbn一樣
- N個連續的序列號
- 限制已發送且未確認的分組
Selective Repeat：發送方/接收方窗口
兩個窗口是自用的，並無關聯，不對齊。
SR協議
SR協議示例
$Ns=Nr=4$
SR協議：困境
- 序列號: 0, 1, 2, 3
- 窗口尺寸：3
- 接收方能區分開右側兩種不同的場景嗎？
- a是超時
- b是3缺失導致0直接發送
- 接受端無法區分
- (a)中，發送方重發分組0, 接收方收到后會如何處理？按第二個0接受
- 產生原因：發送接受雙窗口相對與序號空間，太大了，導致雙窗口能輻射到序號相同但是內容不同的數據包。
- 問題：序列號空間大小與窗口尺寸需滿足什么關系？
- $NS+NR<=2^k$
可靠數據傳輸原理與協議回顧
- 信道的(不可靠)特性
- 可靠數據傳輸的需求
- Rdt 1.0
- Rdt 2.0, rdt 2.1, rdt 2.2
- Rdt 3.0
- 流水線與滑動窗口協議
- GBN
- SR
- 流水線與滑動窗口協議
Markdown文本：https://github.com/ArrogantL/BlogData/tree/master/計算機網絡spoc/W3
本文作者： ArrogantL (arrogant262@gmail.com)
版權聲明： 本博客所有文章除特別聲明外，均采用 CC BY-NC-SA 4.0 許可協議。轉載請注明出處！