一、窗口機制的分類
在TCP協議當中窗口機制分為兩種：
1.固定的窗口大小
2.滑動窗口
二、固定窗口存在的問題
如下圖所示：
我們假設這個固定窗口的大小為1，也就是每次只能發送一個數據，只有接收方對這個數據進行了確認后才能發送第二個數據。在圖中我們可以看到，發送方每發送一個數據接收方就要給發送方一個ACK對這個數據進行確認。只有接收了這個確認數據以后發送方才能傳輸下個數據。
存在的問題：如果窗口過小，當傳輸比較大的數據的時候需要不停的對數據進行確認，這個時候就會造成很大的延遲。
如果窗口過大，我們假設發送方一次發送100個數據，但接收方只能處理50個數據，這樣每次都只對這50個數據進行確認。發送方下一次還是發送100個數據，但接受方還是只能處理50個數據。這樣就避免了不必要的數據來擁塞我們的鏈路。
因此，我們引入了滑動窗口
二、滑動窗口（以字節為單位）
1.概述
滑動窗口通俗來講就是一種流量控制技術。
它本質上是描述接收方的TCP數據報緩沖區大小的數據，發送方根據這個數據來計算自己最多能發送多長的數據，如果發送方收到接收方的窗口大小為0的TCP數據報，那么發送方將停止發送數據，等到接收方發送窗口大小不為0的數據報的到來
2.工作原理
第一次發送數據這個時候的窗口大小是根據鏈路帶寬的大小來決定的。
假設這時候的窗口是3.這個時候接收方收到數據以后會對數據進行確認告訴哦發送方我下次希望收到的數據是多少。
在上圖中：我們看到接收方發送的ACK = 3（這是對發送方發送序列2的回答確認，下一次接收方期望接收到的是3序列信號），這個時候發送方收到這個數據以后就知道我第一次發送的3個數據對方只收到了兩個，就知道第三個數據對方沒有收到，下次返送的時候就從第3個數據開始發。這時候窗口大小就變為了2.
如下圖所示：
看到接收方發送的ACK是5就表示他下一次希望收到的數據是5，發送方就知道我剛才發送的2個數據對方收到了，這個時候開始發送第5個數據。
*****當鏈路變好或者變差，這個窗口還會發生變化，並不是第一次協商好了以后就永遠不會變化了。
3.死鎖狀態
（1）概述：
當接收端向發送端發送零窗口報文段后不久，接收端的接收緩存又有了一些存儲空間，於是接收端向發送端發送了Windows size = 2的報文段，然而這個報文段在傳輸過程中丟失了。發送端一直等待收到接收端發送的非零窗口的通知，而接收端一直等待發送端發送數據，這樣就死鎖了。
（2）解決方法
TCP為每個連接設有一個持續計時器。只要TCP連接的一方收到對方的零窗口通知，就啟動持續計時器，若持續計時器設置的時間到期，就發送一個零窗口探測報文段（僅攜帶1字節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
4.TCP報文段的發送時機（傳輸效率問題）
可以用以下三種不同的機制控制TCP報文段的發送時機：
（1）TCP維持一個變量MSS，等於最大報文段的長度。只要緩沖區存放的數據達到MSS字節時，就組裝成了一個TCP報文段發送出去
（2）由發送方的應用進程指明要發送的報文段，即：TCP支持推送操作
（3）發送方的一個計時器期限到了，這時就把當前已有的緩存數據裝入報文段（但長度不能超過MSS）發送出去。
5.Nagle算法（控制TCP報文段的發送時機）
（1）主旨：避免大量發送小包
（2）初衷：避免發送大量的小包，防止小包泛濫於網絡，在理想情況下，對於一個TCP連接而言，網絡上每次只能有一個小包存在。它更多的是端到端意義上的優化
【CORK算法：提高網絡利用率，理想情況下，完全避免發送小包，僅僅發送滿包以及不得不發的小包】
發送方將第一個數據字節發送出去，把后面到達的數據字節緩存起來。當發送方接收對第一個數據字符的確認后，再把發送緩存中的所有數據組裝成一個報文段再發送出去，同時繼續對隨后到達的數據進行緩存。只有在收到對前一個報文段的確認之后，才繼續發送下一個報文段。規定一個TCP連接最多只能有一個未被確認的未完成的小分組，在該分組的確認到達之前不能發送其它的小分組。當數據到達較快而網絡速率較慢時，用這樣的方法可以明顯的減少所用的網絡帶寬。
Nagle算法還規定：當達到的數據已經達到發送窗口大小的一半或者已經達到報文段的最大長度時，就可以立即發送一個報文段。
6.糊塗窗口綜合症（接收端糊塗，網絡上小包泛濫的原因之一）
（1）概述：
TCP接收方的緩存已滿，而交互式的應用進程一次只從接收緩存區中讀取1字節（這樣就使接收緩存空間僅騰出1字節），然后向發送方發送確認，並把窗口設置為1個字節（但發送的數據報為40字節的話），然后，發送方又發來1字節的數據（發送方的IP數據報是41字節），接收方發回確認，仍將窗口設置為1個字節，這樣，網絡效率就會很低
（2）解決辦法
a.你糊塗我不糊塗法。即Nagle算法。
可讓接收方等待一段時間，使得或者 接收緩存已有足夠的空間容納一個 最長的報文段，或者等到接收方緩存已有一半的空閑空間。只要出現這兩種情況，接收方就發回確認報文，並向發送方通知當前的窗口大小。此外，發送方也不要發送太小的報文段，而是把數據報文積累為足夠大的報文段或達到接收方緩存的空間的一半大小。
b.治療接收端的糊塗（其中一種機制是延遲ACK（還有其它機制，例如不發送小窗口通告等））
對於接收方而言， 延遲ACK可以拖延ACK發送時間，進而延遲窗口通告，在這段時間內，接收窗口有機會進一步放大
對於發送方而言， 不理會接收端的小窗口通告等於說不馬上1發送小包，小包有時間積累成大包
————————————————
版權聲明：本文為CSDN博主「m0_37962600」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/m0_37962600/java/article/details/79951780