1、第13講第5章 運輸層(3)第 5 章 運輸層5.1 運輸層協議概述5.2 用戶數據報協議 UDP5.3 傳輸控制協議 TCP 概述5.4 可靠傳輸的工作原理5.5 TCP 報文段的首部格式5.6 TCP 可靠傳輸的實現5.7 TCP的流量控制5.8 TCP 的擁塞控制5.9 TCP 的運輸連接管理5.6 TCP 可靠傳輸的實現5.6.1 以字節為單位的滑動窗口前移不允許發送已發送并收到確認A 的發送窗口 = 20允許發送的序號26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

2、54 55 56B 期望收到的序號前沿后沿前移收縮根據 B 給出的窗口值A 構造出自己的發送窗口 TCP 標準強烈不贊成發送窗口前沿向后收縮 不允許發送已發送并收到確認A 的發送窗口位置不變允許發送但尚未發送26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55已發送但未收到確認56P1P2P3不允許接收已發送確認并交付主機B 的接收窗口允許接收26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 4

3、7 48 49 50 51 52 53 54 55 56未按序收到可用窗口A 發送了 11 個字節的數據 P3 P1 = A 的發送窗口（又稱為通知窗口）P2 P1 = 已發送但尚未收到確認的字節數P3 P2 = 允許發送但尚未發送的字節數（又稱為可用窗口） 允許發送但尚未發送A 的發送窗口向前滑動26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55已發送并收到確認不允許發送已發送但未收到確認56P1P2P3允許接收B 的接收窗口向前滑動26 27 28 29 30 3

4、1 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55已發送確認并交付主機不允許接收56未按序收到A 收到新的確認號，發送窗口向前滑動 先存下，等待缺少的數據的到達不允許發送已發送并收到確認A 的發送窗口已滿，有效窗口為零26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55已發送但未收到確認56P1P2P3A 的發送窗口內的序號都已用完，但還沒有再收到確認，必須停止發送。 發送緩

5、存 最后被確認的字節發送應用程序發送緩存最后發送的字節發送窗口TCP序號增大接收緩存接收應用程序已收到接收窗口TCP接收緩存下一個讀取的字節序號增大下一個期望收到的字節（確認號）發送緩存與接收緩存的作用n發送緩存用來暫時存放：n 發送應用程序傳送給發送方 TCP 準備發送的數據；n TCP 已發送出但尚未收到確認的數據。n接收緩存用來暫時存放：n 按序到達的、但尚未被接收應用程序讀取的數據；n 不按序到達的數據。 需要強調三點nA 的發送窗口并不總是和 B 的接收窗口一樣大（因為有一定的時間滯后）。nTCP 標準沒有規定對不按序到達的數據應如何處理。通常是先臨時存放在接收窗口中，等到字節流中所

6、缺少的字節收到后，再按序交付上層的應用進程。nTCP 要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。 5.6.2 超時重傳時間的選擇n重傳機制是 TCP 中最重要和最復雜的問題之一。nTCP 每發送一個報文段，就對這個報文段設置一次計時器。只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。往返時延的方差很大n由于 TCP 的下層是一個互聯網環境，IP 數據報所選擇的路由變化很大。因而運輸層的往返時間的方差也很大。時間數據鏈路層運輸層T1T2T3往返時間的概率分布加權平均往返時間nTCP 保留了 RTT 的一個加權平均往返時間 RTTS（這又稱為平滑的往返時間）。n第一次測

