从这一节开始，我们学习通信双方应用进程建立TCP连接之后，数据传输过程中，TCP有哪些机制保证传输可靠性的。本节先学习第一种机制：流量控制。

窗口与流量控制

首先，我们要知道的是：什么是流量控制？使用流量控制是为了解决什么问题？

在这之前，我们学习过“接收窗口”的概念，其实也就是接收缓存的大小，能够容纳多少字节的数据，这个数值是有限的。所以接收窗口在容纳了足够的数据量之后，就没有缓存再接收对方发来的数据了。如果这时对方还在不断地发来数据，那么这些数据到达接收方之后，接收方由于没有空余的空间来容纳，来不及接收，就只能把它们丢弃掉。

所以，必须要有一种机制能够解决这种问题，这就是流量控制。流量控制就是为了能够控制发送方的发送速率，使其不要太快，要能够让接收方来得及处理。

可以用比较经典的原理图来说明流量控制，如下图：

在这个图中，为了方便叙述原理，假设发送方只简单的发送数据，接收方只简单的接收数据，并设置接收方的接收窗口大小为400个字节。

一开始，发送方发送了两个大小为100字节数据的报文段，接收方收到后进行确认回复：ack=201，rwnd=200。意思是，截止到序号为200的报文，我已经都收到了，我期望你下一个发来的报文的序号是201，现在我的接收窗口大小是200字节，你最多再给我发200字节的数据。

发送方知道这个情况之后，接着发送了200个字节的数据。这时候接收方给出接收窗口大小为0的确认报文，告诉发送方：我目前已经没有接收缓存了，暂时先不要发送数据了。

接收方通过在确认报文中给出自己当前接收窗口的大小，使发送方知道应该向对方发送多少数据量，就是TCP流量控制的方法。

“零窗口”死锁现象

了解了上面流量控制的过程之后，可能会想一个问题：接收方最后发送窗口值大小为零的确认报文之后，发送方就会暂停发送数据，等待接收方告诉缓存有空间了再继续发送。可是如果接收方将“缓存有空间”的消息告诉发送方的时候，这个消息不巧在传输过程中丢失了，那么发送方会不会一直等下去呢？

这个现象就叫做“零窗口”死锁现象，由于发送方没收到“接收方缓存有空间”的消息，所以发送方一直以为接收方当前接收缓存没有空间。所以双方就会产生这样一种“死锁”的局面。

为了解决这种死锁问题，所以每一个TCP连接都会设置有一个“坚持定时器”。这个定时器的作用是：从收到对方发来“窗口大小为零”的报文开始，启动定时器，等到定时器到期如果还没有收到对方发来“接收缓存有空间”的消息，那么就主动向对方发送一个“零窗口探测”报文，这个探测报文只带有一个字节的数据，目的就是为了探测一下对方窗口大小有没有改变。

对方收到这个探测报文后，给出确认报文，其中包含了当前窗口值，如果当前窗口值已经不是零了，这个死锁的局面就打破了，发送方可以继续发送数据；但如果当前窗口值仍然为零，那么发送方将再次启动“坚持定时器”，时间到就再次发送探测报文。

学到这里，又出现一个问题：既然接收方的窗口值都为零了，也就意味着接收方不能再接收数据了，那么为什么发送方的“零窗口探测”报文能被接受呢？

这其实是TCP的一个规定：当接收窗口大小为零时，也必须接收“零窗口探测”报文。还有一个前面学过的，首部中URG位被设置为1的紧急报文，也是即使窗口值为零时必须被接收。