您能否在受控网络内优化/配置 TCP，使其变得与 UDP 一样快？
我正在考虑编写自己的可靠 UDP 实现（数据包排序和丢包重传）。这是针对我的受控网络内的内部系统。我想知道在Linux系统上是否有可能对TCP进行如此多的优化，使其变得和UDP一样快？如果是的话，我将只使用超级优化的 TCP，而不用担心实现可靠的 UDP。
I am considering writing my own implementation of reliable UDP (packet ordering and retransmission for packet drops). This is for internal systems inside my controlled network. I wonder if it is possible on a Linux system to optimize TCP so much that it becomes as fast as UDP? If it is I will just use super-optimized TCP and not worry about implementing reliable UDP.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以采取一些措施来使 TCP 适应您的特定需求。您可以增加最大缓冲区大小、更改拥塞算法等等。我认为在重新发明轮子之前确实值得尝试，特别是因为您似乎对内部网络有很好的控制。 本文描述了其中一些内容。有关所有这些参数的另一个很好的信息来源是 Linux 源代码中的
Documentation/networking/ip-sysctl.txt。您还可以通过查看
/proc/sys/net/ipv4/tcp_sack来检查 Linux 上是否启用了 TCP 选择性确认 (SACK)。There are a few things that you can do to adapt TCP to your specific needs. You can increase the maximum buffer size, change the congestion algorithm and much more. I think it's really worth trying before re-inventing the wheel, especially since you seem to have a good control over your internal network. This article describe a few of those things. Another good source of information for all those parameters is
Documentation/networking/ip-sysctl.txtin your Linux source code.You can also check that the TCP Selective Acknowledgement (SACK) is enabled on your Linux by looking at
/proc/sys/net/ipv4/tcp_sack.性能有不同的衡量标准（吞吐量、延迟、抖动、丢包鲁棒性）。
如果不引入任意延迟，您就无法获得数据包交付和订购保证。从这个意义上说，可靠的 UDP 不可能比 TCP“更快”。
可以使用 FEC 来减少重传次数，但会增加带宽。不过，这只会提高有损链路上的吞吐量。它将减少链路上任何丢包的抖动和最大延迟。
或者你在谈论 TCP 公平性与 UDP 贪婪性？
无论如何，您的操作系统 TCP 层已经非常高度优化，如果不改变游戏规则（例如牺牲公平性），您不太可能做得更好。
There are different measures of performance (throughput, latency, jitter, robustness to packet drop).
You can't get packet delivery and ordering guarantees without introducing arbitrary delay. In that sense, reliable UDP cannot be "faster" than TCP.
It's possible to use FEC to reduce the number of retransmits, at the expense of additional bandwidth. That would only improve throughput over a very lossy link though. It will reduce jitter and maximum latency over a link with any drops.
Or are you talking about TCP fairness vs UDP greediness?
In any case, your OS TCP layer is already very highly optimized, it's unlikely you can do better without changing the rules of the game (e.g. sacrificing fairness).