tcp的滑動視窗是以位元組為單位的。現假定a收到了b發來的確認報文段，其中視窗是20位元組，而確認號是31（這表明b期望接收到的下乙個序列號為31，而序號30為止的資料已經接收到了），根據這兩個資料，a就構造出了自己的傳送視窗，如圖5-15所示。
我們首先討論傳送發a的傳送視窗，傳送視窗表示：在沒有收到b確認的情況下，a可以連續的把視窗內的資料都傳送出去。凡是已經傳送出去的資料，在未收到確認之前都必須暫時保留，以便在重傳時使用。
傳送視窗裡面的序號表示允許傳送的序號，顯然，視窗越大，傳送方就可以在收到對方確認之前傳送的資料就越多，因此就可以提高傳輸速率。前面講過，接收方會把自己的接收視窗數值放在視窗欄位中傳送給對方。因此，a 的傳送視窗一定不能超過 b 的接收視窗數值。在後面的我們將要討論，傳送方的傳送視窗大小還要受到當時網路擁塞程度的制約。但在目前，我們暫不考慮網路擁塞的影響。
傳送視窗後延部分表示已經已經傳送且收到了確認。這些資料顯然不在需要保留了，傳送視窗前沿的部分表示不允許傳送，因為接收方還沒有為這部分資料提供快取空間。
傳送視窗的位置由視窗前沿和後延位置共同確定。傳送視窗後沿的變化情況有兩種可能，即不動（沒有收到新的確認）和前移（收到了新的確認）。傳送視窗後沿不可能向後移動，因為不能撤銷掉已收到的確認。傳送視窗前沿通常是不斷向前移動，但也有可能不動。這對應於兩種情況：一是沒有收到新的確認，對方通知的視窗大小也不變；二是收到了新的確認但對方通知的視窗縮小了，使得傳送視窗前沿正好不動。
傳送視窗前沿也有可能向後收縮。這發生在對方通知的視窗縮小了。但 tcp 的標準強
烈不贊成這樣做。因為很可能傳送方在收到這個通知以前已經傳送了視窗中的許多資料，現
在又要收縮視窗，不讓傳送這些資料，這樣就會產生一些錯誤。
現在假定 a 傳送了序號為 31 ～ 41 的資料。這時，傳送視窗位置並未改變（圖 5-16），
但傳送視窗內靠後面有 11 個位元組（灰色小方框表示）表示已傳送但未收到確認。而傳送窗
口內靠前面的9個位元組（42～50）是允許傳送但尚未傳送的。
從以上所述可以看出，要描述乙個傳送視窗的狀態需要三個指標：p1，p2和 p3（圖 5-16)。指標都指向位元組的序號。這三個指標指向的幾個部分的意義如下：
再看一下b 的接收視窗。b 的接收視窗大小是 20。在接收視窗外面，到 30 號為止的資料是已經傳送過確認，並且已經交付主機了。因此在 b 可以不再保留這些資料。接收視窗內的序號（31 ～ 50）是允許接收的。在圖 5-16 中，b 收到了序號為 32 和 33 的資料。這些資料沒有按序到達，因為序號為 31 的資料沒有收到（也許丟失了，也許滯留在網路中的某處）。請注意，b只能對按序收到的資料中的最高序號給出確認，因此 b 傳送的確認報文段中的確認號仍然是31（即期望收到的序號），而不能是32或33。
現在假定b收到了序號為31的資料，並把序號為31～33的資料交付主機，然後b刪除這些資料。接著把接收視窗向前移動3個序號（圖5-17），同時給a傳送確認，其中視窗值仍為 20，但確認號是 34。這表明 b 已經收到了到序號 33 為止的資料。我們注意到，b還收到了序號為37,38和40的資料，但這些都沒有按序到達，只能先暫存在接收視窗中。a 收到 b 的確認後，就可以把傳送視窗向前滑動 3 個序號，但指標 p2不動。可以看出，現在 a 的可用視窗增大了，可傳送的序號範圍是 42～53。
a 在繼續傳送完序號 42 ~ 53 的資料後，指標 p2向前移動和 p3重合。傳送視窗內的序號都已用完，但還沒有再收到確認（圖5-18）。由於a的傳送視窗已滿，可用視窗已減小到零，因此必須停止傳送。請注意，存在下面這種可能性，就是傳送視窗內所有的資料都已正確到達b，b也早已發出了確認。但不幸的是，所有這些確認都滯留在網路中。在沒有收到b的確認時，a不能猜測：「或許b收到了吧！為了保證可靠傳輸，a只能認為b還沒有收到這些資料。於是，a在經過一段時間後（由超時計時器控制）就重傳這部分資料，重新設定超時計時器，直到收到 b 的確認為止。如果 a 收到確認號落在傳送視窗內，那麼 a 就可以使傳送視窗繼續向前滑動，並傳送新的資料。
傳送方的應用程序把位元組流寫入了tcp的傳送快取中，接收方的應用程序從tcp的接收快取中讀取位元組流資料。下面我們就討論視窗和快取之間的關係.這裡首先明確兩點:
我們首先檢視一下圖5-19（a）傳送方的情況：
傳送快取用來暫時存放：
傳送視窗只是傳送快取的一部分，已被確認的資料應當從快取中被刪除。因此傳送快取和傳送視窗的後延是重合的。傳送應用程式最後寫入傳送快取的位元組減去最後被確認的位元組，就是還保留在傳送傳中的被寫入的位元組數。傳送應用程序必須控制寫入快取中的速度。不能太快，否則傳送快取就沒有存放資料的空間。
再看一下圖（b）接收方的情況。
接收快取暫時用來存放：
如果收到的分組有差錯，則要丟棄 。如果接收應用程序來不及讀取收到的資料，接收快取中就會被填滿，使接收視窗減少到0。反之，如果接收應用程式接收到資料能夠及時從接受快取中讀取到資料，接收視窗就可以增大，但最大就不能超過接收快取的大小。圖（b）還指出了下乙個期待收到的位元組號，這個位元組號也是接收方給傳送方的報文段中首部的確認號。
根據以上總結出：
最後強調：tcp通訊是全雙工通訊。通訊中的每一方都在傳送和接收報文段，因此，每一方都有自己的傳送視窗和接收視窗。在談到這些視窗的時候，一定要分清楚。
計算機網路 TCP如何保證可靠傳輸
tcp 協議如何保證可靠傳輸？1 資料被分割成資料塊。2 tcp 給傳送的每 個包編號，接收 對包排序，把有序資料傳給應 層。3 校驗和 保持 部和資料的檢驗和。如果收到報文段的檢驗和有錯，將丟棄且不確認收到該報 段。4 接收端丟棄重複資料。5 流量控制 利 滑動窗 實現，只允許傳送 接收端緩衝區 ...
計算機網路3 可靠傳輸
title 計算機網路3 可靠傳輸 mathjax true date 2020 03 19 13 33 04 categories 計算機網路 tags 計算機網路 keywords 計算機網路 不可靠傳輸，voice over ip dns rpc dhcp?16位源埠，16位目標埠，16位ud...
計算機網路 TCP怎麼保證可靠？
tcp資料段以位元組為單位對資料段中的 資料 部分進行一一編號，確保每個位元組的資料都可以有序傳送和接收。序號 序號tcp傳送的資料段中 資料 部分 不包括tcp資料段頭部 每個位元組都有乙個序號，每個資料段中的 序號 欄位是以該資料段中第乙個位元組的序號進行填充的。確認號 確認號確認號指傳送包含這...