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

解决方案

回答

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

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

回答

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

回答

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

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

回答

请记住，TCP通常会在网上保留多个消息。如果要在UDP中实现此目标，并且要可靠地进行，将会有很多工作。解决方案或者可靠性降低，速度降低，或者工作量惊人。有UDP的有效应用程序，但是如果我们问这个问题，答案可能不是。

回答

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

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

回答

with loss tolerant

我们是说"具有损失承受能力"吗？

基本上，UDP不是"容错"的。我们可以将100个数据包发送给某人，他们可能只会得到其中的95个数据包，而某些数据包的顺序可能不正确。

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

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

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

这样考虑：如果一个数据包丢失了，我们宁愿尽快获取下一个数据包并继续(使用UDP)，还是实际上需要该丢失的数据(使用TCP)。除非我们处于真正的极端情况下，否则开销不会很重要。

回答

人们说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相同类型的延迟(例如，如果我们正在传输实时传感器数据，而我们不必担心会因大量小数据包而使网络拥塞)。