TCP拥塞控制ABC Appropriate Byte Counting 的利弊说 _拥塞控制

世事洞明皆学问，人情练达即文章。这篇文章主要讲述TCP拥塞控制ABC Appropriate Byte Counting 的利弊说相关的知识，希望能为你提供帮助。
TCP在慢启动阶段，每一个RTT拥塞窗口按指数级增长，TCP在拥塞避免阶段，每一个RTT拥塞窗口线性增加1。这些都是书上讲的，不必太认真，真实的情况要比这个复杂的多！
首先我们看大部分的资料里讲的TCP是怎么实现每RTT增窗的，一切都是扯理论，没什么现实意义！
在慢启动阶段，每收到一个ACK(数据包从发出到收到其ACK，就是一个RTT)，窗口增加1，在拥塞避免阶段，每收到前一窗口整窗的ACK，窗口增加1，也就是说，每收到一个ACK，窗口增加1/cwnd！然而这都是理想情况，万一ACK丢了怎么办？万一接收端启用了delay ACK怎么办？
根据标准规定，接收端最多只能延迟2*MSS这么多的ACK，如果再多了就是stretch ACK了！也就是说，如果接收端启用了delay ACK，每收到两个数据包的时候才发一个ACK的话，发送端在一个RTT时间段内可能增加的窗口只有预期的1/2，这符合大多数资料里讲的逻辑吗？

标准其实并没有规定在拥塞避免阶段窗口一定是一个RTT增加1，而只是用了一个近似的算法：
Traditionally, TCPs have approximated this increase by increasing cwnd by 1/cwnd for each arriving ACK. This algorithm opens cwnd by roughly 1 segment per RTT if the receiver ACKs each incoming segment and no ACK loss occurs. However, if the receiver implements delayed ACKs [Bra89], the receiver returns roughly half as many ACKs, which causes the sender to open cwnd more conservatively(by approximately 1 segment every second RTT).

如果TCP真的表现为一包一ACK，那么大多数情况下确实可以做到慢启动指数增窗，拥塞避免线性增窗。但是正如上面所说，如果考虑到ACK丢失，或者接收端delay ACK等，理论逻辑就难免失真了。
TCP的ACK机制本身就是一种反馈，理论上“被ACK的数据越多，意味着可以发送的越多”这种猜测总是合理的，于是RFC3465提出了一个ABC算法，即通过收到的ACK中被ACK的字节数来计算如何增加窗口。

1.safe area和dangerous area TCP作为一种端到端的协议并没有带宽反馈的能力，因此其拥塞控制机制完全是基于探测的，即不断地试探带宽的极限，不管多么好的拥塞控制算法，其本质也不外乎以上这种探测。在拥塞控制看来，所谓的带宽探测最终落实到拥塞窗口探测上。
如今的TCP实现基本延续了NewReno的内核，在拥塞窗口探测的过程中，它会经历两个区域，一个是safe区域，一个是dangerous区域，两个区域由ssthresh来分割。在safe区域中，执行指数增窗的慢启动，在dangerous区域执行线性增窗的拥塞避免。ssthresh事实上是安全增窗的上界，也可以理解为保守的满带宽窗口，既然是安全的区域，那么就可以尽可能快的增加窗口，于是理论上每来一个ACK(这说明网络是通的)，窗口就可以增加1，而不必等待一窗数据均被ACK才增窗，在越过了ssthresh之后，TCP会认为随时都有可能超过网络的承载能力，于是只有在一窗数据都被ACK了之后，才可以增窗。

2.如何利用ACK的反馈信息以上的关于safe/dangerous区域的描述中，所有的增窗行为均是通过ACK来反馈的，RFC2581建议使用ACK的数量来作为增窗的信号，然而面对ACK丢失或者delay ACK的时候，RFC3465给出了ABC算法，在ABC中，使用被ACK的字节数而不是ACK的数量来作为增窗的反馈信号。这样的话，以下过程将被执行：
1.慢启动阶段：只要被ACK的数据字节数达到了一个MSS大小，窗口增加一个MSS；
2.拥塞避免阶段：只要被ACK的数据字节数达到了一窗的大小，窗口增加一个MSS。
除此之外，ABC可以让TCP在慢启动阶段更加激进，它可以让TCP每收到ACK了一个MSS的确认包后，增加N个而不是1个MSS窗口的大小，因为这是在安全区域，激进不为过！

