TCP滑动窗口

1、滑动窗口的概念

  TCP每发送一个数据，都需要进行一次应答。当收到了上一个应答，在发下一个数据，但这种方式效率比较低。数据包往返时间越长，通信的效率就越低。
  为了解决这个问题，TCP引入了窗口概念。即在接收窗口范围内的数据，无需等待确认，可以继续发送窗口内数据，直到把发送窗口数据传输完毕。
  窗口的实现实际上是在操作系统开辟一个缓存空间（空间和序号都是有限的，并且要循环使用，一般为环形队列），发送主机在等到确认应答返回之前，必须在缓冲区保留已发送窗口的数据（超时重传）。收到应答后，将此数据清除。

2、滑动窗口的使用

  TCP的滑动窗口是以字节为单位的。
  TCP通信是全双工通信，通信中的每一方都在发送和接收报文段。每一方都有自己的发送窗口和接收窗口。
  假设数据是由A发往B的，即A发送数据，B给出确认。

  如图所示，表示B发来的确认报文段。其中窗口是20字节，确认号是31（表明B期望收到的下一个序号是31，表示31之前的数据已收到）。根据这两个数据，A根据B的窗口值构造出自己的发送窗口为20字节（A的发送窗口一定不能超过B的接收窗口数值，上篇文章讲到过的）。
  其中A主机在没得到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已发送过的数据，在未收到确认之前都必须暂时保留在缓存空间内，以便在超时重传使用。
  上图窗口后沿之后的数据表示已发送且收到了确认。这部分数据不需要在保留。发送窗口前沿之前的部分数据表示不允许发送的，接收方没有更多缓存接收这些数据。

3、滑动窗口的位置

发送和接收窗口的位置在实时动态变化着。

  在程序设计上描述一个窗口状态需要三个指针。
如上图A的发送窗口

P3 - P1 = A的发送窗口
P2 - P1 = 已发送但尚未收到确认的字节数
P3 - P2 = 允许发送但当前尚未发送的字节数（又称可用窗口或有效窗口）

  B的接收窗口。窗口大小是20。窗口之外，到30为止的数据时已经发过确认，并且已经交付主机了。因此B可以不在保留这些数据。接收窗口内的数据序号（31~50）是允许接收的。
  对于不按序到达的数据，TCP标准并无明确规定。如果接收方把不按序到达的数据一律丢弃，那么接收窗口管理将会比较简单，但是对网络资源的利用不利。因此TCP通常对不按序到达的数据时先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，在按序交付上层的应用进程。
  如上图，B先收到了序号为32和33的数据（31未收到，也许丢失或滞留在网络中），此时B会给出确认报文，报文段中确认号仍为31（31未收到，期望收到的序号）。

  假定B以收到序号为31的数据，并把序号为31~33的数据交付主机，然后把接收窗口向前移动3个序号，并删除已交付数据缓存（如上图）。同时给A发送确认，窗口大小仍为20，确认号34。图中可以注意到，已经收到了序号为37,38和40的数据，但这些都未按序到达，同样按以上方法暂存到接收窗口中。
  A收到B的确认后，就可以把发送窗口向前滑动3个序号，即P1和P3向右移动3序号，但P2不动。A的可用窗口在增大。
  此时A继续发送数据，指针P2向前移和P3重合。发送窗口内的序号都已用完，但还没有再收到确认。由于A的发送窗口已满，可用窗口为0，就必须停止发送了。

  为了保证可靠传输A不能猜测：“或许B收到了吧！”，A只能认为B还没收到这些数据。于是A经过一端时间后（超时计数器时间）重传此段数据，重新计时，直到收到B的确认为止。