为什么我的TCP吞吐量比UDP吞吐量大得多？

我没有对硬件或内核配置（所有默认设置，全新的操作系统安装，Linux内核3.11 TCP / IP堆栈）进行任何异常处理，通过TCP我平均每秒平均发送约383万条消息，而我平均仅为0.75每秒通过UDP的百万条消息。这似乎完全违背了我对这两个协议的期望。

造成这种巨大差异的最可能原因是什么，如何在Ubuntu 13.10上进行诊断？

#TCP RESULTS
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

87380  65536     64    10.00      1963.43   32.96    17.09    5.500   2.852

#UDP RESULTS
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

4194304      64   10.00     7491010      0      383.5     28.97    24.751
212992            10.00     1404941              71.9     25.03    21.381

对于此测试，我有两个相同的测试服务器，它们直接通过10G交叉电缆连接。在这种情况下使用的NIC是具有开箱即用配置的Intel X520，并连接到主板上的PCIe 3.0 x8插槽，该插槽通过NUMA控制器与CPU通信。

除了没有获得有关您的测试设置的详细信息之外，主要问题似乎还在于，您使用的消息大小为64字节。这与通常的1500字节的MTU相距甚远，并且使UDP效率很低：尽管TCP将多个发送合并到网络上的单个数据包（除非设置了TCP_NODELAY）以有效利用链接，但每个UDP消息都会导致一个单独的数据包。以数字表示：大约23条64字节大小的消息将被组合成一个MTU大小的TCP数据包，而对于相同数量的数据，它将需要UDP 23个单个数据包。这些数据包中的每一个都意味着从主机发送，在线传输和对等方接收时的开销。从您的情况可以看出，大约80％的UDP数据包丢失了，因为您的硬件传输和接收所有这些数据包的速度不够快。

因此，您可以从该基准中学到的是：

• UDP不可靠（80％的数据包丢失）
• 如果数据包的大小远低于MTU，则UDP效率不高
• TCP进行了高度优化，以充分利用链接

如您所愿，UDP应该更好：您是否想知道为什么所有主要文件传输（ftp，http，...）都是基于TCP的协议完成的？基准向您显示了原因。

那么，为什么人们完全使用UDP？

• 使用实时数据（例如IP语音），您无需关心较旧的消息，因此您不希望发件人将消息合并为较大的数据包以有效利用链接。您宁愿接受一个数据包丢失也不愿让它到达太迟。
• 对于高延迟链接（如卫星），TCP的默认行为并非最佳选择，无法有效利用链接。因此，在这种情况下，有些人切换到UDP并重新实现TCP的可靠性层并针对高延迟链接对其进行优化，而其他人则对现有的TCP堆栈进行调整以更好地利用该链接。
• “丢弃”数据：有时更重要的是将数据发送出去，而不关心数据包丢失，例如日志消息（syslog）
• 简短的交互：使用TCP，您需要建立一个连接并维护一个状态，这会花费时间和客户端和服务器上的资源。对于短时间的交互（例如短时间的请求和答复），这可能会导致过多的开销。因此，DNS通常是使用UDP完成的，但已在UDP之上建立了重试功能。