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

停止等待協(xié)議

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

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

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

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

圖片

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

• 一次只能發(fā)送一個數(shù)據(jù)包效率低下。

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

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

滑動窗口協(xié)議

那么什么是滑動窗口協(xié)議呢？

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

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

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

這個時候就有讀者疑問了，這時候到底會發(fā)送多少數(shù)據(jù)包呢？

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

我們簡單模擬一下這個滑動窗口協(xié)議下，數(shù)據(jù)不丟包的情況。

圖片

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

圖片

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

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

同時窗口開始陸續(xù)的向左邊滑動，

圖片

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

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

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

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

如果發(fā)送方在一定時間內(nèi)沒有收到確認包，或者接收方在一定時間內(nèi)沒有收到正確的數(shù)據(jù)包，滑動窗口協(xié)議會觸發(fā)超時重傳機制，重新發(fā)送未確認或未正確接收的數(shù)據(jù)包。

滑動窗口協(xié)議可以提高數(shù)據(jù)傳輸?shù)男屎涂煽啃裕瑫r充分利用網(wǎng)絡帶寬。它被廣泛應用于各種網(wǎng)絡通信中，如TCP協(xié)議就是基于滑動窗口協(xié)議實現(xiàn)的。

滑動窗口協(xié)議需要注意的點

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

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

所以，你了解滑動窗口協(xié)議了么？