TCP滑动窗口

TCP的滑动窗口解决了端到端的流量控制问题，允许接受方对传输进行限制，直到它拥有足够的缓冲空间来容纳更多的数据。滑动窗口的大小由接收方确定，接收方在发送确认信号给发送方的同时告诉发送方自己的缓冲区大小（在TCP头部字段中），发送方根据此大小确定窗口大小，从而控制数据发送量。同时，滑动窗口协议允许发送方在停止并等待确认前可以连续发送多个分组，由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。

下面是一个例子：

在建立连接时，双方都告知了对方自己的MSS为1024，所以在传输过程中，每一个报文段的大小都为1024.下面重点分析各个确认报文段，也就是从右边发往左边的报文段：

• 报文段7确认了报文段4和报文段5。由于包含两个分组的ACK，所以该报文段不是经受时延的确认。滑动窗口大小为4096表示收到的两个报文段已经全部交付给了应用层，此时TCP的接收缓存为空。
• 报文段8确认了报文段6。此报文段在等待其它数据（这里为报文段9的确认）一起传送的过程中延时定时器溢出，所以此为经受时延的确认。滑动窗口大小为3072表示TCP接受缓存中还有1024字节数据未被应用程序读取。
• 报文段10确认了报文段9，它也是一个经受时延的确认。
• 报文段14确认了报文段11和报文段12，它不是一个经受时延的确认。
• 报文段16确认了报文段13和报文段15，它不是一个经受时延的确认。

通过上面的过程可以看出，报文段7、14、16的ACK确认了两个收到的报文段。这与开头的描述是一致的。

下面来看看上述过程中的滑动窗口变化情况：

接收方每确认一个报文段，滑动窗口的左边沿就向右边沿靠拢。 这里的确认是指接收方发送确认报文段，并不代表应用层已经读取了TCP接收缓存。当应用进程读取了已经确认的数据并释放TCP接受缓存后，滑动窗口的右边沿才会向右移动。

参考：

《TCP/IP详解》 P209-P214.