大家都知道TCP和UDP的区别是，TCP是基于连接的(三次握手)，而且TCP数据的传输是可靠的，所谓可靠是依托序列号及确认号机制让TCP的传输过程中即使出现丢包也会重传。

但是TCP的确认机制也让TCP连接双方的数据传输速度变慢，也就是说，一方发送数据需要等待对方的确认才继续发送后续数据。这就体现的窗口机制的作用，所谓窗口，也就是充分利用双方的带宽及缓冲区(Buffer)。举个栗子，发送方不必等待对方的确认，可以连续发送多个数据包给对方，而对方可以暂时把这些数据存放在缓冲区，并给对方一个确认。这样，可以大大增加数据传输的速度。

这样做的问题是一旦当接收方的缓冲区填满或即将填满时，就会产生不堪重负的情况，那么这就需要TCP窗口的实时更新机制，举个栗子，接收方窗口大小设置的是50000，也就是说发送方可以不必等待确认而一次性发送50000字节的数据，一旦接收方意识到不堪重负的情况，可以发送窗口更新通知告诉发送方，现在的窗口大小是30000，请减少一次性发送数据的字节数。某些极端情况，接收方的Buffer完全填满，这时，会发送ZeroWindowSize通知，让发送方暂时停止数据传输，并等待下一个确认通知。 上图是抓包工具抓到的一个ACK包的头部信息，可以看出其windowsize的值是最大值，因为16bit的字段最大取值就是65535。红框中下面那一行可能会让大家疑惑。为什么会有一个Calculated window size呢？下面我们就来看一个TCP的选项：TCP Window Size Scaling。

既然是选项，那么毫无疑问需要体现在上图TCP报头的选项（Options）字段。

接下来我们再看一张抓包的截图： 这张图中我们可以看到，windows size的值是114，但是Calculated Windows Size的值却是14592，这是怎么回事呢？

在TCP三次握手过程中，可以通过SYN包开启TCP选项Window Size Scaling，设计出这个选项是因为如今的带宽已经大规模提升，千兆到桌面也是一件常事儿，因此，65535长度的窗口大小已经显得有些小了，为了突破这个限制，便有了Window Size Scaling选项，看下图SYN包截图： 可以看到这个字段的值为7，也就是要将Window Size的值左移七位，即乘以128，因此，上图中我们看到window size值是114，但是真正选用的值却是14592(114*128)。