5.7.1 利用滑动窗口实现流量控制

• 若发送方数据发送过快，接收方可能来不及接收，造成数据丢失。

• 流量控制
  让发送方的发送速率不要太快，要让接收方来的及接收。

• 如何利用 滑动窗口 来实现对 发送方的流量控制
  发送方的发送窗口不能超过接收方给出的接收窗口的数值。
  TCP的 窗口单位 是字节，不是报文段。
  
  A向B发送数据。
  设每一个报文段是100字节长。数据报文段 序号的初始值 设为1。大写ACK表示 确认位（连接建立后所有传送的报文段都必须把ACK置1），小写ack表示 确认字段的值 。
  连接建立时，B告诉A：我的 接收窗口 rwnd = 400。
  接收方的主机B进行了3次流量控制：第一次把窗口减小到300，第二次减小到100，第三次减小到0即不允许A发送数据了。
  这种使发送方 暂停发送的状态 将持续到主机B重新发出 一个新的窗口值 为止。
  上图中，若B向A发送了 零窗口的报文段 后不久，B的接收缓存又有了一些存储空间。于是B又向A发送了rwnd=400的报文段。然而这个报文段在传送过程中丢失了。A一直等待收到B发送的 非零窗口的通知 ，而B也一直等待A发送的数据。若没有其他措施，这种 互相等待的死锁局面 将一直延续下去。
  为解决上述问题，TCP为每个连接设有一个 持续计时器 。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若 持续计时器设置的时间 到期，就发送一个 零窗口探测报文段 （仅携带一个字节的数据） ，而对方就在确认这个探测报文段时给出现在的窗口值。若窗口仍然是0，那么收到这个报文段的一方就重新设置持续计时器；若窗口不是0，那么死锁的僵局就打破了。

• 持续计时器
  用于 发送方TCP 收到 零窗口大小通知 后的处理。
  若 接收方TCP 发出了 窗口大小为0的报文段 ，发送方TCP 就会停止传送报文段，直到 接收方TCP 发送确认并给出一个非零的窗口大小。
  但这个确认可能会丢失。
  在TCP中，对于 确认报文段 是不需要发送确认的。
  若 这个非零窗口大小的确认 丢失了， 接收方TCP 无从得知，会一直等待发送方TCP发送数据；而 发送方TCP 由于未收到次确认也会等待接收方TCP发送确认来通知接收窗口大小。
  要打开这种 死锁 ，TCP为 每一个连接 使用了 一个持续计时器 。
  当发送方TCP收到 一个零窗口的确认 时，就会启动 该连接的持续计时器 。当持续计时器期限到时， 发送方TCP 就发送一个 探测报文段 （此报文段只有 一个字节的数据 ，探测报文段的有一个序号，但这个序号不需要确认）。 探测报文段 提醒接收方TCP：确认已丢失，请重传。
  持续计时器的值 设置为 重传时间的数值 。若 第一个探测报文段 的持续计时器到期也未收到从接收方TCP的响应，那么需要发送 另一个探测报文段 ，并将持续计时器的值加倍和复位，知道这个值增大到 门限值 （通常是60秒）为止。
  此后发送端每隔60秒就发送一个探测报文段，直到窗口重新打开。