tcp的滑動視窗是以位元組為單位的。現假設a收到了b發來的確認報文段，其中視窗是20位元組，而確認號是31.根據這兩個資料，a就構造出自己的傳送視窗。如下圖所示。
傳送視窗表示：在沒收收到b的確認情況下，a可以連續把視窗內的資料都傳送出去。凡是已經傳送的資料，在未收到確認之前都必須暫時保留，以便超時重傳。傳送視窗裡面的序號表示允許傳送的序號。顯然，視窗越大，傳送方就可以在收到對方確認之前連續傳送更多的資料，因而具有更高的傳輸效率。但是接受方必須來得及處理這些資料。
傳送視窗後沿表示已經傳送且已經收到了確認。這些資料不需要再保留在快取。傳送視窗前沿的前面部分表示不允許傳送的資料，因為接收方沒有為這部分資料保留臨時存放的快取空間。傳送視窗的位置由視窗前沿和後沿的位置共同確認。傳送視窗後沿的變化情況有兩種可能，即不動（沒有收到新的確認）和前移（收到了新的確認）。傳送視窗後沿不能向後移動，因為不能撤銷已收到的確認。傳送視窗前沿通常是不斷向前移動，但也有可能不動。傳送視窗前沿也有可能向後收縮。這發生在對方通知的視窗縮小了。但tcp的標準強烈不贊成這樣。因為很有可能傳送方在收到這個通知以前已經傳送了視窗中很多的資料，現在又要收縮視窗，不讓傳送這些資料，這樣會產生一些錯誤。
如圖b的接收視窗大小是20.在接收視窗外面到30號為止的資料是已經傳送過確認的，並且已經交付給主機。因此b可以不保留這些資料。接收視窗內的序號（31~50）是允許接收的。如上圖b收到了32和33號資料。這些資料沒有按序到達，因為對按序接收到的資料中的最高序號給出確認，因此b傳送的確認號任然是31（即期望收到的序號）,而不能是32或33.
tcp的傳送方在規定的時間內沒有收到確認就要重傳已傳送的報文段。重傳時間的選擇是tcp最複雜的問題之一。如果把超時重傳時間設定太短，就會引起許多報文段不必要的重傳，是網路負荷增大。但把超時重傳時間設定的太長，則又使網路的空閒時間增大，降低傳輸效率。
TCP可靠傳輸的實現
1.概述 為方便描述可靠傳輸原理，假定資料傳輸只在乙個方向上進行，即a傳送資料，b給出確認 2.以位元組為單位的滑動視窗 tcp的滑動視窗是以位元組為單位的。為了便於說明，位元組編號取得很小。先假定a收到b發來的確認報文字段，其中視窗是20位元組，而確認號是31位元組。表明b期望接收到的下乙個序號是...
TCP可靠傳輸的實現
滑動視窗是指傳送方維護乙個固定大小的環形鍊錶做資料快取，快取上有三個指標 p1已傳送未確認的首位址，p2已傳送未確認的尾位址 允許傳送但未傳送首位址 p3允許傳送但未傳送尾位址 未傳送首位址 視窗的大小由接收方控制。傳送資料後，需要等待接收方的確認，直到收到確認資訊後，才會移動p1指標，相當於在未接...
TCP可靠傳輸的實現
tcp的滑動視窗是以位元組為單位的。現假設a收到了b發來的確認報文段，其中視窗是20位元組，而確認號是31.根據這兩個資料，a就構造出自己的傳送視窗。如下圖所示。傳送視窗表示 在沒收收到b的確認情況下，a可以連續把視窗內的資料都傳送出去。凡是已經傳送的資料，在未收到確認之前都必須暫時保留，以便超時重...