哈工大計算機網絡Week3-傳輸層

目錄

• 學習目標
• 傳輸層服務概述
  • 傳輸層服務和協議
  • 傳輸層 vs. 網絡層
  • Internet傳輸層協議
• 多路複用和多路分用
  • 多路複用/分用
  • 分用如何工做？
  • 無鏈接分用（UDP）
  • 面向鏈接的分用
    • 面向鏈接的分用：多線程Web服務器
• UDP
  • UDP: User Datagram Protocol [RFC 768]
    • UDP爲何存在?
    • 應用場景
    • 報文格式
  • UDP校驗和(checksum)
    • 校驗和計算示例
• 可靠數據傳輸
  • 可靠數據傳輸協議基本結構:接口
  • 可靠數據傳輸協議
  • Rdt 1.0: 可靠信道上的可靠數據傳輸
  • Rdt 2.0: 僅產生位錯誤的信道（無丟包和亂序）
    • Rdt 2.0: FSM規約
    • Rdt 2.0: 無錯誤場景
    • Rdt 2.0: 有錯誤場景
  • Rdt 2.1
    • Rdt 2.0有什麼缺陷？
    • Rdt 2.1: 發送方, 應對ACK/NAK破壞
    • Rdt 2.1: 接收方, 應對ACK/NAK破壞
    • Rdt 2.1 vs. Rdt 2.0
  • Rdt 2.2: 無NAK消息協議
    • Rdt 2.2 FSM片斷
  • Rdt 3.0
    • Rdt 3.0發送方FSM
    • Rdt 3.0示例(1)
    • Rdt 3.0示例(2)
    • Rdt 3.0性能分析
    • Rdt 3.0: 停等操做
  • 流水線機制與滑動窗口協議
    • 流水線機制：提升資源利用率
    • 流水線協議
    • 滑動窗口協議概述
  • Go-Back-N協議
    • Go-Back-N(GBN)協議: 發送方
    • GBN: 發送方擴展FSM
    • GBN: 接收方擴展FSM
    • GBN示例
    • 練習題
  • SR（Selective Repeat）協議
    • Selective Repeat：發送方/接收方窗口
    • SR協議
    • SR協議示例
    • SR協議：困境
  • 可靠數據傳輸原理與協議回顧

學習目標

• 理解傳輸層服務的基本理論和基本機制

  • 複用/分用
  • 可靠數據傳輸機制
  • 流量控制機制
  • 擁塞控制機制

• 掌握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中顯式告知所確認的分組
  • 須要定時器

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、二、3號幀的確認，則發送方須要重發的幀數是多少？分別是那幾個幀？
解：根據GBN協議工做原理，GBN協議的確認是累積確認，因此此時發送端須要重發的幀數是4個，依次分別是四、五、六、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/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9Cspoc/W3
本文做者： ArrogantL (arrogant262@gmail.com) ： 本博客全部文章除特別聲明外，均採用 CC BY-NC-SA 4.0 許可協議。轉載請註明出處！