我們都知道TCP是一種可靠的，面向連接的傳輸層協議。我們總是希望TCP能夠傳輸的數據越快越好。如果存在這樣一種情況，發送方數據發送的非常快，而且接收方耗盡自己的資源也根本來不及接收，那這些多余的數據就會被丟棄，這就違背了TCP可靠的宗旨了。

[[269367]]

所以就需要引入一種流量控制的手段：讓發送方不要發送太快，既讓接收方能夠順利接收數據，而且也不會造成網絡鏈路的阻塞。

思路

沿著這個思路：讓發送方不要發送的太快。那就讓接收方控制發送方的數據大小，每次應答的時候通知發送方自己還剩多少空間可以接收數據。當然實際交互沒有這么的簡單，只是提供了一種思路。利用這種思路，誕生了滑動窗口的方式。

滑動窗口

滑動窗口類似一個窗口，是用來告訴發送方可以發送數據的大小。也可以說是窗口標記了接收方緩沖區的大小。窗口大小也就表示一次能發送多少數據量，而且這個窗口可以滑動，滑動窗口因此得名。

怎樣告知發送方窗口大小?

怎樣通知發送方窗口大小呢?難道要重新發送一包數據告訴對方嗎，這顯然是不合理的。可以巧妙的使用確認應答包。有了確認應答包還是不夠，如果是***次交互呢?所以還需要在三次握手時候，就需要告知對方。(rwnd表示接收窗口)

在原來的確認應答策略中，每一次發送數據，都需要Ack應答，在接收到Ack之后才會發送下一個數據段，發送方沒有接收到Ack應答呢?這樣做的方式效率實在太低。使用了滑動窗口，可以多次發送數據，只要不要超過對方窗口大小。這樣就大大提高了效率。

滑動窗口細節

1. 接收方將自己能夠接收的緩沖區大小是在TCP首部中的“窗口大小”字段表示的，通過Ack通知發送方。
2. 窗口大小是發送方可以發送的***值，也就是說可以不需要Ack應答，可以發送多次數據，前提發送總數據量不要超過窗口大小。
3. 窗口大小大說明網絡的吞吐率高
4. 操作系統內核維護了一塊接收緩沖區，只有Ack應答之后的數據才能從緩沖區中刪除。
5. 接收方一旦發現自己的緩沖區快滿了，就會通知對方自己的窗口為更小的值。
6. 如果接收方發現自己的緩沖區滿了，就會將窗口的大小設置為0，此時發送方將不再發送數據，但是需要定期發送一個窗口探測數據段，使接收方把窗口大小告訴發送方 。(針對這一點重點說明下為什么需要定期發送窗口探針?可以想象下，如果接收方緩沖區滿了，然后通過Ack告知發送方窗口大小為0。發送方從此不會發送數據給接收方，接收方也沒辦法告知對方自己緩沖區可以接收數據，就會出現“卡死”的情況)

實例

A 向 B 發送數據。在連接建立時，B 告訴 A：“我的接收窗口 rwnd = 400(字節)。注意：圖中的箭頭上面大寫的ACK表示首部中的確認位ACK，小寫ack表示確認字段的值。

上面的過程是這樣的：

1. A發送了數據序號1至100，還能發送300字節
2. A發送了數據序號101至200，還能發送200字節
3. A發送了數據序號201至300，但是丟失了數據
4. B發送了ACK，同時通知A，允許A發送序號201至500,300字節
5. A發送了數據序號301至400，還能發送100字節
6. A發送了數據序號401至500，不能發送數據了
7. A超時重傳舊的數據，但不能發送新數據
8. B發送了ACK，同時通知A，允許A發送序號501至600,100字節
9. A發送了數據序號501至600，不能發送數據了
10. B發送了ACK，同時通知A，不允許A發送數據