具有多线程的 TCP 与用于游戏服务器的 UDP

Question

我一直在阅读（出于好奇）有关游戏服务器的大量信息。对于快节奏的游戏（第一人称射击游戏），UDP 似乎是必须的。

根据我收集到的信息，归结为当数据包丢失时会发生什么。当 TCP 尝试重新发送/接收丢失的数据包时，您将获得巨大的延迟，并且此时游戏的状态已经远远领先于客户端，使得您等待了这么久的数据包在它到达时毫无用处。

如果您禁用 Nagle 的算法，我很难弄清楚为什么这样的东西不起作用，而不是处理 UDP 数据包：

你打开了多个到服务器的连接

client thread 1 <- packet 1
client thread 2 <- packet 2
client thread 3 <- packet 3
client thread 4 <- packet 4
client thread 5 <- packet 5

那么，如果数据包 1 发生问题并且您在 500 毫秒后收到它，那么到那时您将拥有数据包 2，所以没关系，客户端可以丢弃它。我确定我错过了一些关键信息，但我找不到任何相关信息。使用 Zeromq 或其他消息传递库实现类似我提议的内容非常简单。

Answer 1

所提出的技术会有所帮助（顺便说一句，它实际上并不需要多个线程，只需要多个 TCP 连接），但它确实假设导致数据包丢失的任何东西只会影响某些 TCP 连接的数据包，而不是他们都是。这可能不是一个非常可靠的假设——因为所有 TCP 连接（可能）都通过相同的网络路径，任何导致 TCP 流 A 丢弃数据包的故障条件（或带宽短缺）都可能导致流 B 通过E 也丢弃数据包——然后你又回到原来的问题了。

激活多个 TCP 流确实允许您解决单个 TCP 流的严格排序要求（即，如果您知道数据流 B 中的更新在逻辑上独立于数据流 A 中的更新，那么为什么强制新的 B 更新始终等到所有先前发送的 A 更新都已成功传输？）。不过，我怀疑您仍然会发现 UDP 效果更好的情况。混合方法（使用 UDP 处理低延迟数据，同时使用 TCP 流处理延迟更大或更复杂的数据）可能会产生更好的结果。