TCP协议——滑动窗口，流量控制

滑动窗口

滑动窗口主要解决效率的问题

滑动窗口在自身发送缓冲区中，可以发送数据，但不收到应到的数据量

TCP的确认应答机制，在对每一个发送的数据段，都要给一个ACK的确认应答，收到ACK之后，再发送下一个数据段，虽然保证了可靠性，但是性能较低，尤其是对于数据往返时间较长时。

为了解决这一问题，我们可以一次发送多条数据，就可以提高效率。

如下：

• 窗口大小就是指无需等待确认应答而可以继续发送数据的最大值，可以理解为一个窗口一次性最多能够通过的数据量，上图中的窗口大小为4000个字节（四个字段）
• 发送前四个字段的时候，无需等待任何ACK，直接发送
• 收到第一个ACK后，窗口向后移动，继续发送第五个段的数据；以此类推
• 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答，只有确认应答过的数据，才能从缓冲区删掉。
• 窗口越大，则网络吞吐量越高。

当出现丢包，应该怎么办，如何重传

我们将丢包分两种情况讨论

1.数据包到达，但ACK丢失
这种情况可以根据后续的ACK包来进行确认

2.数据包丢失

• 当某一段报文丢失，发送端会一直收到像1001这样的ACK，就像在提醒发送端，我想要“1001”
• 如果发送端主机连续三次收到重复的ACK，那么对应的数据包就会重新发送
• 这时收到重新发送的包之后，再返回的ACK就是7001了，因为2001-7000早已接收到了，只是被放到了接收端的接收缓冲区中。
  这样的机制被叫做“快重传”，快重传即解决了效率问题，又解决了可靠性问题
  超时重传是保障，快重传是锦上添花

流量控制

流量控制是一个保证可靠性的机制

接收端处理数据的速度是有限的，如果发送端发送的太快，导致接收端的缓冲区被填满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等一系列连锁反应

因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制

• 接收端将自己可以接受的缓冲区大小放入TCP首部的“窗口大小”的字段中，通过ACK端通知发送端
• 窗口字段越大，说明网络吞吐量越高
• 接收端发现自己的接收缓冲区快满了，就会将窗口设置成一个更小的值通知给发送端
• 发送端接收到这个值之后，就会减慢自己的发送速度
• 如果接收端的缓冲区满了，就会将窗口置为0，此时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，来将窗口的大小告诉发送端

注意：发送端通过了解窗口字段来控制自己的发送速度，在TCP首部窗口有16位有效位，16位最大就是65535，但是我们的窗口最大不止65535，在TCP首部的40字节选项中包含了一个窗口扩大因子M，实际窗口的大小是窗口字段的值左移M位