如果我們把一次網絡應用分成兩個階段，建立連接，數據傳輸。那接下來要說的windows都是爲了數據傳輸的。
如果我們把網絡應用分成兩種，要求交互性的（telnet，rlogin），要求傳輸大量數據的（FTP）。那接下來會對於這兩種分別介紹，但是會側重的說大量數據傳輸的那種。
在說Window之前，我們先說說buffer。
記得我們在用netperf建立TCP連接的時候通常會指定sender和receiver兩端的buffer。一般的實驗中的結論，當兩端buffer相當，通常buffersize越大，throughput會越大。一個原因是Buffer的大小也決定了Window size， 而window是用來control flow的。
下面我們會涉及到Advertised window， sliding window，congestion window。
————For interactive data transfer, 情況很簡單，在我的涉獵中，它只涉及到“Advertised Window”。Advertised window 由receiver提供size，通知接收端目前Receiver端的接收buffer還有多大的free space，sender可以發送不超過這個size的packet。這個size大概就是接收端的buffer 減去沒有被APP layer讀走的數據大小。
————For bulk data transfer, 情況稍微複雜。因爲數據量較大，且不是交互的信息，所以我們有expectation，在bulk data transfer中，allow sender to transmit multiple packets before it stops and waits for an ACK. 這就產生了sliding Window。Sliding window可以想象是一個框框，左邊是收到ACK的segmentID，右邊是左邊+Advertised window的size，中間有個槓槓，代表前面的數據已經發出但是沒有收到ACK。那這個中間的槓槓和右邊的邊框之間的size（usable window）便是發送端可以發送的packet大小。如此，發送端可以一下子發出多個packet，然後等待usable window大於0（或者某個大於零的值爲了better performance，這就是另一個故事了，這裏不說啦），然後再send packet。
大家可以看到，sliding window還是用的Advertised window作爲一個參考的。那就是說他只是考慮到接收端的能力。可是網絡上的中間節點也很多，比如鏈路上有些弱者造成網絡傳輸的瓶頸，勢必會出現問題，網絡出現大量丟包，因而性能降低。所以這裏又出現了congestion window的概念。
Congestion window， 從size 1開始，每收到一個ACK，增大一個segment的大小。這也就是slow start。在實際情況下，congestion window是和Advertised window一起工作，選其中比較小的那個值做sliding window的offer window size。就是我們之前提到的，右邊框和左邊框之間的size。這樣就可以既考慮到接收方的能力，又考慮到鏈路上可能存在的弱弱的其他硬件比如路由器啊之類的能力了。
我之前剛看到這裏就有個疑問，那我的packets不斷地傳，sender不斷接受到ACK，那congestion window豈不是要變得好大好大？答案是不是這樣的。爲什麼呢？因爲congestion window normally implemented with Congestion Avoidance. 當它不斷變大，超過網絡上能處理的能力的時候就會出現congestion，這個congestion可能是重複收到ACK，或者timeout。這時候congestion avoidance就要起作用了，將congestion window變小（一半或者別的，不同算法不一樣）並記錄到ssthresh中。You could see,當有新的ACK收到時，sender或者是在做slow start，或者是在做congestion avoidance（減小congestion window，或者等於ssthresh，或者ssthresh+**），取決於當前的congestion window和ssthresh的大小關係。