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