TCP和宽容

网络对TCP很宽容，但TCP对网络并不宽容，这意味着转发节点必须小心翼翼处理TCP。

核心IP网络本是尽力而为，面对TCP却有使不上劲儿的感觉。本文后面我会讲一个故事，在这个故事前，我先描述结论。

转发节点无法并行处理同一条TCP流。若串行化，会有新问题，单程串行将影响TCP的burst，order pacing时序。转发节点的资源分配和利用严重影响TCP流的形态。

无论两个CPU并行处理两个长程，还是分别处理一个半程，总吞吐和单包总延时都不变，不同的是对burst，order pacing的影响。两个并行长程需要精确同步时序才能保证order pacing，而两个串行半程则保持半程延时作为pacing且不会out of order。

若要最小化对TCP流的影响，转发节点必须如上述小心同步并行时序以保序，以及用流水线降低长程延时，说好的无状态尽力而为转发，却还是要识别并额外处理TCP单流。无论精确同步并行逻辑还是将同一条TCP流的包hash到同一队列，都意味着要保持某种状态，这显然和IP无状态转发相悖。

端到端的TCP并非不依赖中间网络，而是非常依赖。

网络乱序导致的后果是发送端会误以为丢包从而降速并重传，这会降低带宽利用率。虽然TCP协议栈的实现可以通过reordering度量乱序程度，进而确认是真乱序还是真丢包，但reordering需启发式学习，具有严重滞后性，这个机制的效果并不好。

端到端的事端到端解决。若接收端可重排序，发送端和网络便可不保序传输，保序流是矢量，去掉order分量就成了仅有数量的标量，约束少了，核心网络的带宽利用率将会大大提高。

转发节点所有转发资源全力开动，并行无差别转发每一个数据包，这才是理想的IP转发。

大概六年前我碰到过一起RSS将同一条TCP流的数据包hash到不同CPU造成端到端速率陡降，但pps却相当高的场景，我觉得最终fix方向反了，但控诉无门，悄悄在接收端基于Netfilter做了个重排，效果炸天。

这是一个很讽刺的故事，转发节点无差别hash使所有负载完美均衡到所有CPU，转发吞吐高到难以置信的10Gbps(裸线吞吐13Gbps)，这超高的pps本来正是转发节点要追求的，然而当看到端到端TCP速率从直连的8Gbps降到600Mbps时，工人们第一时间就想到是转发节点hash的问题，修改驱动，问题解决。速率回到了6.4Gbps，软件转发达到这个速率，相当不错了，工人们欢呼雀跃。

但我在思考为什么TCP单流达不到10Gbps，从10Gbps降到6.4Gbps，到底损失了什么。大概几小时的抓包调试，我发现了串行化延时损耗。简单讲就是特定CPU将一个包从入口运输到出口并返回期间，同一流后面的数据包无法被任何CPU处理，即便用流水线缩短了这个长程，问题只是缓解，并未解决。

为什么转发节点去迎合TCP，而不是TCP反过来适应转发节点呢？

性能陡降到600Mbps是因为并行处理同一条流造成了乱序，而TCP对乱序反应过激，于是转发节点不得不迎合TCP去避免乱序，增加了将同一流hash到同一CPU这个逻辑，说实话我认为这是本末倒置了。

换个思路，并行无差别转发，TCP来适应无差别转发，在接收端重排乱序包，即可保持转发节点的极简和效率最优。基于Netfilter完成重排并非难事，但对于不怎么会编程的我，断断续续却花了将近半个月时间，幸运的是结果是好的，乱序转发和接收端重排的端到端速率达到了9.2Gbps，相当棒。

由于修改接收端不可行，这个POC就只能慢慢烂掉，只剩下一个理念，这个理念我后来不断强调，即乱序传输，接收端重排。这个理念可以推广到一切关于并行和串行传输的争论，如果可以重排，仅在接收端同步一次，不要在传输过程中做同步。

最近我又碰到了类似的问题，优化wireguard-go的单流吞吐，如果可以并行传输+接收端重排，单流吞吐提升一倍毫无压力。但重排谁来做，在哪里做呢？理念终究还是理念。

现实是所有的转发节点都在迎合TCP，对同一TCP流进行串行处理以避免乱序，这是一个典型的多队列处理模型，资源平均利用率和利用率方差显然不如单队列，同时，这增加了转发节点实现的复杂性。很遗憾，现实中一而再再而三地以“端不能改，只能改转发节点”为借口在转发节点增加复杂逻辑，网络核心因此变得复杂。

工人们唾手可改的端代码竟然是不能修改不能升级的，负责转发的基础设施却是每天都在变。我曾经对这个现状将计就计，既然只能改转发节点，那就用这个乱序传输技术搭建传输隧道呗，所谓沧浪之水如果清澈，那就喝，沧浪之水要是浑浊，那就洗脚。

TCP再宽容些吧。

TCP的保序传输约束直接影响了路由器交换机的设计和实现，路由器和交换机不得不考虑TCP的保序约束，进而引入复杂性，这既对路由器交换机不好，也对端到端吞吐有损害，路由器交换机变复杂了，资源利用率低了，端到端吞吐也降低了，这并不是一个买卖，因为赔了夫人又折兵却毫无收益，这完全是一场妥协，因为TCP一开始就是那个样子，它成功得太快了，以至于很难通过迭代弥补它的先天问题，以至于所有的转发设备在实现中不得不迎合它。TCP一开始就是要求保序传输，没有办法用简单手段规避这个约束，没办法，转发设备只能满足它。复述一个故事，加点想法。

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