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

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

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

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

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

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

UDP确实有更少的开销，适合做一些事情，比如流式实时数据，如音频或视频，或者在任何情况下，如果数据丢失是ok的。

UDP具有较低的开销，如前所述，它对视频和音频等流媒体很好，最好只是丢失一个数据包，然后尝试重新发送和追赶。

TCP传输没有保证，你只是被告知套接字是否断开，或者数据是否没有到达。否则它会在到达目的地的时候到达目的地。

A big thing that people forget is that udp is packet based, and tcp is bytestream based, there is no guarantee that the "tcp packet" you sent is the packet that shows up on the other end, it can be dissected into as many packets as the routers and stacks desire. So your software has the additional overhead of parsing bytes back into usable chunks of data, that can take a fair amount of overhead. UDP can be out of order so you have to number your packets or use some other mechanism to re-order them if you care to do so. But if you get that udp packet it arrives with all the same bytes in the same order as it left, no changes. So the term udp packet makes sense but tcp packet doesnt necessarily. TCP has its own re-try and ordering mechanism that is hidden from your application, you can re-invent that with UDP to tailor it to your needs.

UDP更容易在两端编写代码，基本上是因为你不需要建立和维护点到点连接。我的问题是在什么情况下你需要TCP开销?如果你走捷径，比如假设接收到的tcp“数据包”是发送的完整数据包，你会更好吗?(如果你费心检查长度/内容，你可能会扔掉两个包)