TCP滑动窗口、流量控制、拥塞控制

一、滑动窗口

上篇博客我们介绍了TCP报文结构、确认应答机制、超时重传机制、连接管理机制。
TCP保证了可靠传输，但是失去了效率。那么怎么样尽可能提高传输效率呢？？？

我们讨论了确认应答策略：对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段。
这样做有一个比较大的缺点，就是性能较差，尤其是数据往返的时间较长的时候。

主机A大量的时间都消耗在了等待ACK上！

既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能 (其实是将多个段的等待时间重叠在一起了) ！

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

那么如果出现了丢包，如何进行重传？这里分两种情况讨论。

情况一： 数据包已经抵达，ACK被丢了。

这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认！

情况二： 数据包就直接丢了。


2001 - 7000 接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。

这种搭配滑动窗口的机制被称为"高速重发控制" (也叫"快重传")。

二、流量控制

窗口大小越大，确实发送速度会更快~~ 但是窗口能无限大吗？

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

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

接收方的接收速率如何进行量化？
接收方使用接收缓冲区的剩余空间大小来作为发送方发送速率(窗口大小)的参考数值！

如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

接收端如何把窗口大小告诉发送端呢？回忆我们的TCP首部中，有一个16位窗口字段，就是存放了窗口大小信息：

16位数字最大表示65535，那么TCP窗口最大就是65535字节么？
实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位~~

三、拥塞控制

流量控制是通过接收方的处理能力来衡量发送方的速率的。
难道只需要考虑接收方的处理速率吗？显然不是，还得考虑中间的这些转发节点的情况！


网络的环境是复杂的，网络环境也不是一成不变的~~
这就是拥塞控制！

流量控制是在控制发送方的窗口大小；拥塞控制也是在控制发送方的窗口大小。
那么有分歧的时候听谁的？谁小听谁的！！！(木桶原理)

TCP实现拥塞控制的具体方式是什么呢？
TCP引入慢启动机制，先发少量的数据探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。

拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案~~