3.ABC与突发 ABC貌似解决了delay ACK以及ACK丢失带来的窗口增加缓慢的问题，然而却带来了突发问题，这个突发问题是利还是弊，并不绝对！本质上来讲，ABC算法会带来突发的原因是它会“记住”那些迟到的或者丢失的确认，并积累起来日后使用，这非常类似于网络流量控制的突发令牌桶的原理，令牌是可以积累使用的，在TCP中，每一个针对一个MSS大小数据段的确认，不管其是显式的还是隐式的，都相当于一个可以积累的令牌。
1.异常带来的突发
假设ACK大面积丢失，对于发送端而言，ACK到来的频率会降低，造成的效果就是窗口长时间由于收不到ACK而僵住，一旦收到一个ACK，发送端会发现它ACK了大量(甚至巨量)的数据，窗口一下子得到了补偿，可能会增加很多，这种突发对于慢启动阶段可能会更严重，因为慢启动阶段每确认MSS大小的数据，窗口就会增加N(取决于配置)，而对于拥塞避免阶段，情况会缓和很多。
这种异常带来的突发，在单向拥塞的情况下，问题不大，如果发生了双向拥塞，发送端的激进增窗带来的就是更多丢包了，发送端在无法区别对待ACK丢失和delay ACK的情况下，会造成很多的误判，幸好，TCP规范了stretch ACK的定义，这或许会给发送端的判断带来一些暗示，比如收到了连续ACK了超过2个MSS数据的确认包，就判断为是ACK丢失，保守增窗。
为了保证发生上述问题的时候异常突发不会带来严重的后果，RFC3465规定慢启动阶段，N的最大值为2，即每收到一个MSS大小的确认，窗口最多增加2个MSS！
2.正常突发
相对于异常突发，正常突发就显得更加像是一个正反馈无级变速系统了，简单来讲，如果不考虑delay ACK和ACK丢失以及接收端的实现bug，ABC算法执行地会相当平滑，即ACK覆盖面越广，增窗就越快，不考虑拥塞的情况下，这意味着你发送的数据越多，窗口增加的越快！
RFC3465有一个例子很好，比如你登录了ssh进行交互式作业，大多数情况下都是小数据的交互，此时窗口增加比较缓慢(ABC算法按照被ACK的字节数大小来决定是否增窗以及增加多少)，此时如果你需要在终端显示一个大文件，那么交互的数据量几乎是瞬间变大，如果按照RFC2581的方式增窗，窗口增加完全按照ACK的数量来的话，就等于说是有了一个最高的限速，然而如果使用ABC的话，随着大块数据的发送和被确认，窗口的增速也随之增加。这种情况下，ACK到达的速率是不变的，然而ACK覆盖的字节数却变大了，窗口增速也就随之变大。

3.穿越ssthresh 在慢启动阶段，窗口按照指数增长，如果ssthresh的值比较大，在窗口穿越ssthresh的时候，其可能已经是十分大了，在最后一次慢启动增窗中，很大的可能性会使窗口一下子升到ssthresh以上很多，超过了网络的承载能力造成丢包。在这种情况下，ssthresh根本就没有起到阈值的作用，在ABC算法中N为2的情况下，问题更加严重。
之所以会有这个问题，是因为TCP没有在窗口增加到ssthresh附近的时候没有更细化的控制。不过这不是什么问题，Linux 4.x+已经完美修正了这个问题(具体我不知道是哪个版本引入的，但是我确定3.10中没有，而4.3中有)。

4.ABC与Linux TCP实现 Linux关于ABC算法的实现经历了三个阶段。
阶段一：ABC作为一个sysctl选项
以2.6.32内核版本为例，Linux有一个sysctl_tcp_abc选项，它会选择是否使用ABC算法，如果启用ABC，一个ACK包确认的字节数会被保存在bytes_acked字段里，在拥塞避免阶段，TCP是这样使用bytes_acked的：

if (tp-> bytes_acked > = tp-> snd_cwnd*tp-> mss_cache) { tp-> bytes_acked -= tp-> snd_cwnd*tp-> mss_cache; if (tp-> snd_cwnd < tp-> snd_cwnd_clamp) tp-> snd_cwnd++; }

而bytes_acked会在收到ACK的时候被更新：

if (icsk-> icsk_ca_state < TCP_CA_CWR) tp-> bytes_acked += ack - prior_snd_una; else if (icsk-> icsk_ca_state == TCP_CA_Loss) /* we assume just one segment left network */ tp-> bytes_acked += min(ack - prior_snd_una, tp-> mss_cache);

