我说过好几次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实现大概率也不是全双工的,甚至各类转发逻辑的实现都没有考虑这个事情,天天想自然就要天天说。
浙江温州皮鞋湿,下雨进水不会胖。