1，tcp傳輸報文段，傳送視窗與快取的關係？？？

2，普通意義上的，TCP傳輸報文段的時候會產生稍帶確認嗎？？？

3，接受方收到位元組確認不是按順序的，那麼對這些東西已經收到的確認號如何處理？？？

對於網路通訊，tcp傳送的都是一些報文段，裡面存在一些傳送/接受視窗

我們也清楚：傳送方的應用程序把位元組流寫入TCP的傳送快取，接受方的應用程序從TCP的接受快取中讀取位元組流

值得注意的是：快取空間和序號空間（傳送時的位元組流需要的）都是有限的，並且都是迴圈使用的

傳送快取：（用來暫時存放）

1，傳送應用程式傳送給傳送方TCP準備傳送的資料

2，TCP已傳送但尚未收到確認的資料

傳送視窗通常只是傳送快取的一部分。已被確認的資料應當從傳送快取中刪除，，因此，傳送快取和傳送視窗的後沿是重合的。傳送應用程式最後寫入傳送快取的位元組減去最後被確認的位元組，就是還保留在傳送快取中的被寫入的位元組數（也就是等待確認的位元組數）。傳送應用程式必須控制寫入快取的速率，不能太快，不然傳送快取就會沒有存放資料的空間。

接受快取：（用來暫時存放）

1，按序到達的，但尚未被接受應用程式讀取的資料

2，未按序到達的資料（也就是說，不會直接丟棄掉未按序到達的資料，會保留，等待指定的序號到達，此刻，視窗就會向前滑動）

如果收到的分組被檢測出有差錯，則要丟棄。如果接受應用程式來不及讀取收到的資料，接收快取最終會被填滿，使接收視窗減小到零。如果接收應用程式能夠及時從接收快取中讀取收到的資料，接收視窗就可以增大，但最大不能超過接受快取的大小

1，雖然A傳送方的傳送視窗是根據B接受方的接收視窗設定的，但在同一時刻，A的傳送視窗並不總和B的接收視窗一樣大。這是因為通過網路傳送視窗值需要經歷一定的時間（時間不確定）。另外，傳送方A還可能根據網路擁塞情況適當減小自己的傳送視窗數值

2，對於不按序到達的資料如何處理，TCP標準並無明確規定。如果接受方把不按序到達的資料一律丟棄，那麼接受視窗的管理將會比較簡單，但這樣做對網路資源的利用不利（因為傳送方會重複傳送特別多的資料）。因此TCP通常對不按序到達的資料是先臨時存放在接受視窗中，等到位元組流中所缺少的位元組收到後，在交付給上層應用程序

3，TCP要求接受方必須有累積確認的功能，這樣可以減少傳輸開銷。接受方可以在合適的時候傳送確認，也可以在自己有資料要傳送時把確認資訊順便稍帶上。值得注意的是：1，接受方不應該過分推遲傳送確認，不然會導致傳送方不必要的重傳，這反而浪費了網路資源，TCP規定：確認推遲時間不應超過0.5s,

      稍帶確認實際上並不經常發生，