TCP的滑动窗口机制
如果每次传输数据都只能发送一个MSS，就需要等待接收方的ACK，这显然会极大的影响传输的速率。在发送数据的时候，最好的方式是一下将所有的数据全部发送出去，然后一起确认。
但是现实中确实会存在一些限制：
- 接收方的缓存（接收窗口）可能已经满了，无法接收数据。
- 网络的带宽也不一定足够大，一口发太多会导致丢包事故。
发送方要知道接收方的接收窗口和网络这两个限制因素中哪一个更严格，然后在其限制范围内尽可能多发包。这个一口气能发送的数据量就是传说中的TCP发送窗口。
首先TCP在进行数据传输的时候都是先将数据放在数据缓冲区中的，TCP维护了两个缓冲区，发送方缓冲区和接收方缓冲区。
- 发送方缓冲区：发送方缓冲区用于存储已经准备就绪数据和发送了但是没有被确认的数据。
- 接收方缓冲区：接收方缓冲区用于存储已经被接收但是还没有被用户进程消费的数据。
滑动窗口机制是TCP的一种流量控制方法，该机制允许发送方在停止并等待确认前连续发送多个分组，而不必每发送一个分组就停下来等待确认，从而增加数据传输的速率提高应用的吞吐量。
TCP的包可以分为四种状态
- 已发送并且已经确认的包。
- 已发送但是没有确认的包。
- 未发送但是可以发送的包。
- 不允许被发送的包。
滑动窗口协议的基本工作流程就是由接收方通告窗口的大小，这个窗口称为提出窗口，也就是接收方窗口。接收方提出的窗口则是被接收缓冲区所影响的，如果数据没有被用户进程使用那么接收方通告的窗口就会相应得到减小，发送窗口取决于接收方窗口的大小。可用窗口的大小等于接收方窗口减去发送但是没有被确认的数据包大小。
滑动窗口机制示意流量图
滑动窗口的动态性
零窗口（TCP Zero Window）
在接收方窗口大小变为0的时候，发送方就不能再发送数据了。但是当接收方窗口恢复的时候发送方要怎么知道那？在这个时候TCP会启动一个零窗口（TCP Zero Window）定时探测器，向接收方询问窗口大小，当接收方窗口恢复的时候，就可以再次发送数据。