攻击和利用TCP的拥塞控制

仅局限于用DDoS或RST这种手段攻击TCP是无趣的，这两种攻击损人不利己，且很容易被发现，所以不好玩。

对TCP拥塞控制的攻击有趣，它能带来实际的“效果”和麻烦：

• 让网络变拥塞。
• 让用户浪费钱。
• …

怎么做呢？不难。

TCP依赖ACK自时钟触发发包，以Linux TCP为例(其它的系统也大同小异)，它实现了一个拥塞状态机，我捡重点说：

• 未开启SACK，RACK，收到reordering个重复ACK触发重传。
• 开启SACK，未开启RACK，收到reordering个SACKed段触发重传。
• 开启RACK，执行时间序重传逻辑。

只需构造特殊ACK/SACK序列并注入发送端，就能让发送端无效重传。比如，在真正的积累ACK尚未到达发送端前，先给它注入多个重复ACK，或者携带多个SACKed空洞，协议栈里的效果是：

• 发送端平白无故向网络注入了多个无效的重传包。
• 发送端的recovery状态被后续真实ACK成功undo，不影响cwnd。
• 发送端继续以实际cwnd发包，但多发了无效的重传包。

实际效果是：

• 多发了重传包，网络更拥塞，更容易丢包。
• 多发了重传包，成本更高，花的钱更多。
• 拥塞丢包导致吞吐降低。
• 综合效果是，连接既慢，又要多花钱。
• …

这里有个疑问点，有人会说，你都能构造ACK序列并且注入了，为啥不直接构造Data包并注入呢？这样亦可达到拥塞网络并增加用户计费的目的。话是没错，问题是并不知道计费，审计的点在哪个位置，这就对注入位置有了更多的要求。

构造ACK序列是可以在任意地方进行的。真查起来，这些无效重传的数据包，明明白白就是从发送端发出的。

BBR普遍采用RACK算法，稍好，时间序没那么容易触发重传，但依然可以构造乱序序列或者构造时间戳进行RTT欺骗来触发重传。

归根结底，这是TCP ACK自时钟反馈导致的，没反馈就不发包，但反馈可以任意构造。packetdrill很容易试验这种效果。若使用无反馈单向传输，则无此问题，接收端亦可将所需的发送速率以独立应用层数据的形式进行反馈(可加密)，而非在传输协议层面去支持什么自时钟。

说个Linux TCP实现的小细节，关于reneging。看一段注释：

/* If ACK arrived pointing to a remembered SACK, it means that our
 * remembered SACKs do not reflect real state of receiver i.e.
 * receiver _host_ is heavily congested (or buggy).
 *
 * To avoid big spurious retransmission bursts due to transient SACK
 * scoreboard oddities that look like reneging, we give the receiver a
 * little time (max(RTT/2, 10ms)) to send us some more ACKs that will
 * restore sanity to the SACK scoreboard. If the apparent reneging
 * persists until this RTO then we'll clear the SACK scoreboard.
 */

真正将所有SACKed段忘记，全部标记LOST并重传之前，等上一丢丢时间，这样就避免了可能存在的无效重传，特别是在长肥链路场景下。如果没有这个逻辑，发现reneging马上重传，那么只需构造一个reneging序列即可制造麻烦。在老版本内核中，不会等这个时间，但也只是重传一个数据包。因此看起来意义不大，但不晓得其它TCP实现是如何处理reneging的，得试。

利用TCP拥塞控制制造麻烦，需进行流量嗅探，踩点抓包，在真实ACK尚未返回时，地址端口逆转，seq，ack颠倒，构造修改，注入网络即可，谁能提供嗅探点是个问题，但这已和TCP无关。

若仅制造麻烦，不是做这件事的好理由，动机背后都是利益，让网络变拥塞没有实际意义，让用户多掏钱是个好理由。

大雨一天，继续居家办公，晚上夜深人静，写点东西。有朋友反馈说我写的这些东西属于走火入魔型的，嗯，我觉得也是，不过这些本就是闲来的夜谈，随便玩玩的东西，有趣，但千万别上瘾，更不能用在工作中。写这篇的动机在于，一提到攻击TCP就要么是DDoS，要么是RST，千篇一律，所以想写点不同的。

浙江温州皮鞋湿，下雨进水不会胖。