7、量到 RTT 樣本時，RTTS 值就取為所測量到的 RTT 樣本值。以后每測量到一個新的 RTT 樣本，就按下式重新計算一次 RTTS： 新的 RTTS (1 ) (舊的 RTTS) (新的 RTT 樣本) (5-4)n式中，0 1。若 很接近于零，表示 RTT 值更新較慢。若選擇 接近于 1，則表示 RTT 值更新較快。nRFC 2988 推薦的 值為 1/8，即 0.125。 超時重傳時間 RTO (RetransmissionTime-Out) nRTO 應略大于上面得出的加權平均往返時間 RTTS。nRFC 2988 建議使用下式計算 RTO：n RTO RTTS + 4 RTTD (

8、5-5)nRTTD 是 RTT 的偏差的加權平均值。nRFC 2988 建議這樣計算 RTTD。第一次測量時，RTTD 值取為測量到的 RTT 樣本值的一半。在以后的測量中，則使用下式計算加權平均的 RTTD：新的 RTTD = (1 ) (舊的RTTD) + RTTS 新的 RTT 樣本 (5-6)n 是個小于 1 的系數，其推薦值是 1/4，即 0.25。往返時間 RTT?往返時間的測量相當復雜 nTCP 報文段 1 沒有收到確認。重傳（即報文段 2）后，收到了確認報文段 ACK。n如何判定此確認報文段是對原來的報文段 1 的確認，還是對重傳的報文段 2 的確認？ 發送一個TCP 報文段超

9、時重傳TCP 報文段收到 ACK時間12往返時間 RTT?是對哪一個報文段的確認？Karn 算法 n在計算平均往返時間 RTT 時，只要報文段重傳了，就不采用其往返時間樣本。n這樣得出的加權平均平均往返時間 RTTS 和超時重傳時間 RTO 就較準確。 n報文段每重傳一次，就把 RTO 增大一些：新的 RTO (舊的 RTO) n系數 的典型值是 2 。n當不再發生報文段的重傳時，才根據報文段的往返時延更新平均往返時延 RTT 和超時重傳時間 RTO 的數值。n實踐證明，這種策略較為合理。 修正的 Karn 算法 5.6.3 選擇確認 SACK(Selective ACK) n接收方收到了和前

10、面的字節流不連續的兩個字節塊。n如果這些字節的序號都在接收窗口之內，那么接收方就先收下這些數據，但要把這些信息準確地告訴發送方，使發送方不要再重復發送這些已收到的數據。 1 1000 1501 3000 3501 4500確認號 = 1001L1 = 1501L2 = 3501R1 = 3001R1 = 4501接收到的字節流序號不連續 連續的字節流第一個字節塊第二個字節塊 和前后字節不連續的每一個字節塊都有兩個邊界： 左邊界和右邊界。圖中用四個指針標記這些邊界。 第一個字節塊的左邊界 L1 = 1501，但右邊界 R1 = 3001。 左邊界指出字節塊的第一個字節的序號，但右邊界減 1 才是

11、 字節塊中的最后一個序號。 第二個字節塊的左邊界 L2 = 3501，而右邊界 R2 = 4501。 RFC 2018 的規定n如果要使用選擇確認，那么在建立 TCP 連接時，就要在 TCP 首部的選項中加上“允許 SACK”的選項，而雙方必須都事先商定好。n如果使用選擇確認，那么原來首部中的“確認號字段”的用法仍然不變。只是以后在 TCP 報文段的首部中都增加了 SACK 選項，以便報告收到的不連續的字節塊的邊界。n由于首部選項的長度最多只有 40 字節，而指明一個邊界就要用掉 4 字節，因此在選項中最多只能指明 4 個字節塊的邊界信息。5.7 TCP 的流量控制5.7.1 利用滑動窗口實現

12、流量控制n一般說來，我們總是希望數據傳輸得更快一些。但如果發送方把數據發送得過快，接收方就可能來不及接收，這就會造成數據的丟失。n流量控制(flow control)就是讓發送方的發送速率不要太快，既要讓接收方來得及接收，也不要使網絡發生擁塞。n利用滑動窗口機制可以很方便地在 TCP 連接上實現流量控制。 seq = 1, DATAseq = 201, DATAseq = 401, DATAseq = 301, DATAseq = 101, DATAseq = 201, DATAseq = 501, DATAACK = 1, ack = 201, rwnd = 300ACK = 1, ack

13、= 601, rwnd = 0ACK = 1, ack = 501, rwnd = 100AB允許 A 發送序號 201 至 500 共 300 字節A 發送了序號 101 至 200，還能發送 200 字節A 發送了序號 301 至 400，還能再發送 100 字節新數據A 發送了序號 1 至 100，還能發送 300 字節A 發送了序號 401 至 500，不能再發送新數據了A 超時重傳舊的數據，但不能發送新的數據允許 A 發送序號 501 至 600 共 100 字節A 發送了序號 501 至 600，不能再發送了不允許 A 再發送（到序號 600 為止的數據都收到了）丟失！流量控制舉例

