速讀原著-TCP/IP(擁塞舉例)

• 2020 年 3 月 12 日
• 筆記

第21章 TCP的超時與重傳

21.5 擁塞舉例

現在觀察一下數據報文段的傳輸過程。圖 2 1 – 6顯示了報文段中數據的起始序號與該報文段發送時間的對比圖。它提供了一種較好的數據傳輸的可視化方法。通常代表數據的點將向上和向右移動，這些點的斜率就表示傳輸速率。當這些點向下和向右移動則表示發生了重傳。在2 1 . 4節開始時，我們曾提到整個傳輸的時間約為 4 5秒，但在本圖中只顯示了 3 5秒鐘。

這3 5秒只是數據報文段發送的時間。因為第 1個S Y N看來是丟失了並被重傳（見圖 2 1 – 5），因此第1個數據報文段是在第 1個S Y N發送6 . 3秒後才發送的。而且，在發送最後一個數據報文段和F I N（圖2 1 – 6中的3 4 . 1秒）之後，在接收方的 F I N到達之前，又花費了另外的 4 . 0秒接收來自接收方的最後1 4個A C K。

可以立即看到圖 2 1 – 6中發生在時刻 1 0，1 4和2 1附近的3個重傳。我們還可以看到在這 3個點中只進行了一次報文段的重傳，因為只有一個點下垂低於向上的斜率。

仔細檢查一下這幾個下垂點中的第 1個點（在1 0秒標記處的附近）。整理t c p d u m p的輸出結果可以得到圖2 1 – 7。

在這個圖中，除了下面將要討論的報文段 7 2，已經去掉了其他所有的窗口通告。主機s l i p總是通告窗口大小為 4 0 9 6，而主機v a n g o g h則通告窗口為 8 1 9 2。該圖中報文段的編號可以看作是圖 2 1 – 2的延續，在那裡報文段的編號從 1開始。與圖2 1 – 2一樣，報文段根據在 s l i p上發送和接收的順序進行編號， t c p d u m p在主機s l i p上運行。我們還去掉了一些與討論無關的段（第44, 47和4 9以及所有來自v a n g o g h的A C K）

看來報文段4 5丟失或損壞了，這一點無法從該輸出上進行辨認。能夠在主機 s l i p上看到的是對第6 6 5 7位元組（報文段5 8）以前數據的確認（不包括位元組 6 6 5 7在內）。緊接著的是帶有相同序號的8個A C K。正是接收到報文段 6 2，也就是第3個重複A C K，才引起自序號6 6 5 7開始的數據報文段（報文段 6 3）進行重傳。的確，源於伯克利的 T C P實現對收到的重複 A C K進行計 數，當收到第3個時，就假定一個報文段已經丟失並重傳自那個序號起的一個報文段。這就是J a c o b s o n的快速重傳演算法，該演算法通常與他的快速恢復演算法一起配合使用。我們在第 2 1 . 7節中介紹這兩個演算法。

注意到在重傳後（報文段 6 3），發送方繼續正常的數據傳輸（報文段 6 7、6 9和7 1）。T C P不需要等待對方確認重傳。

現在檢查一下在接收端發生了什麼。當按序收到正常數據（報文段 4 3）後，接收 T C P將2 5 5個位元組的數據交給用戶進程。但下一個收到的報文段（報文段 4 6）是失序的：數據的開始序號（6 9 1 3）並不是下一個期望的序號（ 6 6 5 7）。T C P保存2 5 6位元組的數據，並返回一個已成功接收數據的最大序號加 1（6 6 5 7）的A C K。被v a n g o g h接收到的後面 7個報文段（ 48, 50,52, 54, 55, 57和5 9）也是失序的，接收方T C P保存這些數據併產生重複A C K。

目前T C P尚無辦法告訴對方缺少一個報文段，也無法確認失序數據。此時主機 v a n g o g h所能夠做的就是繼續發送確認序號為 6 6 5 7的A C K。

當缺少的報文段（報文段 6 3）到達時，接收方T C P在其快取中保存第 6 6 5 7 ~ 8 9 6 0位元組的數據，並將這2 3 0 4位元組的數據交給用戶進程。所有這些數據在報文段 7 2中進行確認。請注意此時該A C K通告窗口大小為5 8 8 8（8 1 9 2-2 3 0 4），這是因為用戶進程沒有機會讀取這些已準備好的2 3 0 4位元組的數據。

如果仔細檢查圖21-6 中t c p d u m p的輸出中第1 4和2 1秒附近的下垂點，我們會看到它們也是由於收到了3個重複A C K引起的，這表明一個分組已經丟失。在這些例子中只有一個分組被重傳。

在介紹完擁塞避免演算法後，將在第 2 1 . 8節中繼續討論這個例子。