Linux TCP并不是全双工的

我说过好几次Linux TCP不是全双工的，没人信，也可能不知道我在说什么，总是有人拿TCP规范来怼我，说TCP就是全双工的，两边可以同时发送数据，显然没get到我的点。

Linux TCP半双工体现在以下方面：

• Linux TCP接收ACK反馈和由此反馈激励发送数据在同一个CPU上，不能同时进行。
• Linux TCP接收数据以及对该数据的即时ACK反馈在同一个CPU上，不同同时进行。
• Linux TCP socket发送数据和接收数据均需要lock socket，不能同时进行。

这下说明白了吗？还不信的话，自己看代码吧。

为什么会产生这样错误的设计呢？我想还是传输派和计算派之间的理念矛盾导致，且计算派占了上风。
传输派认为，能分开就分开，特别是两个方向的处理一定要分开，而计算派的则为了利用局部性，能在一起就在一起。

工人们认为，同一个CPU处理同一条流会更好，大多数工人也说不清到底怎么好，人云亦云cache亲和性，调度开销小，以及一大堆和CPU亲和相关的理由，这让很多人陷入了死局，主动本末倒置。

我举个例子，蒸汽机车和马车的区别在哪？在动力而不在轮子，懂吗？是动力造成了降维打击。工人们青睐cache亲和性，青睐CPU亲和性，无异于极致打磨一个马车轮子，去和携带平庸轮子的蒸汽机车比速度。这回我说清楚了吗？

正是工人们念念不忘不肯妥协的cache/CPU亲和力别了马脚，稍微松弛一下，就海阔天空：让不同的线程在不同的CPU上同时处理收和发。涉及到两个层面：

• TCP内部，不同CPU处理Data和ACK。
• TCP与用户接口，不同CPU处理读和写。

还记得我前天说的人体循环系统吗？按照人体循环系统重新来实现TCP，将会有质的变化：

这涉及到对socket接口的修改，很难，一但实现，性能方面对传统协议栈实现将是降维打击。因此，各类重写的用户态协议栈不妨参考。

Linux TCP的实现并不是全双工的，说了好多遍，没人信我还怼我，我都测出来了还没人信，不得不一直啰嗦，我相信别的TCP实现大概率也不是全双工的，甚至各类转发逻辑的实现都没有考虑这个事情，天天想自然就要天天说。

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