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“数据包”是发送的完整数据包，你会更好吗?(如果你费心检查长度/内容，你可能会扔掉两个包)

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

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

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

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

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

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

We have web service that has thousands of winforms client in as many PCs. The PCs have no connection with DB backend, all access is via the web service. So we decided to develop a central logging server that listens on a UDP port and all the clients sends an xml error log packet (using log4net UDP appender) that gets dumped to a DB table upon received. Since we don't really care if a few error logs are missed and with thousands of client it is fast with a dedicated logging service not loading the main web service.

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

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

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

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

只使用UDP，如果你真的知道你在做什么。UDP在今天是在极其罕见的情况下，但数量(甚至非常有经验)专家谁会试图坚持到处似乎是不成比例。也许他们喜欢自己实现错误处理和连接维护代码。

由于所谓的校验和印记，使用现代网络接口卡，TCP应该会快得多。令人惊讶的是，在快速连接速度下(比如1Gbps)，计算校验和对CPU来说是一个很大的负载，所以它被卸载到识别TCP数据包的NIC硬件上，它不会为你提供相同的服务。