TCPのwindows:Advertised window,Sliding window,Congestion window

如果我们把一次网络应用分成两个阶段，建立连接，数据传输。那接下来要说的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的大小关系。

对原博有删改：http://blog.sina.com.cn/s/blog_702b398b0101bqgu.html