然而，如果没有使用ABC的话，在每收到ACK的时候会执行下面的逻辑：

if (tp-> snd_cwnd_cnt > = tp-> snd_cwnd) { if (tp-> snd_cwnd < tp-> snd_cwnd_clamp) tp-> snd_cwnd++; tp-> snd_cwnd_cnt = 0; } else { // 可见，不使用ABC是通过ACK的数量来计数的 tp-> snd_cwnd_cnt++; }

在慢启动阶段：

if (sysctl_tcp_abc > 1 & & tp-> bytes_acked > = 2*tp-> mss_cache) cnt < < = 1; // 可以增加2倍窗口 // 慢启动阶段完全按照一次ACK的MSS倍数来决定增窗大小，因此需要清除bytes_acked tp-> bytes_acked = 0; tp-> snd_cwnd_cnt += cnt; // 注意，下面的算法可能会出现ssthresh的穿越问题！ while (tp-> snd_cwnd_cnt > = tp-> snd_cwnd) { tp-> snd_cwnd_cnt -= tp-> snd_cwnd; if (tp-> snd_cwnd < tp-> snd_cwnd_clamp) tp-> snd_cwnd++; }

阶段二：ABC可选实现
以3.10为例，你会发现没有了tcp_abc选项，在代码中，也再也没有了关于bytes_acked的计数，而且在拥塞避免阶段，也只剩下了tcp_cong_avoid_ai(tp, tp-> snd_cwnd)的逻辑，而这个逻辑是按照ACK的数量来计数的。
那么如果想实现ABC怎么办呢？只好在自己的拥塞模块里面自己写了。每个ACK所确认的数据量(即bytes_acked)可以通过pkts_acked回调函数获取(在清理传输队列的数据包后调用)。
阶段三：ABC内置并优化实现
到了Linux 4.4内核，依然还是没有tcp_abc选项，然而如果你看代码，发现基本已经完全实现了ABC算法：

void tcp_reno_cong_avoid(struct sock *sk, u32 ack, u32 acked) { struct tcp_sock *tp = tcp_sk(sk); if (!tcp_is_cwnd_limited(sk)) return; /* In "safe" area, increase. */ if (tcp_in_slow_start(tp)) { // slow_start函数有了返回值，返回慢启动结束后，还剩下多少被确认的数据可以用来增加拥塞避免增窗计数器 acked = tcp_slow_start(tp, acked); // 如果返回0，说明此次增窗还没有穿越ssthresh。可见新版本完美捕捉到了ssthresh穿越问题 if (!acked) return; } /* In dangerous area, increase slowly. */ // acked参数被传入，作为增窗条件的计数被累加。 tcp_cong_avoid_ai(tp, tp-> snd_cwnd, acked); }

如果我们看下tcp_slow_start，会发现它异常简洁：

u32 tcp_slow_start(struct tcp_sock *tp, u32 acked) { // 慢启动阶段，窗口最多增加到ssthresh。 // acked累加到窗口，虽然不是ABC的标准算法(没有实现N增窗)，但基本就是那个意思 u32 cwnd = min(tp-> snd_cwnd + acked, tp-> snd_ssthresh); // 剩下的穿越ssthresh的部分交给拥塞避免来处理 acked -= cwnd - tp-> snd_cwnd; tp-> snd_cwnd = min(cwnd, tp-> snd_cwnd_clamp); return acked; }

函数tcp_cong_avoid_ai的注释也多了一句话：

/* In theory this is tp-> snd_cwnd += 1 / tp-> snd_cwnd (or alternative w), * 下面这句话是新增的... * for every packet that was ACKed. */ void tcp_cong_avoid_ai(struct tcp_sock *tp, u32 w, u32 acked) { /* If credits accumulated at a higher w, apply them gently now. */ if (tp-> snd_cwnd_cnt > = w) { tp-> snd_cwnd_cnt = 0; tp-> snd_cwnd++; } // 累加被确认的数据量而不是每收到ACK简单加1 tp-> snd_cwnd_cnt += acked; ... ｝

TCP是一个复杂无比的协议，Linux的实现也历经着无比大的变化，从2.6.8到4.4，你会发现很多细节连基本思想都改变了，这背后，如果不了解RFC中阐释的思路，将很难理解其所以然，因此RFC才是王道，内功，心法！【TCP拥塞控制ABC Appropriate Byte Counting 的利弊说】再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow