tcp or udp，另一个比较

Question

考虑一个每秒有数千个请求的缓存应用程序，其中客户端使用整数索引请求对象，服务器将对象发送回给它。 （仅限 Linux）

对于 UDP 协议来说，什么会更快：

• 在一个数据包中发送多个回复？
• 在一个数据包中发送一个回复？

（适用于双方，服务器或客户端）

缺点：

• 每个数据包有多个回复：

  • 将需要许多 memcpy() 来组装具有多个回复的数据包。如果 get() 请求向客户端返回 16 字节对象，则在发出 sendto() 系统调用之前，一个 65535 字节的单个数据包必须 memcpy() 大约 4000 个对象。 memcpy() 开销很大
  • 一个 65000 字节的 UDP 包会产生大约 43 个 udp 包头 因为数据包将在 Fragmetns 中传输，因为默认 MTU 大小为 1500。 开销不大
• 每个数据包单个回复：
  • 每个 get() 都会产生 28 字节的协议开销。对于 16 字节的对象，这将是昂贵的。每秒对象的吞吐量将很低，网络将被数据包饱和。例如，发送 4000 个对象将生成 4000 个 udp 数据包标头，比具有多个回复的 43 个标头要多得多。
  • 此外，过多的 sendto() 系统调用会增加 CPU 消耗，因为内核必须在每个系统调用上保存 CPU 寄存器。

似乎这两种方法都有其缺点，尚不清楚哪种解决方案会更好，但是，千兆以太网的时钟运行在 1GHz，而处理器是例如 3GHz，内存也是 总线比以太网接口的双绞线宽得多。所以多回复 每个数据包会是更好的选择，因为额外的 memcpy() 会减少网络流量，对吗？

现在，如果我们使用 TCP 而不是 UDP：

• 每个数据包有多个回复：
  • 再次，将需要许多 memcpy() 来组装数据包，该数据包不应大于 65535，然后内核会将其分段以 MTU 大小的数据包发送它与这里有 UDP
• 每个数据包单个回复：
  • 由于我们的 16 字节对象随机分布在服务器的内存中，我们必须为每个对象发出一个 write() 系统调用，系统调用的数量与 udp 的单个请求情况相同。
  • 每个 get() 都会导致 52 字节的开销，因为 TCP 具有更大的标头 + 我们将不得不另外一个大约 40 字节的 ACK 数据包开销。 更大的网络流量

结论：

1. 对于这个特定的应用程序（从客户端给定的索引向客户端发送简单的数据块）TCP 的性能不会比 UDP 更好。 + 考虑到 TCP 栈的实现比 UDP 复杂得多，在那里执行的指令更多。 使协议运行得更快的关键在于将 UDP 数据包组装到 MTU 中尽可能大。
2. 向系统添加另一个 NIC 的成本低于添加另一个 CPU。减少 memcpy() 的数量是有意义的，但发送一堆小的 UDP 数据包并为网络端每个 udp 标头的开销支付额外费用（+ 通过执行许多 sendto() 系统调用来增加一些开销我认为会低于 memcpy() 的开销）因为这种方式使用一个 CPU 可以通过多个 NIC 发送请求

非常感谢您的 cmets 和您在协议选择方面的经验。

注意： 让我们抛开可靠性问题，假设我们的网络没有错误，即 如果您正确连接它们，大多数情况下都是正确的，如果发生错误，那肯定不是常态

Answer 1

这里有几处说法不准确，稍作改动：

1. 多个对象不需要多个 write() 系统调用，您可以使用 writev() 来满足这个确切的需要。 （适用于 UDP 和 TCP）

2. 使用 UDP 发送 65K 字节缓冲区不会创建多个 UDP 标头，只会创建多个带有单个 UDP 标头的 IP 标头。此外，对于今天的 1Gbit NIC/s，如果这是用于专用网络，您可以使用 jambo 帧并增加 MTU（超过 1500）。

1234563流，它没有 UDP 的数据包边界。

3. 你不能假设可靠性、顺序和负载，在我看来，这使得 UDP 更难管理。当服务器或客户端的流量开始过载时，TCP 将处理连接。使用 UDP，您必须检测此类情况并做出反应。