比较TCP和UDP，像UDP这样的无连接协议可以保证速度，但不能保证数据包传输的可靠性。 例如，电子游戏通常不需要可靠的网络，但速度是最重要的，在游戏中使用UDP具有减少网络延迟的优势。

UDP是一种无连接协议，用于SNMP和DNS等协议，在这些协议中，无序到达的数据包是可以接受的，数据包的即时传输很重要。

在SNMP中使用它是因为网络管理通常必须在网络处于压力状态时进行，即当可靠的、拥塞控制的数据传输难以实现时。

它用于DNS，因为它不涉及连接建立，从而避免了连接建立延迟。

干杯

UDP can be used when an app cares more about "real-time" data instead of exact data replication. For example, VOIP can use UDP and the app will worry about re-ordering packets, but in the end VOIP doesn't need every single packet, but more importantly needs a continuous flow of many of them. Maybe you here a "glitch" in the voice quality, but the main purpose is that you get the message and not that it is recreated perfectly on the other side. UDP is also used in situations where the expense of creating a connection and syncing with TCP outweighs the payload. DNS queries are a perfect example. One packet out, one packet back, per query. If using TCP this would be much more intensive. If you dont' get the DNS response back, you just retry.

关键的问题是“在什么情况下UDP是更好的选择[而不是tcp]”

上面有很多很好的答案，但是缺少的是对传输不确定性对TCP性能影响的正式、客观的评估。

随着移动应用程序的大量增长，以及“偶尔连接”或“偶尔断开”的范式，在很难获得连接的情况下，TCP试图维持连接的开销肯定会导致UDP及其“面向消息”的性质的强烈情况。

现在我没有数学/研究/数字，但我制作的应用程序使用ACK/NAK和UDP上的消息编号比使用TCP更可靠，当时连接通常很差，可怜的旧TCP只是花费了时间和客户的金钱来尝试连接。在许多西方国家的地区和农村地区都有这种情况....

我们知道UDP是一种无连接协议，的确如此

适用于需要简单请求-响应通信的流程。 适用于有内部流动、误差控制的工艺 适用于广泛铸造和多播

具体的例子:

用于SNMP 用于RIP等路由更新协议

当TCP可以工作时，我有点不情愿建议使用UDP。问题是，如果TCP由于某种原因不能工作，因为连接太延迟或拥塞，将应用程序更改为使用UDP不太可能有帮助。一个坏的连接对UDP也不好。TCP在减少拥塞方面已经做得很好了。

我能想到的唯一需要UDP的情况是广播协议。在应用程序涉及两个已知主机的情况下，UDP可能只会提供边际的性能优势，而代码复杂性的成本则会大幅增加。