5.6.1 以字节为单位的滑动窗口

滑动窗口的工作原理

• 以 字节 为单位。
  如下图，假定A收到了 B发来的确认报文段 ：其中 窗口 是20字节，确认号 是31（表明B期望收到的下一个序号是31，30及之前的都已经收到了）
  A根据 B发来的确认报文段 中的这两个数据，构造出了自己的 发送窗口
  
  在没有收到B的确认的情况下，A可以连续把 窗口内的数据 都发送出去。
  凡是发送过的数据，在未收到对方的确认之前都必须暂时保留，以便在超时重传时使用。
  发送窗口里面的序号 表示允许发送的序号。
  窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而获得更高的传输效率。
  但是发送窗口的值一定不能超过接收窗口的值；发送方的发送窗口的大小受到 网络拥塞程度 和 接收窗口 的制约。
  发送窗口 后沿后面的的部分 表示已发送且已收到了确认，这些数据不需要再保留了。
  发送窗口 前沿的前面部分 表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。
  发送窗口的位置由窗口前沿和后沿的位置共同确定。
  发送窗口 后沿的变化 有两种情况，不动（未收到新的确认）和前移（收到了新的确认）。注意发送窗口的后沿不可能向后移动，因为不能撤销掉已收到的确认，后面的被确认的数据已经出缓存被丢掉了。
  发送窗口的 前沿的变化 通常是不断地向前移动，也有可能不动。前沿不动的情况有两种：1、未收到新的确认，对方通知的窗口大小也不变；2、收到了新的确认但是对方通知的窗口也缩小了，使得发送窗口的前沿正好不动。（一般不会让发送窗口的前沿后移，因为可能发送方在收到这个通知以前已经发送了窗口中的许多数据，现在又要收缩窗口，不让发送这些数据，会产生错误）

• 现在假定A发送了 序号为31 ~ 41的数据 ，但未收到确认。因此发送窗口的位置并未改变。如下图：
  
  发送窗口靠后的11个字节（黑色）表示发送还未收到确认（只有被确认的数据才能出发送窗口，确认 中包含 确认号 ，如此新的数据也可以进发送窗口）。
  发送窗口靠前的9个字节（42 ~ 50）是允许发送但尚未发送的。
  如上图，要描述一个发送窗口的状态需要3个指针：P₁，P₂，P₃。指针都是指向字节的序号，3个指针指向的几个部分的意义如下：
  小于P₁的是已发送并已收到确认的部分;
  大于P₃的是不允许发送的部分；
  P₃ - P₁ 是 A的发送窗口;
  P₂ - P₁ 是已发送但当前尚未收到确认的字节数;
  P₃ - P₂ 是允许发送但当前尚未发送的字节数（又叫可用窗口和有效窗口）;
  再看B的 接收窗口 ：
  大小为20。
  接收窗口后沿往后：到30为止的数据是已经发送过确认且已经交付主机的数据。因此B不在保留这部分数据。
  接收窗口中的序号 31 ~ 50 是允许接收的。
  上图中B收到了32、33号数据，但31号数据未收到（丢失或者还在路上）；但是B只能对 按序收到的数据中的最高序号 给出确认，因此B发送的确认报文段中的确认号仍然是31（即期望收到的序号）。

• 若某一时刻B收到了序号为31的数据，并把序号为31 ~ 33 的数据交付主机，然后把接收窗口向前移动3个序号，同时向A发送确认（窗口只仍是20，但确认号是34），如下图。
  
  B还收到了序号为37，38和40的数据，但这些都没有按序到达，只能先暂存在接收窗口中。
  A收到B的确认后，就可以把发送窗口后沿向前滑动3个序号，但指针P₂不动，可以看出现在A的可用窗口增大了，发送范围是 42 ~53。

• A继续发送完序号42 ~ 53的数据后，指针 P₂ 向前移动和 P₃ 重合。
  此时发送窗口内的序号都已用完，但还未收到确认。
  由于A的发送窗口已满，可用窗口减小到0，因此必须停止发送，等待B的确认。
  超时计时器控制时间超过后，A重传这部分数据，并重新设置超时计时器，直到收到B的确认为止
  若A收到确认号落在发送窗口内，那么A就可以使发送窗口继续向前滑动，并发送新的数据。
  

窗口与缓存的关系

TCP缓存区与窗口的关系

• 发送方的应用进程 把 字节流 写入 TCP的发送缓存 。
  接收方的应用进程 从 TCP的接收缓存 中读取 字节流 。

• 如下图，分别是：
  发送方维持的发送缓存 和 发送窗口
  接收方维持的 接收缓存 和接收窗口
  

• 缓存空间和序号空间都是有限的、循环使用的，将其画成圆环状的较客观。

• 如上图，发送方：
  发送缓存用来暂存：
  1、发送应用进程传送给发送方TCP、准备发送出去的数据；
  2、TCP已经发送出去、但尚未收到确认的数据。
  发送窗口通常只是发送缓存的一部分。
  已经被确认的数据应当从发送缓存中删除。因此发送缓存和发送窗口的后沿是重合的。
  发送应用进程最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中的字节。
  发送应用进程必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。

• 如上图，接收方：
  接收缓存用来暂存：
  1、按序到达的、但尚未被接收应用进程读取的数据；
  2、未按序到达的数据。
  若收到的分组有差错，则丢弃。
  若接收应用进程来不及读取收到的数据，接收缓存会被填满，使接收窗口减小到0。
  若接收应用进程能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但接收窗口不能超过接收缓存的大小。

总结

• 1、虽然A的发送窗口是由B的接收窗口设置的，但在同一时刻，而这并不总是一样大。
  因为通过网络来传递窗口只有时延。
  另外发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值（接收方 接收窗口 和 网络拥塞情况 中取一个较小值）。

• 2、对于 不按序到达的数据 ，TCP未明确规定如何处理。
  若接收方对不按序到达的数据一律丢弃：会简化接收窗口的管理，但会降低网络资源的利用率（发送方会重复传送很多数据）
  通常TCP对于不按序到达的数据先临时存放在接收窗口中，等到字节流所缺少的字节收到后，再按序交付上层的应用进程。

• 3、TCP要求接收方必须有 累计确认 的过程，便于减小传输开销，接收方可以在合适的时候发送确认，也可以在自己有数据要发送的时候顺便捎带上。
  但接收方不应过分推迟发送确认，否则可能导致发送方不必要的重传，反而浪费了网络资源。
  捎带确认实际中很少用，因为大部分应用进程很少同时在两个方向上发送数据。

• 4、TCP是 全双工通信 ，通信的每一方都有自己的发送窗口和接收窗口。
  双方共四个窗口。