14、A 向 B 發送數據。在連接建立時，B 告訴 A：“我的接收窗口 rwnd = 400（字節）”。持續計時器(persistence timer)。nTCP 為每一個連接設有一個持續計時器。n只要 TCP 連接的一方收到對方的零窗口通知，就啟動持續計時器。n若持續計時器設置的時間到期，就發送一個零窗口探測報文段（僅攜帶 1 字節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。n若窗口仍然是零，則收到這個報文段的一方就重新設置持續計時器。n若窗口不是零，則死鎖的僵局就可以打破了。 5.7.2 必須考慮傳輸效率n可以用不同的機制來控制 TCP 報文段的發送時機:n第一種機制是 TCP

15、維持一個變量，它等于最大報文段長度 MSS。只要緩存中存放的數據達到 MSS 字節時，就組裝成一個 TCP 報文段發送出去。n第二種機制是由發送方的應用進程指明要求發送報文段，即 TCP 支持的推送(push)操作。n第三種機制是發送方的一個計時器期限到了，這時就把當前已有的緩存數據裝入報文段（但長度不能超過 MSS）發送出去。5.8 TCP的擁塞控制5.8.1 擁塞控制的一般原理 n在某段時間，若對網絡中某資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變壞產生擁塞(congestion)。n出現資源擁塞的條件： 對資源需求的總和 可用資源 (5-7) n若網絡中有許多資源同時產生擁

16、塞，網絡的性能就要明顯變壞，整個網絡的吞吐量將隨輸入負荷的增大而下降。 擁塞控制與流量控制的關系 n擁塞控制所要做的都有一個前提，就是網絡能夠承受現有的網絡負荷。n擁塞控制是一個全局性的過程，涉及到所有的主機、所有的路由器，以及與降低網絡傳輸性能有關的所有因素。 n流量控制往往指在給定的發送端和接收端之間的點對點通信量的控制。 n流量控制所要做的就是抑制發送端發送數據的速率，以便使接收端來得及接收。 擁塞控制所起的作用 提供的負載吞吐量理想的擁塞控制實際的擁塞控制0死鎖（吞吐量 = 0）無擁塞控制擁塞輕度擁塞擁塞控制的一般原理 n擁塞控制是很難設計的，因為它是一個動態的（而不是靜態的）問題。n

17、當前網絡正朝著高速化的方向發展，這很容易出現緩存不夠大而造成分組的丟失。但分組的丟失是網絡發生擁塞的征兆而不是原因。n在許多情況下，甚至正是擁塞控制本身成為引起網絡性能惡化甚至發生死鎖的原因。這點應特別引起重視。 開環控制和閉環控制 n開環控制方法就是在設計網絡時事先將有關發生擁塞的因素考慮周到，力求網絡在工作時不產生擁塞。 n閉環控制是基于反饋環路的概念。屬于閉環控制的有以下幾種措施： n監測網絡系統以便檢測到擁塞在何時、何處發生。n將擁塞發生的信息傳送到可采取行動的地方。n調整網絡系統的運行以解決出現的問題。第四章部分習題4-29、一個自治系統有、一個自治系統有5個局域網，其連接圖如個局域

18、網，其連接圖如圖圖4-55示。示。LAN2至至LAN5上的主機數分別為：上的主機數分別為：91，150，3和和15。該自治系統分配到的。該自治系統分配到的IP地址地址塊為塊為30.138.118/23。試給出每一個局域網的地址。試給出每一個局域網的地址塊（包括前綴）。塊（包括前綴）。方案1（24位上取0）118（01110110)局域局域網網主機數，應有位數主機數，應有位數（說明）（說明）24至至29的值的值地址塊地址塊/網絡前綴網絡前綴最小地址最小地址最大地址最大地址LAN3150，8（27-2=）126150+1254（=28-2）030.138.118.0/2430.138.118.030.138.118.255LAN291，7（26-2=）6291+1126（=27-2）1030.138.119.0/2530.138.119.030.138.119.127LAN515，5（24-2=）1415+130（=25-2）111030.1