一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收MSS5131-393MLC方就可能来不及接收，这就会造成数据的丢失。所谓流量控制(flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。

   利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。

   下面通过图5-22的例子说明如何利用滑动窗口机制进行流量控制。

   设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口rwnd=400”（这里nⅣnd表示receiver window）。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP的窗口单位是字节，不是报文段。TCP连接建立时的窗口协商过程在图中没有显示出来。再设每一个报文段为100字节长，而数据报文段序号的初始值设为1（见图中第一个箭头上面的序号seq：1。图中右边的注释可帮助理解整个的过程）。请注意，图中箭头上面大写ACK表示首部中的确认位ACK，小写ack衷示确认字段的值。

   A发送了序号301至400，还能再发送100字市新数据

   A发送了序号401至500，不能冉发送新数据了

   A超时重传旧的数据，但不能发送新的数据

    允许A发送序号501至600共100字符

   A发送了序号501至600，不能再发送

   图5-22利用可变窗口进行流量控制举例

   我们应注意，接收方的主机B进行了三次流量控制。第一次把窗口减小到rwnd=300，第二次又减到rwnd：100，最后减到rwnd=0，即不允许发送方再发送数据了a这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。我们还应注意到，B向A发送的三个报文段都设置了ACK =1，只有在ACK=1时确认号字段才有意义。

   现在我们考虑一种情况。在图5-22中，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd=400的报文段。然而这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的

数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

   为了解决这个问题，TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值“。。如果窗口仍然是零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破了。