UDP的“不可靠性”是一种形式主义。传播并不能绝对保证。实际上，他们几乎总是能通过。它们只是在暂停后不被确认和重试。

协商TCP套接字和握手TCP数据包的开销是巨大的。真的很大。没有明显的UDP开销。

最重要的是，您可以轻松地用一些可靠的传输握手来补充UDP，开销比TCP要少。读这个:http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP对于在发布-订阅类型的应用程序中广播信息非常有用。IIRC, TIBCO大量使用UDP来通知状态变化。

任何其他类型的单向“重要事件”或“日志记录”活动都可以用UDP包很好地处理。您希望在不构造整个套接字的情况下发送通知。你不期望从不同的听众那里得到任何回应。

系统“心跳”或“我还活着”消息也是一个不错的选择。错过一个不是危机。(连续)少了半打就是。

UDP的“不可靠性”是一种形式主义。传播并不能绝对保证。实际上，他们几乎总是能通过。它们只是在暂停后不被确认和重试。

协商TCP套接字和握手TCP数据包的开销是巨大的。真的很大。没有明显的UDP开销。

最重要的是，您可以轻松地用一些可靠的传输握手来补充UDP，开销比TCP要少。读这个:http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP对于在发布-订阅类型的应用程序中广播信息非常有用。IIRC, TIBCO大量使用UDP来通知状态变化。

任何其他类型的单向“重要事件”或“日志记录”活动都可以用UDP包很好地处理。您希望在不构造整个套接字的情况下发送通知。你不期望从不同的听众那里得到任何回应。

系统“心跳”或“我还活着”消息也是一个不错的选择。错过一个不是危机。(连续)少了半打就是。

在某些情况下，如果丢失一些数据不会完全破坏正在传输的数据，则应该使用UDP而不是TCP。它的很多应用都是在实时应用中，比如游戏(例如FPS，你不需要知道每个玩家在特定时间的位置，如果你丢失了一些数据包，新的数据会正确地告诉你玩家在哪里)，以及实时视频流(一个损坏的帧不会破坏观看体验)。

关于这个问题，我所知道的最好的答案之一来自Hacker News的用户zAy0LfpBZLC8mAC。这个答案太好了，我就原原本本地引用它吧。

TCP has head-of-queue blocking, as it guarantees complete and in-order delivery, so when a packet gets lost in transit, it has to wait for a retransmit of the missing packet, whereas UDP delivers packets to the application as they arrive, including duplicates and without any guarantee that a packet arrives at all or which order they arrive (it really is essentially IP with port numbers and an (optional) payload checksum added), but that is fine for telephony, for example, where it usually simply doesn't matter when a few milliseconds of audio are missing, but delay is very annoying, so you don't bother with retransmits, you just drop any duplicates, sort reordered packets into the right order for a few hundred milliseconds of jitter buffer, and if packets don't show up in time or at all, they are simply skipped, possible interpolated where supported by the codec. Also, a major part of TCP is flow control, to make sure you get as much througput as possible, but without overloading the network (which is kinda redundant, as an overloaded network will drop your packets, which means you'd have to do retransmits, which hurts throughput), UDP doesn't have any of that - which makes sense for applications like telephony, as telephony with a given codec needs a certain amount of bandwidth, you can not "slow it down", and additional bandwidth also doesn't make the call go faster. In addition to realtime/low latency applications, UDP makes sense for really small transactions, such as DNS lookups, simply because it doesn't have the TCP connection establishment and teardown overhead, both in terms of latency and in terms of bandwidth use. If your request is smaller than a typical MTU and the repsonse probably is, too, you can be done in one roundtrip, with no need to keep any state at the server, and flow control als ordering and all that probably isn't particularly useful for such uses either. And then, you can use UDP to build your own TCP replacements, of course, but it's probably not a good idea without some deep understanding of network dynamics, modern TCP algorithms are pretty sophisticated. Also, I guess it should be mentioned that there is more than UDP and TCP, such as SCTP and DCCP. The only problem currently is that the (IPv4) internet is full of NAT gateways which make it impossible to use protocols other than UDP and TCP in end-user applications.

UDP是完美的VoIP地址，其中数据包必须发送不考虑其可靠性… 视频聊天是UDP的一个例子(你可以在任何视频聊天期间通过wireshark网络捕获来检查它)。 而且TCP不能与DNS和SNMP协议一起使用。 UDP没有任何开销，而TCP有很多开销

这是我最喜欢的问题之一。UDP被误解了。

当你真的想快速地向另一个服务器得到一个简单的答案时，UDP是最好的选择。通常，您希望答案在一个响应包中，并准备实现自己的协议以提高可靠性或重新发送。DNS是这个用例的完美描述。连接设置的成本太高了(然而，DNS 不支持TCP模式以及)。

另一种情况是，当您交付的数据可能会丢失，因为新的数据将取代之前的数据/状态。天气数据、视频流、股票报价服务(不用于实际交易)或游戏数据浮现在脑海中。

另一种情况是，当您正在管理大量的状态时，您希望避免使用TCP，因为操作系统无法处理那么多会话。这在今天是一个罕见的案例。事实上，现在可以使用用户专用的TCP堆栈，以便应用程序编写人员可以对该TCP状态所需的资源进行更细粒度的控制。在2003年之前，UDP是唯一的游戏。

另一种情况是多播流量。UDP可以多播到多个主机，而TCP根本不能这样做。