电子游戏的网络通信几乎都是通过UDP完成的。

速度是最重要的，如果错过更新也无关紧要，因为每次更新都包含玩家所能看到的完整当前状态。

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

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

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

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

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

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

具体的例子:

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

关于这个问题，我所知道的最好的答案之一来自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 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。它的很多应用都是在实时应用中，比如游戏(例如FPS，你不需要知道每个玩家在特定时间的位置，如果你丢失了一些数据包，新的数据会正确地告诉你玩家在哪里)，以及实时视频流(一个损坏的帧不会破坏观看体验)。