sockets - 大量连接使用 TCP 还是 UDP？

Question

我想创建一个具有以下特征的P2P网络:

低延迟并不重要

丢包裹没关系

节点只会在

附近发送少量数据

不会有 NAT/防火墙问题，每个节点的公共(public) ip 上都有一个开放端口

每个节点都连接到每个其他节点

通常我会将 TCP 用于任何对时间不敏感的事情，但最后一个要求会导致节点长时间拥有大量打开的连接。如果我没记错的话，使用 TCP 连接到 1000 个服务器意味着我必须使用 1000 个端口来处理这些连接。另一方面，UDP 只需要每个节点一个端口。

所以我的问题是:TCP 是否能够在网络中处理上述要求，例如1000 个节点而不调整系统？在这种情况下，UDP 会更适合吗？还有什么会破坏这两种协议(protocol)的交易吗？

Answer 1

使用 UDP，您可以控制“连接状态”，如果您有大量节点或关心带宽、内存和 CPU 开销，它几乎是执行任何点对点相关的最佳方式。通过将关于每个节点的“连接状态”的所有控制权转移到您的应用程序，您可以通过使其完全满足您的需求来最大限度地减少浪费的资源量。

您将绕过许多操作系统特定的怪癖，这些怪癖会限制 TCP 在大量连接时的有效性。有 TIME_WAIT 膨胀和数十到数百个操作系统特定设置，如果需要这些高数字，则需要针对 P2P 应用程序的每个用户进行调整。我制作的一个测试应用程序允许您将 UDP 与 ack 或 TCP 一起使用，而不管使用 UDP 的操作系统如何，性能差异都只有 10%。 TCP 性能总是低于最好的 UDP，并且它的性能因操作系统而异，变化幅度超过 600%。通过调整，您可以使用 TCP 使大多数操作系统的性能大致相同，但默认情况下，大多数操作系统都没有正确调整。

所以在我看来，与 TCP 相比，建立可靠的 UDP P2P 网络更难，但它经常被需要。但是，如果您对网络非常有经验，我只会建议您使用它，因为有很多“问题”需要处理。有一些库可以帮助解决这个问题，比如 Raknet 或 Enet。它们提供了实现可靠 UDP 的方法，但仍然需要更多的网络知识才能知道这一切是如何联系在一起的，而对于 TCP，它大多对您隐藏。

在对等网络中，您经常会收到诸如节点 PING 之类的消息，您可能不关心是否总是收到每个消息，您只关心最近是否收到了一条消息。即您可以每 10 秒发送一次 ping，并在 60 秒没有 ping 后断开节点。这意味着您需要连续 6 个 ping 数据包失败，除非节点真的关闭，否则这是极不可能的。如果您在 60 秒内收到 1 个 ping，则该节点仍处于事件状态。对此的 TCP 实现将涉及更多的延迟和带宽，因为它确保每个 ping 消息都能通过，并会阻止任何其他数据发出，直到它通过为止。并且由于您不能依靠 TCP 来可靠地告诉您连接是否已死，因此您不得不为 TCP 添加类似的 PING 功能，此外 TCP 已经对您的数据包做了额外的处理。

游戏也经常有数据，如果它没有被客户端接收到也没什么大不了的，因为在几毫秒内有更多的数据包进入，这将使任何丢失的数据包无效。即玩家在 1 秒的时间跨度内从 A 移动到 Z，他的客户端发送每个数据包，大约相隔 40 毫秒 ABCDEFG__I__KLMNOPQRSTUVWXYZ 我们真的关心我们是否因为每 40 毫秒接收一次更新而错过“H 和 J”？并非如此，这是可以进行预测的地方，但这通常与大多数 P2P 项目无关。如果那是 TCP 而不是 UDP，那么它会增加带宽要求并增加正在接收的其余数据包的延迟，因为数据将重新发送直到它到达，除了它已经通过确认所有内容而增加的额外延迟之外。

本质上，您可以使用 UDP 降低对等网络中许多消息的延迟和网络开销。然而，总会有一些消息需要可靠地发送，这需要您基本上实现一些可靠的方法来将数据包发送到该节点，类似于 TCP 的方法。如果您想要一个可靠的对等网络，这就是您需要一定程度的专业知识的地方。需要考虑的一些事项包括使用数字、消息 ACK 等对数据包进行排序。

如果您非常关心效率或确实需要数万个连接，那么在 UDP 中实现您的特定协议(protocol)总是比 TCP 更好。但是对于 TCP 也有一些案例，比如项目的时间是否很重要，或者您是否是网络编程的新手。