解析TCP之滑動視窗(動畫演示)
概述
滑動視窗實現了TCP流控制。首先明確滑動視窗的範疇：TCP是雙工的協議，會話的雙方都可以同時接收和傳送資料。TCP會話的雙方都各自維護一個傳送視窗和一個接收視窗。各自的接收視窗大小取決於應用、系統、硬體的限制（TCP傳輸速率不能大於應用的資料處理速率）。各自的傳送視窗則要求取決於對端通告的接收視窗，要求相同。
滑動視窗解決的是流量控制的的問題，就是如果接收端和傳送端對資料包的處理速度不同，如何讓雙方達成一致。接收端的快取傳輸資料給應用層，但這個過程不一定是即時的，如果傳送速度太快，會出現接收端資料overflow，流量控制解決的是這個問題。
視窗的概念
傳送方的傳送快取內的資料都可以被分為4類:
1. 已傳送，已收到ACK
2. 已傳送，未收到ACK
3. 未傳送，但允許傳送
4. 未傳送，但不允許傳送
其中型別2和3都屬於傳送視窗。
接收方的快取資料分為3類：
1. 已接收
2. 未接收但準備接收
3. 未接收而且不準備接收
其中型別2屬於接收視窗。
視窗大小代表了裝置一次能從對端處理多少資料，之後再傳給應用層。快取傳給應用層的資料不能是亂序的，視窗機制保證了這一點。現實中，應用層可能無法立刻從快取中讀取資料。
滑動機制
傳送視窗只有收到傳送視窗內位元組的ACK確認，才會移動傳送視窗的左邊界。
接收視窗只有在前面所有的段都確認的情況下才會移動左邊界。當在前面還有位元組未接收但收到後面位元組的情況下，視窗不會移動，並不對後續位元組確認。以此確保對端會對這些資料重傳。
遵循快速重傳、累計確認、選擇確認等規則。
傳送方發的window size = 8192;就是接收端最多傳送8192位元組，這個8192一般就是傳送方接收快取的大小。
模擬動畫
模擬特點
找到了一個模擬TCP視窗傳送的動畫的地址，稍微有缺陷：1. 丟包率如果設得太高，有時無論重發多少次都不能恢復正常 2. 視窗最大可為10，其實應該為9
明確傳送端和接收端，傳送A~S資料包，我們不會從頭到尾分析，因為過程比較長。
1. 簡化了視窗大小，雙方視窗大小都一直是4
2. 設定一定的丟包率，否則沒什麼值得分析的，包括sender傳送的資料包和receiver回覆的ACK包。
3. 簡化重傳機制，出現丟包則直接重傳，不等3個冗餘ACK和超時。
4. 既不是選擇重傳也不是退回N步，重傳的包是隨機的
發
分析滑動視窗機制
首先發送端傳送A,B,C,D四個包，但是A,B丟失，只有C,D到達接收端。
接收端沒有收到A，所以不回覆ACK包。傳送端重傳A,B,C,D四個包，這次全都到達了。
接收端先獲得A，發ACK包A，但是中途丟失；獲得B後，根據累計確認的原則，發D的ACK包，然後視窗滑動。再次獲得C,D後，連續回覆2個D的ACK包，其中C對應的ACK包丟失。
傳送端連收2個D的ACK包，說明4個包對方都已收到，視窗滑動，發E,F,G,H包，其中G包丟失。現在整個序列的狀態：ABCD是已傳送已確認，EFGH是已傳送未確認，I~S是不能傳送。
接收端先收到E，發ACK包；收到F後發F的ACK包；未收到G，還是發F的ACK包；收到H，還是發F的ACK包。不幸的是，三個ACK包全都丟失。
傳送端收到E的ACK包，視窗向右滑動一位；然後再發送F,G,H,I，其中F丟失。
接收端獲得I，因為沒有G，只好回覆F的ACK包。相繼收到G,H包。
接收端根據累計確認，連發兩個I包，其中H對應的丟失。視窗向右滑動。
傳送端接收I的ACK包後，向右滑動四位。傳送J,K,L,M四個包，後面不再分析。
從上面的過程中，我們可以得到以下結論：
1. TCP連線是通過資料包和ACK實現的，我們作為第三者可以看到雙方發包的過程，但接受者在收到之前不知道傳送方發的是什麼，同樣的，傳送方在收到ACK前也不知道對方是否成功接收。
傳送方沒有收到接收方發回的ACK，就不能向右滑動。假設傳送方向接收方發了ABCD就滑動，只要對方沒收到A，就不能滑動，那麼就會出現二者不同步的局面。
滑動視窗提高了通道利用率，TCP是傳送報文段為單位的，假如每發一個報文就要等ACK，那麼對於大資料包，等待時間就太長了。只要傳送的報文在滑動窗口裡面，不用等每個ACK回來就可以向右滑動。本例中，開始接收端空著AB，只有CD，此時不能滑動；之後接收到EF和H，直接向右滑動2位，不必等G到位。
視窗大小不能大於序號空間大小的一半。目的是為了不讓兩個窗口出現交迭，比如總大小為7，視窗大小都為4，接收視窗應當滑動4，但只剩3個序號，導致兩個視窗交迭。
有一種情況沒出現：傳送方發ABCD，接收方都收到然後向右滑動，但回覆的ACK包全丟了。傳送方未收到任何ACK， timeout後會重發ABCD，此時的接收方按累計確認的原則，收到ABCD後只會重發D的ACK，傳送方收到後向右滑動。
對比滑動視窗和擁塞視窗
滑動視窗是控制接收以及同步資料範圍的，通知傳送端目前接收的資料範圍，用於流量控制，接收端使用。擁塞視窗是控制傳送速率的，避免發的過多，傳送端使用。因為tcp是全雙工，所以兩邊都有滑動視窗。
兩個視窗的維護是獨立的，滑動視窗主要由接收方反饋快取情況來維護，擁塞視窗主要由傳送方的擁塞控制演算法檢測出的網路擁塞程度來決定的。
擁塞視窗控制sender向connection傳輸資料的速率，使這個速率為網路擁堵狀況的函式。