防止 TCP 连接导致 UDP 丢包 [英] Prevent TCP connections from causing UDP packet loss

问题描述

考虑典型的多人游戏服务器.

Consider the prototypical multiplayer game server.

允许连接到服务器的客户端下载地图和脚本.创建 TCP 连接来完成此操作很简单.

Clients connecting to the server are allowed to download maps and scripts. It is straightforward to create a TCP connection to accomplish this.

但是，服务器必须继续通过 UDP 响应其余客户端.如果允许 TCP 下载连接使可用带宽饱和，则 UDP 流量将严重遭受丢包的影响.

However, the server must continue to be responsive to the rest of the clients via UDP. If TCP download connections are allowed to saturate available bandwidth, UDP traffic will suffer severely from packet loss.

处理此问题的最佳方法可能是什么?通过跟踪时间和 send() 在固定的时间间隔以某种方式限制" TCP 上传连接绝对是一个好主意.这样，如果 UDP 数据包丢失开始更频繁地发生，则 TCP 连接可能会受到进一步限制.操作系统是否仍倾向于将数据捆绑在一起而不是稳定地发送出去?我希望多久调用一次send()?我想这样做太频繁会导致数据被缓冲在一起，首先使该方法无效，并且太不频繁地这样做会导致带宽不足(并且使用效率低下).对于每次 发送 的数据量，也存在类似的考虑.

What might be the best way to deal with this issue? It definitely seems like a good idea to "throttle" the TCP upload connection somehow by keeping track of time, and send() on a regular time interval. This way, if UDP packet loss starts to occur more frequently the TCP connections may be throttled further. Will the OS tend to still bunch the data together rather than sending it off in a steady stream? How often would I want to be calling send()? I imagine doing it too often would cause the data to be buffered together first rendering the method ineffective, and doing it too infrequently would provide insufficient (and inefficient use of) bandwidth. Similar considerations exist with regard to how much data to send each time.

推荐答案

这听起来很像你以错误的方式解决问题:

It sounds a lot like you're solving a problem the wrong way:

1. 如果您担心丢失 UDP 数据包，您应该考虑不使用 UDP.
2. 如果您担心在两个函数之间共享带宽，您应该考虑为它们设置单独的管道(带宽).
3. 流量整形(听起来就是这样)通常在操作系统中解决.在对您的应用程序进行奇怪的更改之前，您应该朝那个方向看.
4. 如果您还没有让应用程序运行并遇到此问题，那么您可能过早地进行了优化.

这篇关于防止 TCP 连接导致 UDP 丢包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！