UDP vs TCP，速度快多少？[关闭]

对于一般协议消息交换，可以忍受某些数据包丢失。UDP比TCP效率高多少？

UDP比TCP快，原因很简单，因为它的不存在的确认数据包（ACK）允许连续的数据包流，而不是使用TCP窗口大小和往返时间计算的TCP来确认一组数据包（RTT）。

有关更多信息，我建议简单但很容易理解的Skullbox解释（TCP与UDP）

人们说TCP给您的主要好处是可靠性。但这不是真的。TCP给您的最重要的东西是拥塞控制：您可以在一条DSL链路上以最大速度运行100个TCP连接，而所有100个连接都将“富有成效”，因为它们“感知”了可用带宽。尝试使用100种不同的UDP应用程序，所有应用程序都以最快的速度推送数据包，并查看如何为您解决问题。

从更大的角度来看，这种TCP行为是阻止Internet陷入“拥塞崩溃”的原因。

倾向于将应用程序推向UDP的事情：

• 组传递语义：与TCP的点对点确认相比，可以高效地向一群人进行可靠的传递。

• 无序交付：在许多应用程序中，只要获得所有数据，您就不必关心它按什么顺序到达；您可以通过接受乱序阻止来减少应用程序级延迟。

• 不友好：在局域网上，只要您尽可能快地向网络发布更新，您可能就不会在乎您的Web浏览器是否运行良好。

但是，即使您关心性能，也可能不想使用UDP：

• 您现在已经对可靠性产生了很大的兴趣，而为实现可靠性而可能要做的许多事情最终都会比TCP已经完成的速度慢。

• 现在，您对网络不友好，这可能会在共享环境中引起问题。

• 最重要的是，防火墙将阻止您。

通过将多个TCP连接“中继”在一起，可以潜在地克服某些TCP性能和延迟问题。iSCSI可以避免局域网中的拥塞控制，但是您也可以创建一个低延迟的“紧急”消息通道（TCP的“ URGENT”行为已被破坏）。

在某些应用程序中，TCP比UDP更快（吞吐量更高）。

相对于MTU大小进行大量小写操作时，就是这种情况。例如，我读了一个实验，其中300字节的数据包流通过以太网（1500字节的MTU）发送，而TCP比UDP快50％。

原因是因为TCP将尝试缓冲数据并填充整个网络段，从而更有效地利用可用带宽。

另一方面，UDP将数据包立即放在线路上，从而使许多小数据包充斥网络。

除非您有非常特殊的理由，否则您可能不应该使用UDP。特别是因为您可以通过禁用Nagle算法为TCP提供与UDP相同的延迟（例如，如果您正在传输实时传感器数据，而您不必担心会因大量小数据包而使网络拥塞）。

容忍损失

您是说“具有损失承受能力”吗？

基本上，UDP不“容忍”。您可以向某人发送100个数据包，他们可能只会得到其中的95个数据包，而某些数据包的顺序可能不正确。

对于视频流和多人游戏等事情，错过一个数据包比延迟所有其他数据包要好得多，这是显而易见的选择

但是对于大多数其他情况，丢失或“重新排列”的数据包至关重要。您必须编写一些额外的代码才能在UDP之上运行，以便在丢失任何内容时重试并强制执行正确的顺序。在某些地方这会增加一点点开销。

值得庆幸的是，一些非常聪明的人已经做到了，他们称之为TCP。

这样想：如果一个数据包丢失了，您宁愿尽快获取下一个数据包并继续（使用UDP），还是实际上需要该丢失的数据（使用TCP）。除非您处于实际情况，否则开销不会很重要。

哪种协议（在吞吐量方面）表现更好（UDP或TCP）实际上取决于网络特性和网络流量。例如，Robert S. Barnes指出了TCP性能更好（小写）的情况。现在，考虑一种网络拥塞且同时具有TCP和UDP通信量的情况。网络中使用TCP的发送方将感知“拥塞”并降低其发送速率。但是，UDP没有任何拥塞避免或拥塞控制机制，并且使用UDP的发送方将继续以相同的速率输入数据。逐渐地，TCP发送器会将其发送速率降低到最低限度，如果UDP发送器有足够的数据可以通过网络发送，他们将占用大部分可用带宽。所以在这种情况下 UDP发送者将获得更大的吞吐量，因为它们获得了更大的网络带宽。实际上，这是一个活跃的研究主题-在存在UDP流量的情况下如何提高TCP吞吐量。我知道，使用哪种TCP应用程序可以提高吞吐量的一种方法是打开多个TCP连接。这样，即使每个TCP连接的吞吐量可能受到限制，所有TCP连接的吞吐量的总和仍可能大于使用UDP的应用程序的吞吐量。

当谈到“更快”时，至少有两个非常不同的方面：吞吐量和延迟。

如果说到吞吐量，TCP的流控制（如其他答案中所述）非常重要，并且尽管可以实现与UDP相当的功能，但这绝对是一个大麻烦。结果-当需要吞吐量时使用UDP时，很少有一个好主意（除非您想获得不超过TCP的不公平优势）。

但是，如果说延迟，则整个过程完全不同。在没有数据包丢失的情况下，TCP和UDP的行为极为相似（任何差异（如果有的话，都是微不足道的））-数据包丢失后，整个模式会急剧变化。

