傳輸層服務和協議
傳輸層協議為運行在不同Host上的行程提供了一種邏輯通信機制
- 端系統運行傳輸層協議
- 發送方：將應用遞交的訊息分成一個或多
- 個的Segment，并向下傳給網路層，
- 接收方：將接收到的segment組裝成訊息，并向上交給應用層，
- 傳輸層可以為應用提供多種協議
- Internet上的TCP
- Internet上的UDP
網路層：提供 主機之間的邏輯通信機制
傳輸層：提供 應用行程之間的邏輯通信機制，位于網路層之上，依賴于網路層服務，對網路層服務進行（可能的）增強
Internet傳輸層協議
- 可靠、按序的交付服務(TCP)
- 擁塞控制
- 流量控制
- 連接建立
- 不可靠的交付服務(UDP)
- 基于“盡力而為(Best-effort)”的網路層，沒有做（可靠性方面的）擴展
- 兩種服務均不保證
- 延遲
- 帶寬
多路復用/分用
如果某層的一個協議對應直接上層的多個協議/ 物體 ， 則需要復用/分用
主機接收到IP資料報(datagram)， 每個資料報攜帶源IP地址、目的IP地址，，每個資料報攜帶一個傳輸層的段(Segment），每個段攜帶源埠號和目的埠號
主機收到Segment之后，傳輸層協議提取IP地址和埠號資訊，將Segment導向相應的Socket，TCP做更多處理
無連接分用
利用埠號創建Socket
···
DatagramSocket mySocket1 = new DatagramSocket(99111);
DatagramSocket mySocket2 = new DatagramSocket(99222);
···
UDP的Socket用二元組標識( 目的IP 地址 ， 目的埠號)，主機收到UDP段后檢查段中的目的埠號，將UDP段導向系結在該埠號的Socket，來自不同源IP地址和/或源埠號的IP資料包被導向同一個Socket
面向連接的分用
TCP的Socket用四元組標識：源IP 地址，源埠號，目的IP 地址，目的埠號，接收端利用所有的四個值將Segment導向合適的Socket，服務器可能同時支持多個TCPSocket，每個Socket用自己的四元組標識，Web服務器為每個客戶端開不同的Socket
面向連接的分用 ： 多執行緒Web 服務器
UDP
- 基于Internet IP協議
- 復用/分用
- 簡單的錯誤校驗
- “Best effort”服務，UDP段可能
- 丟失
- 非按序到達
- 無連接
- UDP發送方和接收方之間不需要握手
- 每個UDP段的處理獨立于其他段
UDP 為什么存在?
- 無需建立連接 ( 減少延遲)
- 實作簡單 ： 無需維護連接狀態
- 頭部開銷少
- 沒有擁塞控制: 應用可更好地控制發送時間和速率
常用于流媒體應用：容忍丟失， 速率敏感
UDP還用于：DNS， SNMP
在UDP上實作可靠資料傳輸？
- 在應用層增加可靠性機制
- 應用特定的錯誤恢復機制
UDP 校驗和(checksum)
目的 ： 檢測UDP 段在傳輸中是否發生錯誤 （ 如位翻轉）
發送方： 將段的內容視為16-bit 整數，校驗和計算 ： 計算所有整數的和， 進位加在和的后面 ， 將得到的值按位求反 ， 得到校驗和， 發送方將校驗和放入校驗和欄位
接收方：計算所收到段的校驗和， 將其與校驗和欄位進行對比
? 不相等 ： 檢測出錯誤
? 相等 ： 沒有檢測出錯誤 （ 但可能有錯誤 ）
可靠資料傳輸原理
- 什么是可靠 ？
- 不錯、不丟、不亂
- 可靠資料傳輸協議
- 可靠資料傳輸對應用層、傳輸層、鏈路層都很重要
- 網路Top-10問題
- 信道的不可靠特性決定了可靠資料傳輸協議(rdt)的復雜性
可靠資料傳輸協議基本結構: 介面
漸進地設計可靠資料傳輸協議的發送方和接收方，只考慮單向資料傳輸，但控制資訊雙向流動，利用狀態機(Finite State Machine, FSM)刻畫傳輸協議
Rdt 1.0: 可靠信道上的可靠資料傳輸
底層信道完全可靠：不會發生錯誤(bit error)，不會丟棄分組，發送方和接收方的FSM獨立
Rdt 2.0: 產生位錯誤的信道
- 底層信道可能翻轉分組中的位(bit)
- 利用 校驗和 檢測位錯誤
- 如何從錯誤中恢復 ？
- 確認機制(Acknowledgements, ACK): 接收方顯式地告知發送方分組已正確接收
- NAK: 接收方顯式地告知發送方分組有錯誤
- 發送方收到NAK 后 ， 重傳 分組
- 基于這種重傳機制的rdt 協議稱為ARQ(Automatic Repeat reQuest) 協議
- Rdt 2.0 中引入的新機制
- 差錯檢測
- 接收方反饋控制訊息: ACK/NAK
- 重傳
Rdt 2.0: FSM
Rdt 2.0: 無錯誤場景
Rdt 2.0: 有錯誤場景
Rdt 2.1 和2.2
Rdt 2.0 有什么缺陷 ？
如果ACK/NAK 訊息發生錯誤/ 被破壞(corrupted) 會怎么樣 ？
- 為ACK/NAK 增加校驗和 ， 檢錯并糾錯
- 發送方收到被破壞ACK/NAK 時不知道接收方發生了什么 ， 添加額外的控制訊息
- 如果ACK/NAK 壞掉 ， 發送方重傳
- 不能簡單的重傳 ： 產生
如何解決重復分組問題 ？ - 序列號(Sequence number): 發送方給每個分組增加序列號
- 接收方丟棄重復分組
Rdt 2.1: 發送方, 應對ACK/NAK 破壞
Rdt 2.1: 接收方, 應對ACK/NAK 破壞
發送方：
- 為每個分組增加了序列號
- 兩個序列號(0, 1)就夠用
- 需校驗ACK/NAK訊息是否發生錯誤
- 狀態數量翻倍
- 狀態必須“記住”“當前”的分組序列號
接收方
- 需判斷分組是否是重復
- 當前所處狀態提供了期望收到分組的序列號
- 注意：接收方無法知道ACK/NAK是否被發送方正確收到
Rdt 2.2: 無NAK 訊息協議
我們真的需要兩種確認訊息(ACK + NAK) 嗎 ？與rdt 2.1 功能相同 ， 但是只使用ACK, 接收方通過ACK, 在ACK 訊息中顯式地加入被確認分組的序列號,發送方收到重復ACK 之后 ， 采取與收到NAK 訊息相同的動作, 重傳當前分組
Rdt 3.0
如果信道既可能發生錯誤 ， 也可能丟失分組 ， 怎么辦?“校驗和 + 序列號 + ACK + 重傳”夠用嗎？
方法：發送方等待“合理”時間
- 如果沒收到ACK，重傳
- 如果分組或ACK只是延遲而不是丟了
- 重傳會產生重復，序列號機制能夠處理
- 接收方需在ACK中顯式告知所確認的分組
- 需要定時器
Rdt 3.0 發送方FSM
Rdt 3.0: 停等操作
流水線機制 ： 提高資源利用率
流水線協議
允許發送方在收到ACK之前連續發送多個分組
- 更大的 序列號范圍
- 發送方和/或接收方需要更大的存盤空間以 快取分組
滑動視窗協議
滑動視窗協議: Sliding-window protocol
視窗
- 允許使用的序列號范圍
- 視窗尺寸為N：最多有N個等待確認的訊息
滑動視窗: 隨著協議的運行，視窗在序列號空間內向前滑動
滑動視窗協議：GBN, SR
Go-Back-N 協議
Go-Back-N(GBN) 協議: 發送方
- 分組頭部包含k-bit序列號
- 視窗尺寸為N，最多允許N個分組未確認
- ACK(n): 確認到序列號n(包含n)的分組均已被正確接收
- 可能收到重復ACK
- 為空中的分組設定計時器(timer)
- 超時Timeout(n)事件: 重傳序列號大于等于n，還未收到ACK的所有分組
GBN: 發送方擴展FSM
GBN: 接收方擴展FSM
ACK機制: 發送擁有最高序列號的、已被正確接收的分組的ACK,可能產生重復ACK只需要記住唯一的expectedseqnum
亂序到達的分組：
- 直接丟棄?接收方沒有快取
- 重新確認序列號最大的、按序到達的分組
Selective Repeat 協議
GBN 有什么缺陷 ？
- 接收方對每個分組單獨進行確認
- 設定快取機制，快取亂序到達的分組
- 發送方只重傳那些沒收到ACK的分組
- 為每個分組設定定時器
- 發送方視窗
- N個連續的序列號
- 限制已發送且未確認的分組
小節
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/182461.html
標籤：其他
上一篇：軟體設計模式修煉 -- 組合模式