TCP滑动窗口和拥塞控制算法

滑动窗口

为了解决可靠传输以及包乱序的问题，TCP 引入滑动窗口的概念。在传输过程中，client 和 server 协商接收窗口 rwnd，再结合拥塞控制窗口 cwnd 计算滑动窗口 swnd。在 Linux 内核实现中，滑动窗口 cwnd 是以包为单位，所以在计算 swnd 时需要乘上 mss（最大分段大小）。

swnd = min(rwnd, cwnd * mss)

滑动窗口包含 4 部分：

• 已收到 ack 确认的数据；

• 已发还没收到 ack 的；

• 在窗口中还没有发出的（接收方还有空间）；

• 窗口以外的数据（接收方没空间）。

保守规则

TCP 维护一个发送窗口，估计当前网络链路上能容纳的数据包数量，希望在有数据可发的情况下，回来一个确认包就发出一个数据包，总是保持发送窗口那么多包在网络中流动。

传输的理想情况是要同时达到最大的吞吐量和最小的往返延迟，要达到这个目的，连接必须同时满足两个条件：

• 以链路瓶颈带宽 BtlBw 发包 （带宽利用率最高）

• 保证链路中没有缓存队列（延迟最低）

包守恒原则是拥塞控制的基础。

 

拥塞控制

拥塞控制的目的是避免过多的数据一下子涌入网络，导致网络超出最大负荷。QUIC 的拥塞控制与 TCP 类似，并在此基础上做了改进。所以我们先简单介绍下 TCP 的拥塞控制。

TCP 拥塞控制由 4 个核心算法组成：慢启动、拥塞避免、快速重传和快速恢复，理解了这 4 个算法，对 TCP 的拥塞控制也就有了大概了解。

• 慢启动：发送方向接收方发送 1 个单位的数据，收到对方确认后会发送 2 个单位的数据，然后依次是 4 个、8 个……呈指数级增长，这个过程就是在不断试探网络的拥塞程度，超出阈值则会导致网络拥塞；

• 拥塞避免：指数增长不可能是无限的，到达某个限制（慢启动阈值）之后，指数增长变为线性增长；

• 快速重传：发送方每一次发送时都会设置一个超时计时器，超时后即认为丢失，需要重发；

• 快速恢复：在上面快速重传的基础上，发送方重新发送数据时，也会启动一个超时定时器，如果收到确认消息则进入拥塞避免阶段，如果仍然超时，则回到慢启动阶段。

拥塞窗口校验

在 [RFC2861] 中，区分了 TCP 连接数据传输的三种状态：

• network-limited：TCP 的数据传输受限于拥塞窗口而不能发送更多的数据。

• application-limited：TCP 的数据传输速率受限于应用层的数据写入速率，并没有到达拥塞窗口上限。

• idle：发送端没有额外的数据等待发送，当数据发送间隔超过一个 RTO 的时候就认为是 ilde 态。

cwnd 代表了对网络拥塞状态的一个评估，拥塞控制要根据 ACK 来更新 cwnd 的前提条件是，当前的数据发送速率真实的反映了 cwnd 的状况，也就是说当前传输状态是 network-limited。假如 tcp 隔了很长时间没有发送数据包，即进入 idle，那么当前真实的网络拥塞状态很可能就会与 cwnd 反映的网络状况有差距。另外在 application-limited 的场景下，受限数据的 ACK 报文还可能把 cwnd 增长到一个异常大的值，显然是不合理的。基于上面提到的两个问题，[RFC2861]引入了拥塞窗口校验(CWV，Congestion Window Validation)算法。

流量控制

TCP 会对每个 TCP 连接进行流量控制，流量控制的意思是让发送方不要发送太快，要让接收方来得及接收，不然会导致数据溢出而丢失，TCP 的流量控制主要通过滑动窗口来实现的。可以看出，拥塞控制主要是控制发送方的发送策略，但没有考虑到接收方的接收能力，流量控制是对这部分能力的补齐。

扩展http2：

Stream 级别对防止接收端接收过多数据作用有限，更需要借助 Connection 级别的流量控制。理解了 Stream 流量那么也很好理解 Connection 流控。Stream 中，接收窗口(flow control receive window) = 最大接收窗口(max receive window) - 已接收数据(highest received byte offset) ，而对 Connection 来说：接收窗口 = Stream1 接收窗口 + Stream2 接收窗口 + ... + StreamN 接收窗口 。

扩展http3：

那 QUIC 是怎么实现流量控制的呢？我们先看单条 Stream 的流量控制。Stream 还没传输数据时，接收窗口（flow control receive window）就是最大接收窗口（flow control receive window），随着接收方接收到数据后，接收窗口不断缩小。在接收到的数据中，有的数据已被处理，而有的数据还没来得及被处理。如下图所示，蓝色块表示已处理数据，黄色块表示未处理数据，这部分数据的到来，使得 Stream 的接收窗口缩小。

 

参考链接：

https://mp.weixin.qq.com/s/KTKVu3uCC5MFlU5oylZPFA

https://mp.weixin.qq.com/s/MHYMOYHqhrAbQ0xtTkV2ig

• TCP 的那些事儿（上） TCP 的那些事儿（下）

• TCP 系列 08—连接管理—7、TCP 常见选项(option)

• TCP timestamp

• Early Retransmit forTCP

• TCP Tail Loss Probe(TLP)

• TCP 重点系列之拥塞状态机

• Congestion Control in Linux TCP

• TCP 拥塞控制图解

• TCP 进入快速恢复时的窗口下降算法

• tcp 中 RACK 算法

• TCP 系列 23—重传—13、RACK 重传

• TCP 系列 18—重传—8、FACK 及 SACK reneging 下的重传