一个二向 TCP 套接字还是两个一向？ （Linux、高容量、低延迟）
我需要在两台机器之间以尽可能低的延迟定期发送（交换）大量数据。网络速度相当快（例如1Gbit甚至2G+）。操作系统是linux。使用 1 个 tcp 套接字（用于发送和接收）还是使用 2 个单向 tcp 套接字更快？
此任务的测试非常类似于 NetPIPE 网络基准测试 - 测量从 2^1 到 2^13 字节大小的延迟和带宽，每个大小至少发送和接收 3 次（在青色任务中，发送次数更大。两者）进程将发送和接收，就像乒乓球一样）。
2 个单向连接的好处来自 Linux：
http://lxr.linux.no/linux+v2.6.18/net/ipv4/tcp_input.c#L3847
3847/*
3848 * TCP receive function for the ESTABLISHED state.
3849 *
3850 * It is split into a fast path and a slow path. The fast path is
3851 * disabled when:
...
3859 * - Data is sent in both directions. Fast path only supports pure senders
3860 * or pure receivers (this means either the sequence number or the ack
3861 * value must stay constant)
...
3863 *
3864 * When these conditions are not satisfied it drops into a standard
3865 * receive procedure patterned after RFC793 to handle all cases.
3866 * The first three cases are guaranteed by proper pred_flags setting,
3867 * the rest is checked inline. Fast processing is turned on in
3868 * tcp_data_queue when everything is OK.
禁用快速路径的所有其他条件均为 false。并且只有非单向套接字会阻止内核在接收中使用快速路径
I need to send (interchange) a high volume of data periodically with the lowest possible latency between 2 machines. The network is rather fast (e.g. 1Gbit or even 2G+). Os is linux. Is it be faster with using 1 tcp socket (for send and recv) or with using 2 uni-directed tcp sockets?
The test for this task is very like NetPIPE network benchmark - measure latency and bandwidth for sizes from 2^1 up to 2^13 bytes, each size sent and received 3 times at least (in teal task the number of sends is greater. both processes will be sending and receiving, like ping-pong maybe).
The benefit of 2 uni-directed connections come from linux:
http://lxr.linux.no/linux+v2.6.18/net/ipv4/tcp_input.c#L3847
3847/*
3848 * TCP receive function for the ESTABLISHED state.
3849 *
3850 * It is split into a fast path and a slow path. The fast path is
3851 * disabled when:
...
3859 * - Data is sent in both directions. Fast path only supports pure senders
3860 * or pure receivers (this means either the sequence number or the ack
3861 * value must stay constant)
...
3863 *
3864 * When these conditions are not satisfied it drops into a standard
3865 * receive procedure patterned after RFC793 to handle all cases.
3866 * The first three cases are guaranteed by proper pred_flags setting,
3867 * the rest is checked inline. Fast processing is turned on in
3868 * tcp_data_queue when everything is OK.
All other conditions for disabling fast path is false. And only not-unidirected socket stops kernel from fastpath in receive
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
变量太多，单个答案无法始终保持在这里。除非您有非常非常快速的网络链接 - 可能>现代硬件上的 1 GBit/秒 - 您链接到的快速路径/慢速路径可能并不重要。
为了以防万一，您可以选择以任何一种方式编写程序。只需存储一个readsocket和一个writesocket，在connect()时，您可以将它们分配为同一个套接字，也可以分配给两个不同的套接字。然后你可以尝试两种方法，看看哪种更快。
您很可能不会注意到两者之间有任何区别。
There are too many variables for a single answer to always hold here. Unless you have a very very fast network link - probably > 1 GBit/sec on modern hardware - the fastpath/slowpath stuff you linked to probably doesn't matter.
Just in case, you can choose to write your program to work either way. Just store a readsocket and a writesocket, and at connect() time, you can either assign them to be the same socket, or two different sockets. Then you can just try it both ways and see which is faster.
It's highly likely you won't notice any difference between the two.
我知道这并不能直接回答您的问题，但我建议您看一下 ZeroMQ 之类的内容。 lwn 上有一篇介绍性文章：0MQ：一种新的消息传递方法。
我还没有尝试过，但我已经阅读了一些，看起来它可能就是你正在寻找的。为什么要重新发明轮子？
I know this doesn't directly answer your question, but I would suggest taking a look at something like ZeroMQ. There is an introductory article about it on lwn: 0MQ: A new approach to messaging.
I haven't gotten to try it out yet, but I've read up on it a bit and it looks like it might be what you're looking for. Why reinvent the wheel?