Linux内核网络拥塞控制算法的具体实现框架（一）

谈起网络拥塞控制，大家可能很熟悉八股文中的“加法增大“、”乘法减小“、”慢开始“、“拥塞避免”、“快重传”、“快恢复”等概念。没错，这是一种经典网络拥塞控制算法的基础理论，但在实际的实现时不同的拥塞控制算法，有很大差别。本文从Linux内核源码中学习网络拥塞控制算法的具体实现框架。从当前网络拥塞控制算法的发展历程上看，网络拥塞控制算法的类型主要有以下四种：

基于丢包的拥塞控制算法，这类算法将丢包视为发生了网络拥塞。采取缓慢的探测方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减少，代表的算法有Tahoe、Reno、NewReno、BIC、Cubic等。

基于延时的拥塞控制算法，这类算法将延时增大视为发生了网络拥塞，延时增大时减少拥塞窗口，延时减少时增大拥塞窗口，代表的算法有Vegas、Westwood等。

基于链路容量的拥塞控制算法，代表算法是BBR，其采用了另类的方式，不再使用丢包、延时等信号去衡量拥塞是否发生，而是直接对网络建模来避免以及应对真实的网络拥塞。

基于学习的拥塞控制算法，这类算法也没有特定的拥塞信号，一般是基于训练数据、评价函数，通过机器学习生成网络拥塞控制策略模型，代表算法有Remy、PCC、Aurora、DRL-CC、Orca等。

由于每类拥塞控制算法的核心理念有很大差别，关于每种算法的实现与原理在后续的文章中进行呈现。

本次文章先对Linux内核中网络拥塞控制实现细节、大致框架，进行分析和大概学习。在进行正式的分析前先简单梳理一下常识与概念：

什么是网络拥塞：网络拥塞是指在网络中传输的数据量超过网络链路或节点的处理能力，导致网络延迟增加、丢包率升高和带宽利用率下降的现象。

窗口（Window）：如下图的TCP协议头中占据16位，用于接收端告诉发送端还有多少缓冲区可以接收数据。

滑动窗口、发送窗口：下图所示黑色方框代表发送窗口。滑动窗口只是一种形象的称呼，即发送窗口一直移动从而达到发送新的数据的目的，如下图当接收到接收端发来的ACK数据包后发送窗口向右移动。图中灰色的方框代表已经发送且确认的数据，红色代表已发送且刚刚确认的数据，正是因为刚刚确认了5byte的数据，才驱动发送窗口可以向右移动5个单位，使得序号52~56的数据（绿色方框，代表允许发送的待发送数据）可以发送，当37 ~51区间的数据（蓝色方框，代表发送但未确认的数据包）能够被确认时，发送窗口才能向右滑动。发送窗口前方的数据（黄色方框，不允许发送的待发送数据）只能等待发送窗窗口区间内才能发送。TCP的滑动窗口是动态的，我们可以想象成小学常见的一个数学题，一个水池，体积V，每小时进水量V1，出水量V2。当水池满了就不允许再注入了，如果有个液压系统控制水池大小，那么就可以控制水的注入速率和量。这样的水池就类似TCP的窗口。应用根据自身的处理能力变化，通过本端TCP接收窗口大小控制来对对对端的发送窗口流量限制。

拥塞窗口：上面介绍了发送窗口的概念，在TCP协议中有一个反映网络传输能力的变量，叫做拥塞窗口（congestion
window），记作cwnd。发送端实际的发送窗口大小实际是为 接收端通告窗口 rwnd 与 拥塞窗口 cwnd 较小的那个值。

W=min（cwnd，rwnd）