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

停止等待協議

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

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

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

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

圖片

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

• 一次只能發送一個數據包效率低下。

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

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

滑動窗口協議

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

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

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

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

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

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

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

圖片

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

圖片

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

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

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

圖片

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

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

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

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

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

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

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

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

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

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