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

所以就需要引入一種流量控制的手段：讓發(fā)送方不要發(fā)送太快，既讓接收方能夠順利接收數(shù)據(jù)，而且也不會(huì)造成網(wǎng)絡(luò)鏈路的阻塞。

思路

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

滑動(dòng)窗口

滑動(dòng)窗口類似一個(gè)窗口，是用來告訴發(fā)送方可以發(fā)送數(shù)據(jù)的大小。也可以說是窗口標(biāo)記了接收方緩沖區(qū)的大小。窗口大小也就表示一次能發(fā)送多少數(shù)據(jù)量，而且這個(gè)窗口可以滑動(dòng)，滑動(dòng)窗口因此得名。

怎樣告知發(fā)送方窗口大小？

怎樣通知發(fā)送方窗口大小呢？難道要重新發(fā)送一包數(shù)據(jù)告訴對(duì)方嗎，這顯然是不合理的。可以巧妙的使用確認(rèn)應(yīng)答包。有了確認(rèn)應(yīng)答包還是不夠，如果是第一次交互呢？所以還需要在三次握手時(shí)候，就需要告知對(duì)方。（rwnd表示接收窗口）

在原來的確認(rèn)應(yīng)答策略中，每一次發(fā)送數(shù)據(jù)，都需要Ack應(yīng)答，在接收到Ack之后才會(huì)發(fā)送下一個(gè)數(shù)據(jù)段，發(fā)送方?jīng)]有接收到Ack應(yīng)答呢？這樣做的方式效率實(shí)在太低。使用了滑動(dòng)窗口，可以多次發(fā)送數(shù)據(jù)，只要不要超過對(duì)方窗口大小。這樣就大大提高了效率。

滑動(dòng)窗口細(xì)節(jié)

接收方將自己能夠接收的緩沖區(qū)大小是在TCP首部中的“窗口大小”字段表示的，通過Ack通知發(fā)送方。
窗口大小是發(fā)送方可以發(fā)送的最大值，也就是說可以不需要Ack應(yīng)答，可以發(fā)送多次數(shù)據(jù)，前提發(fā)送總數(shù)據(jù)量不要超過窗口大小。
窗口大小大說明網(wǎng)絡(luò)的吞吐率高
操作系統(tǒng)內(nèi)核維護(hù)了一塊接收緩沖區(qū)，只有Ack應(yīng)答之后的數(shù)據(jù)才能從緩沖區(qū)中刪除。
接收方一旦發(fā)現(xiàn)自己的緩沖區(qū)快滿了，就會(huì)通知對(duì)方自己的窗口為更小的值。
如果接收方發(fā)現(xiàn)自己的緩沖區(qū)滿了，就會(huì)將窗口的大小設(shè)置為0，此時(shí)發(fā)送方將不再發(fā)送數(shù)據(jù)，但是需要定期發(fā)送一個(gè)窗口探測(cè)數(shù)據(jù)段，使接收方把窗口大小告訴發(fā)送方。（針對(duì)這一點(diǎn)重點(diǎn)說明下為什么需要定期發(fā)送窗口探針？可以想象下，如果接收方緩沖區(qū)滿了，然后通過Ack告知發(fā)送方窗口大小為0。發(fā)送方從此不會(huì)發(fā)送數(shù)據(jù)給接收方，接收方也沒辦法告知對(duì)方自己緩沖區(qū)可以接收數(shù)據(jù)，就會(huì)出現(xiàn)“卡死”的情況）