昨天我們簡單說了這個(gè) HTTP 和 HTTPS 為什么說簡單呢？因?yàn)榫褪腔A(chǔ)的 HTTP 的協(xié)議的講解以及 HTTPS 的安全性等，這就有讀者說，為什么不說點(diǎn)進(jìn)階的內(nèi)容呢。

停止等待協(xié)議

我們?cè)诹私饣瑒?dòng)窗口協(xié)議之前，我們要先來了解一下什么是停止等待協(xié)議，停止等待協(xié)議又是怎么工作的呢？

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

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

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

圖片

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

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

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

因?yàn)檫@個(gè)效率問題，導(dǎo)致了停止等待協(xié)議并不是很適用，所以就有了其他的協(xié)議出現(xiàn)，也就是我們接下來所要說的滑動(dòng)窗口協(xié)議。

滑動(dòng)窗口協(xié)議

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

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

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

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

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

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

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

圖片

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

圖片

當(dāng)發(fā)送發(fā)在發(fā)送第一個(gè)數(shù)據(jù)包的時(shí)候，這和個(gè)時(shí)候滑動(dòng)窗口就已經(jīng)開始運(yùn)行了嗎？確實(shí)是的，在我們發(fā)送第一個(gè)數(shù)據(jù)包的時(shí)候，滑動(dòng)窗口就開始運(yùn)行了，也就是說我們?cè)诮邮艿酱_認(rèn)之前，可以發(fā)送窗口大小為4的量的數(shù)據(jù)包。

在3號(hào)數(shù)據(jù)包發(fā)送完成之后，0-3號(hào)的對(duì)應(yīng)的確認(rèn)消息也反饋給了發(fā)送方。

同時(shí)窗口開始陸續(xù)的向左邊滑動(dòng)，

圖片

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

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

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

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

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

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

滑動(dòng)窗口協(xié)議需要注意的點(diǎn)

（1）發(fā)送方不必發(fā)送一個(gè)全窗口大小的數(shù)據(jù)。（2）來自接收方的一個(gè)報(bào)文段確認(rèn)數(shù)據(jù)并把窗口向左邊滑動(dòng)，這是因?yàn)榇翱诘拇笮∈窍鄬?duì)于確認(rèn)序號(hào)的。（3）窗口的大小可以減小，但是窗口的左邊沿卻不能夠向右移動(dòng)。（4）接收方在發(fā)送一個(gè)ACK前不必等待窗口被填滿。

這個(gè)向右和向左，取決你理解圖時(shí)的窗口移動(dòng)方向，我習(xí)慣了從從右往左，你也可以理解為從左往右，理解都是一樣的。

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