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

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

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

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

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

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

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的一个很好的例子。

I work on a product that supports both UDP (IP) and TCP/IP communication between client and server. It started out with IPX over 15 years ago with IP support added 13 years ago. We added TCP/IP support 3 or 4 years ago. Wild guess coming up: The UDP to TCP code ratio is probably about 80/20. The product is a database server, so reliability is critical. We have to handle all of the issues imposed by UDP (packet loss, packet doubling, packet order, etc.) already mentioned in other answers. There are rarely any problems, but they do sometimes occur and so must be handled. The benefit to supporting UDP is that we are able to customize it a bit to our own usage and tweak a bit more performance out of it.

Every network is going to be different, but the UDP communication protocol is generally a little bit faster for us. The skeptical reader will rightly question whether we implemented everything correctly. Plus, what can you expect from a guy with a 2 digit rep? Nonetheless, I just now ran a test out of curiosity. The test read 1 million records (select * from sometable). I set the number of records to return with each individual client request to be 1, 10, and then 100 (three test runs with each protocol). The server was only two hops away over a 100Mbit LAN. The numbers seemed to agree with what others have found in the past (UDP is about 5% faster in most situations). The total times in milliseconds were as follows for this particular test:

1记录 IP: 390760 ms TCP: 416,903毫秒 10个记录 IP: 91,707 ms TCP: 95,662毫秒 100条记录 IP: 29,664 ms TCP: 30,968毫秒

IP和TCP传输的数据总量大致相同。我们在UDP通信方面有额外的开销，因为我们拥有一些与TCP/IP“免费”相同的东西(校验和，序列号等)。例如，Wireshark显示对下一组记录的请求在UDP中是80字节，在TCP中是84字节。

关于这个问题，我所知道的最好的答案之一来自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是可以的。在其他情况下，UDP比TCP更可取。

你想要使用UDP而不是TCP的一个独特情况是你在另一个协议(例如隧道，虚拟网络等)上建立TCP隧道。如果您在TCP上建立隧道，则每个TCP的拥塞控制将相互干扰。因此，人们通常更喜欢在UDP(或其他无状态协议)上传输TCP。参见TechRepublic文章:理解TCP Over TCP: TCP隧道对端到端吞吐量和延迟的影响。