【问题标题】:tcp or udp for a game server?tcp 或 udp 用于游戏服务器?
【发布时间】:2017-11-28 12:43:26
【问题描述】:

我知道,我知道。这个问题之前已经被问过很多次了。但是我现在花了一个小时在谷歌上搜索,但没有找到我要找的东西,所以我会再次询问并提及我的背景以及让我难以做出决定的原因: 我正在为一个游戏编写服务器,其中响应时间非常重要并且时不时丢包不是问题

从这一点以及我作为服务器主要必须将相同的数据发送到许多不同的客户端这一事实来看,显而易见的答案是 UDP。

当我遇到这个时,我已经开始编写代码了:

在某些应用程序中,TCP 比 UDP 更快(更好的吞吐量)。 相对于 MTU 大小进行大量小写入时就是这种情况。例如,我阅读了一个实验,其中通过以太网(1500 字节 MTU)发送 300 字节数据包流,TCP 比 UDP 快 50%。

在我的情况下,我发送的信息单元小于 100 字节,这意味着每个单元都适合单个 UDP 数据包(这对我来说非常愉快,因为我不必处理碎片)并且 UDP 似乎实现起来要容易得多,因为我不必处理大量的单个连接,但我的首要任务是尽量减少之间的时间

client sends something to server

client receives response from server

因此,如果这是更快的方式,我愿意选择 TCP。 不幸的是,我找不到有关上述案例的更多信息,这就是我问的原因:在我的案例中哪种协议更快?

【问题讨论】:

    标签: sockets tcp udp


    【解决方案1】:

    UDP 仍然会更适合您的用例。

    TCP 和游戏的主要问题是丢包时会发生什么。在 UDP 中,这就是故事的结局;数据包被丢弃,下一个数据包的生活就像以前一样继续。使用 TCP 时,跨 TCP 流的数据传输将停止,直到成功重传丢弃的数据包,这意味着接收方不仅不会按时收到丢弃的数据包,而且后续数据包也会延迟 - 很可能它们都将丢包重发完成后立即突发接收。

    另一个可能对您不利的 TCP 特性是它的自动带宽控制——即 TCP 会将丢弃的数据包解释为网络拥塞的指示,并会回拨其传输速率作为响应;在大量数据包丢失的情况下,可能会将其调低到接近零的程度。如果原因确实是网络拥塞,这可能很有用,但是由于瞬时网络错误(例如,用户拔出以太网电缆几秒钟)也可能发生丢包,您可能不想以这种方式处理这些问题;但是使用 TCP 你别无选择。

    UDP 的一个缺点是通常需要特殊处理才能通过用户的防火墙获取传入的 UDP 数据包,因为默认情况下防火墙通常配置为阻止传入的 UDP 数据包。不过,对于动作游戏来说,dealing with 这个问题可能值得。

    请注意,这不是一个严格的非此即彼的选择;您始终可以编写游戏以通过同时 TCP 和 UDP 运行,或者同时使用它们,或者让程序和/或用户决定使用哪一个。这样一来,如果一种方法效果不佳,您可以简单地使用另一种方法,实施起来只需两倍的努力。 :)

    在某些应用程序中,TCP 比 UDP 更快(更好的吞吐量)。这 相对于 MTU 大小进行大量小写入时就是这种情况。 例如,我读了一个实验,其中一个 300 字节的流 数据包通过以太网(1500 字节 MTU)发送,TCP 为 50% 比 UDP 快。

    如果这对您来说是个问题,您可以通过将多条消息放在一个更大的 UDP 数据包中来在 UDP 协议中获得相同的效率增益。即不是发送 3 个 100 字节的数据包,而是将这 3 个 100 字节的消息放在 1 个 300 字节的数据包中。 (当然,您需要确保接收程序能够正确解释这个较大的数据包)。无论如何,这就是 TCP 层在这里所做的一切;将尽可能多的数据放入传出数据包中,然后再发送出去。

    【讨论】:

    • 谢谢,这个答案很有用!您提到了通过将多个信息单元放入一个数据包中来提高速度的可能性,为什么这样会更有效率?发送一个包含 50 个字节的 UDP 数据包与发送一个包含 500 个字节的数据包花费相同的努力吗?还是仅仅是因为您节省了几个字节,而实际上您只需要 1 个数据包头来处理所有 1 个数据包?
    • 对于 UDP、IP 和以太网数据包头(来源:stackoverflow.com/a/1846139/131930),每个 UDP 数据包有 52 字节的带宽开销,并且每个数据包必须花费一定数量的 CPU 周期在与数据包交互的每个设备上(请参阅:tamos.net/~rhay/overhead/ip-packet-overhead.htm)。不知道这种开销是否会在您的应用程序中引起注意,但绝对不是零。
    猜你喜欢
    • 2018-08-24
    • 1970-01-01
    • 1970-01-01
    • 2021-07-05
    • 1970-01-01
    • 1970-01-01
    • 2017-06-20
    • 1970-01-01
    • 2011-11-09
    相关资源
    最近更新 更多