从这一节开始，我们学习通信双方应用进程建立TCP连接之后，数据传输过程中，TCP有哪些机制保证传输可靠性的。本节先学习第一种机制：流量控制。
窗口与流量控制
首先，我们要知道的是：什么是流量控制？使用流量控制是为了解决什么问题？
在这之前，我们学习过"接收窗口"的概念，其实也就是接收缓存的大小，能够容纳多少字节的数据，这个数值是有限的。所以接收窗口在容纳了足够的数据量之后，就没有缓存再接收对方发来的数据了。如果这时对方还在不断地发来数据，那么这些数据到达接收方之后，接收方由于没有空余的空间来容纳，来不及接收，就只能把它们丢弃掉。
所以，必须要有一种机制能够解决这种问题，这就是流量控制。流量控制就是为了能够控制发送方的发送速率，使其不要太快，要能够让接收方来得及处理。
可以用比较经典的原理图来说明流量控制，如下图：
在这个图中，为了方便叙述原理，假设发送方只简单的发送数据，接收方只简单的接收数据，并设置接收方的接收窗口大小为400个字节。
一开始，发送方发送了两个大小为100字节数据的报文段，接收方收到后进行确认回复：ack=201，rwnd=200。意思是，截止到序号为200的报文，我已经都收到了，我期望你下一个发来的报文的序号是201，现在我的接收窗口大小是200字节，你最多再给我发200字节的数据。
发送方知道这个情况之后，接着发送了200个字节的数据。这时候接收方给出接收窗口大小为0的确认报文，告诉发送方：我目前已经没有接收缓存了，暂时先不要发送数据了。
接收方通过在确认报文中给出自己当前接收窗口的大小，使发送方知道应该向对方发送多少数据量，就是TCP流量控制的方法。
"零窗口"死锁现象
了解了上面流量控制的过程之后，可能会想一个问题：接收方最后发送窗口值大小为零的确认报文之后，发送方就会暂停发送数据，等待接收方告诉缓存有空间了再继续发送。可是如果接收方将"缓存有空间"的消息告诉发送方的时候，这个消息不巧在传输过程中丢失了，那么发送方会不会一直等下去呢？
这个现象就叫做"零窗口"死锁现象，由于发送方没收到"接收方缓存有空间"的消息，所以发送方一直以为接收方当前接收缓存没有空间。所以双方就会产生这样一种"死锁"的局面。
为了解决这种死锁问题，所以每一个TCP连接都会设置有一个"坚持定时器"。这个定时器的作用是：从收到对方发来"窗口大小为零"的报文开始，启动定时器，等到定时器到期如果还没有收到对方发来"接收缓存有空间"的消息，那么就主动向对方发送一个"零窗口探测"报文，这个探测报文只带有一个字节的数据，目的就是为了探测一下对方窗口大小有没有改变。
对方收到这个探测报文后，给出确认报文，其中包含了当前窗口值，如果当前窗口值已经不是零了，这个死锁的局面就打破了，发送方可以继续发送数据；但如果当前窗口值仍然为零，那么发送方将再次启动"坚持定时器"，时间到就再次发送探测报文。
学到这里，又出现一个问题：既然接收方的窗口值都为零了，也就意味着接收方不能再接收数据了，那么为什么发送方的"零窗口探测"报文能被接受呢？
这其实是TCP的一个规定：当接收窗口大小为零时，也必须接收"零窗口探测"报文。还有一个前面学过的，首部中URG位被设置为1的紧急报文，也是即使窗口值为零时必须被接收。
糊涂窗口综合症
糊涂窗口综合症主要反映的是：接收方应用进程和接收缓存交互数据的时候效率低下，从而导致TCP传输效率低下的问题。
比如这样一个情景：接收方的窗口值为零，意味着当前接收缓存已满，但是上层的应用进程一次只读取一个字节的数据，这样缓存中就有了一个字节的空间，这时接收方给发送方发出确认，表明自己的接收窗口值是1，你可以发来1个字节的数据。
这样的话，可以想一下，发送方要把这一个字节的数据加上至少20字节的TCP首部，再加上至少20字节的IP首部，层层封装，就会造成传输首部信息的开销大，而实际的有用数据才只有一个字节。如此反复，一次只有一个字节的有效数据在传输，就导致TCP传输效率的低下，这就是糊涂窗口综合症的现象。
要解决这种问题，可以在接收方和发送方分别设置一些机制，双方配合起来，使得接收方不要有了一点空间就立即发送确认报文，同时发送方也不要每次只发送一个很小的报文段。
可以在接收方设置：等到缓存中有了能够容纳一个最大长度报文段的空间时，或者缓存空间有一半是空余的，就可以给发送方发去确认，通告自己的接收窗口大小。
也可以在发送方使用Nagle算法：当数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。
两种方法配合起来使用，可以有效避免糊涂窗口综合症的现象发生。
本节内容我们学习了TCP规定在数据传输过程中的流量控制的方法原理，另外还介绍了"零窗口"死锁和糊涂窗口综合症两个可能会发生的问题和相应的解决办法。下一节，我们学习TCP的可靠传输。
参考教材：杨英鹏《计算机网络原理与实践》