概述
滑動窗口實現(xiàn)了TCP流控制。首先明確滑動窗口的范疇：TCP是雙工的協(xié)議，會話的雙方都可以同時接收和發(fā)送數(shù)據(jù)。TCP會話的雙方都各自維護一個發(fā)送窗口和一個接收窗口。各自的接收窗口大小取決于應用、系統(tǒng)、硬件的限制（TCP傳輸速率不能大于應用的數(shù)據(jù)處理速率）。各自的發(fā)送窗口則要求取決于對端通告的接收窗口，要求相同。滑動窗口解決的是流量控制的的問題，就是如果接收端和發(fā)送端對數(shù)據(jù)包的處理速度不同，如何讓雙方達成一致。接收端的緩存?zhèn)鬏敂?shù)據(jù)給應用層，但這個過程不一定是即時的，如果發(fā)送速度太快，會出現(xiàn)接收端數(shù)據(jù)overflow，流量控制解決的是這個問題。
窗口的概念
發(fā)送方的發(fā)送緩存內(nèi)的數(shù)據(jù)都可以被分為4類:1. 已發(fā)送，已收到ACK2. 已發(fā)送，未收到ACK3. 未發(fā)送，但允許發(fā)送4. 未發(fā)送，但不允許發(fā)送其中類型2和3都屬于發(fā)送窗口。接收方的緩存數(shù)據(jù)分為3類：1. 已接收2. 未接收但準備接收3. 未接收而且不準備接收其中類型2屬于接收窗口。窗口大小代表了設備一次能從對端處理多少數(shù)據(jù)，之后再傳給應用層。緩存?zhèn)鹘o應用層的數(shù)據(jù)不能是亂序的，窗口機制保證了這一點?，F(xiàn)實中，應用層可能無法立刻從緩存中讀取數(shù)據(jù)。
滑動機制
- 發(fā)送窗口只有收到發(fā)送窗口內(nèi)字節(jié)的ACK確認，才會移動發(fā)送窗口的左邊界。
- 接收窗口只有在前面所有的段都確認的情況下才會移動左邊界。當在前面還有字節(jié)未接收但收到后面字節(jié)的情況下，窗口不會移動，并不對后續(xù)字節(jié)確認。以此確保對端會對這些數(shù)據(jù)重傳。
- 遵循快速重傳、累計確認、選擇確認等規(guī)則。
- 發(fā)送方發(fā)的window size = 8192;就是接收端最多發(fā)送8192字節(jié)，這個8192一般就是發(fā)送方接收緩存的大小。
模擬動畫
模擬特點
找到了一個模擬TCP窗口發(fā)送的動畫的地址，稍微有缺陷：1. 丟包率如果設得太高，有時無論重發(fā)多少次都不能恢復正常 2. 窗口較大可為10，其實應該為9明確發(fā)送端和接收端，發(fā)送A~S數(shù)據(jù)包，我們不會從頭到尾分析，因為過程比較長。1. 簡化了窗口大小，雙方窗口大小都一直是42. 設置一定的丟包率，否則沒什么值得分析的，包括sender發(fā)送的數(shù)據(jù)包和receiver回復的ACK包。3. 簡化重傳機制，出現(xiàn)丟包則直接重傳，不等3個冗余ACK和超時。4. 既不是選擇重傳也不是退回N步，重傳的包是隨機的發(fā)
