用于大量连接的 TCP 或 UDP？答案

【问题标题】：TCP or UDP for lots of connections?用于大量连接的 TCP 或 UDP？
【发布时间】：2016-06-02 07:19:15
【问题描述】：

我想创建一个具有以下特点的 P2P 网络：

低延迟并不重要
丢包没关系
节点只会发送少量数据
不会有 NAT/防火墙问题，每个节点的公共 ip 上都有一个开放端口
每个节点都连接到其他每个节点

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

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

【问题讨论】：

这不是一个真正的编程问题。这是一个架构设计问题，也可能是一个网络问题。它可能是关于程序员或其他地方的主题，但就目前而言，它不在我们帮助中心定义的范围内。
建议查看TCP vs UDP 进行比较。将其与您的特征列表进行比较并做出选择。 UDP 很可能是最合适的选择。

标签： sockets networking tcp udp p2p

【解决方案1】：

如果我没记错的话，使用 TCP 连接到 1000 个服务器意味着我必须使用 1000 个端口来处理这些连接。

你记错了。
以一个监听 80 端口的 Web 服务器为例，它可以在这个端口上同时处理 1000 个连接。这是因为连接是由{client-ip,client-port,server-ip,server-port} 的元组定义的。虽然 server-ip 和 server-port 对于到该服务器的所有连接都是相同的，但 client-ip 和 client-port 却不是。即使客户端 IP 相同（即相同的客户端），客户端也会选择不同的源端口。

... 例如1000 个节点而不调整系统？

这取决于系统，因为每个打开的连接都需要保存状态，因此需要内存。对于内存很少的嵌入式系统，这可能是个问题。

在任何情况下：如果您的协议只是发送小消息并且如果数据包丢失、重新排序或复制是可以接受的，那么 UDP 可能是更好的选择，因为开销（连接设置、ACK..）更小并且占用的内存更少.您还可以使用单个套接字与所有 1000 个节点交换数据，而使用 TCP 您需要为每个连接使用单独的套接字（套接字与端口不同！）。仅使用单个套接字可能会简化应用程序设计。

【讨论】：

TCP 仍有可能发生“端口耗尽”。如果您有一个侦听套接字，那么理论上每个远程 IP 限制为 65535。它通常远低于此值，Windows 过去的设置将其限制为 ~5000。结合操作系统部分糟糕的 TIME_WAIT 处理，您很容易发现自己的端口在特定远程 IP 上耗尽。我已经在单个后端的高吞吐量前端看到了这一点。但是，对于问题中的 P2P 应用程序来说，这应该不是问题。

【解决方案2】：

我想对 Steffen 的回答修改几点：

1000 个连接对于任何普通的计算机和操作系统来说都不算什么。
UDP 符合您的要求。它可能更容易编程，因为它是面向消息的。 TCP 提供字节流。您需要在不那么容易的基础上添加一个消息传递协议。此外，您需要通过重新连接来处理断开的 TCP 连接。
端口并不稀缺。消耗 1000 个端口没问题。

【讨论】：

【解决方案3】：

使用 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 秒内收到了一个 ping，则该节点仍然处于活动状态。 TCP 实现这一点会涉及更多的延迟和带宽，因为它确保每个 ping 消息都能通过，并会阻止任何其他数据出去，直到它通过。而且由于您无法依靠 TCP 可靠地告诉您连接是否已断开，因此您不得不为 TCP 添加类似的 PING 功能，此外 TCP 已经对您的数据包做了额外的处理。

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

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

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

【讨论】：