UDP数据传输比TCP慢

Question

我目前正在 C#/.Net4 中编写一个原型应用程序，我需要传输未知量的数据。数据从文本文件中读入，然后序列化为字节数组。 现在我需要实现两种传输方法：UDP 和 TCP。两种方式的传输都工作正常，但我在 UDP 方面遇到了一些困难。我假设使用 UDP 的传输必须比使用 TCP 快得多，但实际上我的测试证明 UDP 传输比使用 TCP 慢大约 7 到 8 倍。 我用12兆字节的文件测试了传输，TCP传输大约需要1秒，而UDP传输大约需要7秒。 在应用程序中，我使用简单的套接字来传输数据。由于 UDP 只允许每条消息最大为 65535kb，因此我将文件的序列化字节数组分成几个部分，其中每个部分都有 socker SendBufferSize 的大小，然后使用 Socket.Send() 方法调用传输每个部分。

这是发送者部分的代码。

while (startOffset < data.Length)
{
    if ((startOffset + payloadSize) > data.Length)
    {
        payloadSize = data.Length - startOffset;
    }
    byte[] subMessageBytes = new byte[payloadSize + 16];
    byte[] messagePrefix = new UdpMessagePrefix(data.Length, payloadSize, messageCount, messageId).ToByteArray();
    Buffer.BlockCopy(messagePrefix, 0, subMessageBytes, 0, 16);
    Buffer.BlockCopy(data, startOffset, subMessageBytes, messageOffset, payloadSize);
    messageId++;
    startOffset += payloadSize;
    udpClient.Send(subMessageBytes, subMessageBytes.Length);
    messages.Add(subMessageBytes);
}

此代码只是将要发送的下一部分复制到字节数组中，然后调用套接字上的 send 方法。我的第一个猜测是，字节数组的分割/复制会降低性能，但我隔离并测试了分割代码，分割只花了几毫秒，所以这不会导致问题。

int receivedMessageCount = 1;
Dictionary<int, byte[]> receivedMessages = new Dictionary<int, byte[]>();
while (receivedMessageCount != totalMessageCount)
{
    byte[] data = udpClient.Receive(ref remoteIpEndPoint);
    UdpMessagePrefix p = UdpMessagePrefix.FromByteArray(data);
    receivedMessages.Add(p.MessageId, data);
    //Console.WriteLine("Received packet: " + receivedMessageCount + " (ID: " + p.MessageId + ")");
    receivedMessageCount++;
    //Console.WriteLine("ReceivedMessageCount: " + receivedMessageCount);
}
Console.WriteLine("Done...");
return receivedMessages;

这是我接收 UDP 消息的服务器端代码。每条消息都有一些字节作为前缀，其中存储消息总数和大小。所以我只是循环调用 socket.Receive ，直到收到前缀中指定的消息量。

我在这里的假设是，我可能实现的 UDP 传输代码不够“高效”...也许你们中的一个人已经在代码片段中发现了问题，或者对我有任何其他建议或提示，为什么我的 UDP 传输比TCP。

提前致谢！

Answer 1

虽然 UDP 数据报大小可达 64K，但实际线帧通常为 1500 字节（普通以太网 MTU）。它还必须适合至少 20 字节的 IP 标头和 8 字节的 UDP 标头，从而为您留下 1472 字节的可用负载。

您所看到的是操作系统网络堆栈碎片的结果在发送方发送 UDP 数据报，然后在接收方重新组装它们。这需要时间，因此也需要你的结果。

另一方面，TCP 会进行自己的打包并尝试查找 路径 MTU，因此它更在这种情况下是有效的。

将数据块限制为 1472 字节并再次测量。

Answer 2

我认为你应该测量测试期间的 CPU 使用率和网络吞吐量。

如果 CPU 被固定，这就是您的问题：打开分析器。

如果网络（电缆）被固定，则这是另一类问题。我不知道该怎么办；-)

如果两者都没有固定，请运行分析器并查看大部分挂钟时间都花在哪里。一定还有一些等待。

如果您没有分析器，只需在调试器中按 10 次中断，然后查看最常停止的位置。

编辑：我对您的测量的回应：我们知道 99% 的执行时间都花在接收数据上。但我们还不知道 CPU 是否繁忙。查看任务管理器并查看哪个进程正忙。

我的猜测是它是系统进程。这是 Windows 内核，也可能是其中的 UDP 组件。

这可能与数据包碎片有关。 IP 数据包有一定的最大大小，例如 1472 字节。您的 UDP 数据包正在接收机器上被分段并重新组装。我很惊讶它占用了如此多的 CPU 时间。

尝试发送总大小为 1000 和 1472 的数据包（两者都尝试！）并报告结果。