一文了解滑動窗口協議

來源：Java 極客技術

昨天我們簡單說了這個 HTTP 和 HTTPS 爲什麼說簡單呢？因爲就是基礎的 HTTP 的協議的講解以及 HTTPS 的安全性等，這就有讀者說，爲什麼不說點進階的內容呢。

停止等待協議

我們在瞭解滑動窗口協議之前，我們要先來了解一下什麼是停止等待協議，停止等待協議又是怎麼工作的呢？

停止等待協議（stop-and-wait）是最簡單但也是最基礎的數據鏈路層協議。很多有關協議的基本概念都可以從這個協議中學習到。

停止等待就是每發送完一個分組就停止發送，等待對方的確認。在收到確認後再發送下一個分組。

簡而言之就是，發送方發送數據包後，如果沒有對方確認，那就一直等待，不再發送下一個數據包，而接受到確認之後，再繼續發送數據包。

這也就導致了停止等待協議的缺點尤爲的明顯，

這效率的低下都難以想象了，比如如果我們的帶寬是 100M 而這個停止等待協議每次都只發送一個數據包，這平白的浪費了帶寬，別說現在有很多都是千兆以上的帶寬了。

因爲這個效率問題，導致了停止等待協議並不是很適用，所以就有了其他的協議出現，也就是我們接下來所要說的滑動窗口協議。

那麼什麼是滑動窗口協議呢？

滑動窗口協議（Sliding Window Protocol），屬於 TCP 協議的一種應用，用於網絡數據傳輸時的流量控制，以避免擁塞的發生。該協議允許發送方在停止並等待確認前發送多個數據分組。由於發送方不必每發一個分組就停下來等待確認。因此該協議可以加速數據的傳輸，提高網絡吞吐量。

在滑動協議中，發送方要維持一個發送窗口，隨着數據的傳輸，這個窗口就需要不斷的向前滑動，這也就與停止等待協議出現了不同，不同在那裏呢？

區別就是他允許發送方在停止並且等待確認前，可以發送多個數據包，而不再像停止等待協議一樣，每次發送就只是發送一個數據包了。這樣的話，發送方也就不需要每發一個數據包就需要停下等待了。這就是他們之間最本質的卻區別了。

這個時候就有讀者疑問了，這時候到底會發送多少數據包呢？

這個數據包的多少，那就得取決一個參數了，而這個參數則被我們稱之爲窗口大小。

我們簡單模擬一下這個滑動窗口協議下，數據不丟包的情況。

上圖中，窗口大小爲 4，我們的發送方有 10 個數據包要發送，也就是意味着，我們一次可以發送四個數據包，

當發送發在發送第一個數據包的時候，這和個時候滑動窗口就已經開始運行了嗎？確實是的，在我們發送第一個數據包的時候，滑動窗口就開始運行了，也就是說我們在接受到確認之前，可以發送窗口大小爲 4 的量的數據包。

在 3 號數據包發送完成之後，0-3 號的對應的確認消息也反饋給了發送方。

同時窗口開始陸續的向左邊滑動，

我們也可以從圖中看出，區分了已發送，正在發送和等待發送的部分。

而滑動窗口協議的原理則可以看如下：

滑動窗口協議的主要原理是通過使用序列號來標識每個數據包，並使用確認號來確認接收到的數據包。發送方維護一個發送窗口，其中包含已發送但未收到確認的數據包。接收方維護一個接收窗口，其中包含已接收但未按順序交付的數據包。

發送方在發送數據包時，將數據包的序列號添加到數據包中，並將其發送給接收方。接收方在接收到數據包後，將確認號添加到確認包中，並將其發送給發送方。發送方在收到確認包後，將發送窗口向前滑動，將已確認的數據包從發送窗口中移除，並繼續發送下一個數據包。

如果發送方在一定時間內沒有收到確認包，或者接收方在一定時間內沒有收到正確的數據包，滑動窗口協議會觸發超時重傳機制，重新發送未確認或未正確接收的數據包。

滑動窗口協議可以提高數據傳輸的效率和可靠性，同時充分利用網絡帶寬。它被廣泛應用於各種網絡通信中，如 TCP 協議就是基於滑動窗口協議實現的。

滑動窗口協議需要注意的點

（1）發送方不必發送一個全窗口大小的數據。（2）來自接收方的一個報文段確認數據並把窗口向左邊滑動，這是因爲窗口的大小是相對於確認序號的。（3）窗口的大小可以減小，但是窗口的左邊沿卻不能夠向右移動。（4）接收方在發送一個 ACK 前不必等待窗口被填滿。

這個向右和向左，取決你理解圖時的窗口移動方向，我習慣了從從右往左，你也可以理解爲從左往右，理解都是一樣的。

所以，你瞭解滑動窗口協議了麼？

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/6k__XH2bnyReKMa-QsXP_g