TCP窗口

作者：林沛满
出处：Wireshark网络分析就是这么简单

1.每个TCP的包都含有“window size” (也就是win=)的信息。这个值表示发送窗口的大小吗？

这个不是发送窗口，
而是在向对方表明自己的接收窗口。
另，加入接收方处理数据的速度跟不上接收数据的速度，缓存就会被占满，从而导致接收窗口为0。

2.我如何在包里看出发送窗口的大小呢？

很遗憾，没有简单的办法。因为，当发送窗口是由接收窗口决定的时候，我们还可以通过“window size:”的值来判断。而当它由网络因素决定的时候，事情就会变得非常复杂。

3.发送窗口和MSS有什么关系？

发送窗口决定了一口气能发多少字节，而MSS决定了这些字节要分多少个包发完。举个例子，在发送窗口为16000字节的情况下，如果MSS为1000字节，那就需要发送16000/1000=16个包；

4.发送方在一个窗口里发出n个包，是不是就能收到n个确认包？

不一定，确认包一般会少一些。由于TCP可以累积起来确认，所以当收到多个包的时候，只需要确认最后一个就可以了。

5.经常听人说“TCP Window Scale”这个概念，他究竟和接收窗口有什么关系呢？

在TCP刚被发明的时候，全世界的网络贷款都很小，所以最大接收窗口被定义为65535字节。随着硬件的革命性进步，65535字节已经成为性能瓶颈了。怎么样才能扩展呢？TCP头中只给接受窗口溜了16bit，肯定无法突破65535字节的。
1992年的RFC1323中提出一个解决方案，就是在三次我我握手中，增加Window Scale信息放到TCP头之外的Options中（也就不需要修改TCP头的设计）。Window Scale的作用是向对方声明一个Shift count ，我们把它作为2的指数，再乘以TCP头中定义的接收窗口，就得到真正的TCP接收窗口了。如果IP A告诉IP B说它的Shift count是5。2^5等于32，这就意味着以后的（此次三次握手之后）IP A声明的接收窗口要乘以32才是真正的接收窗口值。

要注意Wireshark是根据Shift count计算出这个Win的数值，如果Wireshark抓包是没有抓到三次握手，Wireshark就不知道怎么计算了，所以有时候我们会看到莫名的一些很小的接收窗口值。还有些时候是防火墙识别不了Window Scale，因此对方无法获得Shift count，最终导致严重的性能问题。