一篇帶你讀懂TCP之「滑動窗口」協議

前言

你如今的努力，是爲了之後有更多的選擇。

在上一篇文章經過「表白」方式，讓咱們快速瞭解網絡七層協議 瞭解了網絡七層協議。 接下來咱們要把重心放在網絡傳輸的可靠性上面。一塊兒來看TCP協議，它是如何解決網絡傳輸不可靠的問題。這其中有個很關鍵的部分，就是咱們的滑動窗口協議。

從工程學角度上，咱們來看一看滑動窗口協議，它到底解決了一個怎樣的問題？

滑動窗口協議：

• TCP協議的使用
• 維持發送方/接收方緩衝區 緩衝區是 用來解決網絡之間數據不可靠的問題，例如丟包，重複包，出錯，亂序

在TCP協議中，發送方和接受方經過各自維護本身的緩衝區。經過商定包的重傳機制等一系列操做，來解決不可靠的問題。

問題一：如何保證次序？

提出問題：在咱們滑動窗口協議以前，咱們如何來保證發送方與接收方之間，每一個包都能被收到。而且是按次序的呢？

發送方發送一個包1，這時候接收方確認包1。發送包2，確認包2。就這樣一直下去，知道把數據徹底發送完畢，這樣就結束了。那麼就解決了丟包，出錯，亂序等一些狀況！同時也存在一些問題。問題：吞吐量很是的低。咱們發完包1，必定要等確認包1.咱們才能發送第二個包。

問題二：如何提升吞吐量？

提出問題：那麼咱們就不能先連發幾個包等他一塊兒確認嗎？這樣的話，咱們的速度會不會更快，吞吐量更高些呢？

如圖，這個就是咱們把兩個包一塊兒發送，而後一塊兒確認。能夠看出咱們改進的方案比以前的好不少，所花的時間只是一個來回的時間。接下來，咱們還有一個問題：改善了吞吐量的問題

問題三：如何實現最優解？

問題：咱們每次須要發多少個包過去呢？發送多少包是最優解呢？

咱們能不能把第一個和第二個包發過去後，收到第一個確認包就把第三個包發過去呢？而不是去等到第二個包的確認包纔去發第三個包。這樣就很天然的產生了咱們"滑動窗口"的實現。

在圖中，咱們可看出灰色1號2號3號包已經發送完畢，而且已經收到Ack。這些包就已是過去式。四、五、六、7號包是黃色的，表示已經發送了。可是並無收到對方的Ack，因此也不知道接收方有沒有收到。八、九、10號包是綠色的。是咱們尚未發送的。這些綠色也就是咱們接下來立刻要發送的包。 能夠看出咱們的窗口正好是11格。後面的11-16尚未被讀進內存。要等4號-10號包有接下來的動做後，咱們的包纔會繼續往下發送。

正常狀況

能夠看到4號包對方已經被接收到，因此被塗成了灰色。「窗口」就往右移一格，這裏只要保證「窗口」是7格的。 咱們就把11號包讀進了咱們的緩存。進入了「待發送」的狀態。八、9號包已經變成了黃色，表示已經發送出去了。接下來的操做就是同樣的了，確認包後，窗口日後移繼續將未發送的包讀進緩存，把「待發送「狀態的包變爲」已發送「。

丟包狀況

有可能咱們包發過去，對方的Ack丟了。也有可能咱們的包並無發送過去。從發送方角度看就是咱們沒有收到Ack。

發生的狀況：一直在等Ack。若是一直等不到的話，咱們也會把讀進緩存的待發送的包也一塊兒發過去。可是，這個時候咱們的窗口已經發滿了。因此並不能把12號包讀進來，而是始終在等待5號包的Ack。

若是咱們這個Ack始終不來怎麼辦呢？

超時重發

這時候咱們有個解決方法：超時重傳 這裏有一點要說明：這個Ack是要按順序的。必需要等到5的Ack收到，纔會把6-11的Ack發送過去。這樣就保證了滑動窗口的一個順序。

這時候能夠看出5號包已經接受到Ack，後面的六、七、8號包也已經發送過去已Ack。窗口便繼續向後移動。

文末

從咱們爲了增長網絡的吞吐量，想講數據包一塊兒發送過去，這時候便產生了「滑動窗口」這種協議。有了「滑動窗口」這個概念，咱們又解決了其中出現的一些問題。例如丟包，咱們又經過重發的機制去解決了。以上來自ccmouse老師教學視頻，做爲學習記錄整理。

若是文章對你有用的話，歡迎關注公衆號：Coder編程 獲取最新原創技術文章和相關免費學習資料，隨時隨地學習技術知識！