在丢失任何数据包之后，TCP将等待至少200ms的重传（RFC6298的2.4段每1sec，但是实际的现代实现往往会将其减少到200ms）。此外，使用TCP，即使那些确实到达目标主机的数据包也不会被传送到您的应用程序，直到接收到丢失的数据包（即，整个通信延迟了约200毫秒）-顺便说一句，这种效应称为Head-of线阻塞是所有可靠的有序流（无论是TCP还是可靠+有序UDP）所固有的。更糟糕的是-如果重新发送的数据包也丢失了，那么我们将谈论大约600ms的延迟（由于所谓的指数退避，第一次重新发送为200ms，第二次重新发送为200 * 2 = 400ms）。如果我们的频道有1％的数据包丢失（按照今天的标准，这还不错），而且我们的游戏每秒更新20次-平均每8分钟就会发生600ms的延迟。600毫秒足以让您在快节奏的游戏中丧命-嗯，这对游戏玩法来说是非常糟糕的。这些效果正是游戏开发人员通常更喜欢UDP而不是TCP的原因。

但是，当使用UDP减少延迟时-重要的是要意识到仅“使用UDP”不足以显着改善延迟，这全都与您使用UDP的方式有关。特别是，尽管RUDP库通常避免“指数退避”并使用较短的重传时间-如果将它们用作“可靠的有序”流，它们仍将遭受行头阻塞（因此如果出现双重阻塞）数据包丢失，而不是600ms，我们将获得约1.5 * 2 * RTT-或对于相当好的80ms RTT，这是〜250ms的延迟，这是一个改进，但仍有可能做得更好。另一方面，如果使用http://gafferongames.com/networked-physics/snapshot-compression/和/或http：// ithare中讨论的技术。 ，则有可能完全消除“线头”障碍（因此，对于每秒更新20次的游戏，如果双包丢失，则无论RTT如何，延迟均为100毫秒）。

另外请注意-如果您碰巧只能访问TCP而不能访问UDP（例如在浏览器中，或者如果您的客户端位于阻止UDP的6-9％的丑陋防火墙之一的后面），则似乎存在一种方法实现UDP-over-TCP而不会产生太多延迟，请参见此处：http : //ithare.com/almost-zero-additional-latency-udp-over-tcp/（确保也阅读注释（！））。

每个TCP连接都需要进行初始握手，然后才能传输数据。另外，TCP头包含许多用于不同信号和消息传递检测的开销。对于消息交换，如果可以接受很小的失败机会，UDP可能就足够了。如果必须验证收货，TCP是您的最佳选择。

@Andrew，我希望有所不同。由于性能要求，UDP是某些应用程序的选择。一个经典的例子是视频会议。这种应用程序不能很好地响应TCP控制。

要考虑的其他方面是您是否需要多播。如果是这样，请使用UDP。

如果您需要在两个甚至还没有通话的IP之间通过网络快速传播消息，那么UDP的到达速度至少要快3倍，通常快5倍。

我只会说清楚。 TCP / UDP是在道路上行驶的两辆汽车。假设交通标志和障碍是错误TCP关心交通标志，尊重周围的一切。行驶缓慢，因为汽车可能会发生故障。尽管UDP只是开走，但全速不考虑路牌。没什么，疯子司机。UDP没有错误恢复，如果有障碍，它将与它发生冲突然后继续。尽管TCP确保所有数据包的发送和接收都完美无误，但没有错误，因此，汽车只是越过障碍物而不会发生碰撞。我希望这是一个很好的例子，您可以理解为什么使用TCP在游戏中首选UDP。游戏需要速度。 可以进行下载，否则下载的文件可能已损坏。

根据我的经验，UDP的速度稍快一些，但速度并不快。选择不应该基于性能，而是取决于消息内容和压缩技术。

如果它是带有消息交换的协议，那么我建议您使用TCP带来的轻微性能损失是值得的。您将获得两个端点之间的连接，这将为您提供所需的一切。除非您对所做的事情非常有信心，否则请不要尝试在UDP之上制造自己的可靠双向协议。

请记住，TCP通常会在线保留多个消息。如果要在UDP中实现此功能，并且要可靠地执行，将会有很多工作。您的解决方案要么可靠性降低，速度降低，要么工作量惊人。有UDP的有效应用程序，但是如果您问这个问题，则可能不是。

已经进行了一些工作，以使程序员能够同时受益于这两个世界。

计划

它是一个独立的传输层协议，但可以用作提供UDP附加层的库。通信的基本单位是一条消息（映射到一个或多个UDP数据包）。内置拥塞控制。协议中有旋钮和旋转键可打开

• 为了传递消息
• 使用用户定义的参数自动重新传输丢失的消息

如果您的特定应用程序需要任何这些。

一个问题是连接建立是一个复杂的过程（因此过程很慢）

其他类似的东西

• https://zh.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

另外一项类似的专有实验项目

• https://zh.wikipedia.org/wiki/QUIC

这也试图改善TCP的三重握手方式，并更改拥塞控制以更好地处理快速线路。

不考虑网络条件而谈论TCP或UDP是没有意义的。如果两点之间的网络具有很高的质量，则UDP绝对比TCP快，但是在其他情况下（例如GPRS网络），TCP可能比UDP更快，可靠性更高。

网络设置对于任何测量都至关重要。如果您是通过本地计算机上的套接字或与世界的另一端进行通信，则将产生巨大的变化。

我想在讨论中添加三点：

1. 在游戏开发的上下文中，您可以在此处找到有关TCP与UDP的很好的文章。
2. 另外，iperf（jperf通过GUI增强了iperf）是一个非常不错的工具，可以通过测量自己回答问题。
3. 我在Python中实现了一个基准测试（请参阅此SO问题）。平均而言，经过10 ^ 6次迭代，UDP的发送8个字节的差异约为1-2微秒。