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

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

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

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

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

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

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

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

UDP在需要速度时使用，如果数据包不需要，则使用精度，而TCP在需要精度时使用。

UDP通常比较难，因为你必须以一种不依赖于数据包准确性的方式来编写程序。

There are already many good answers here, but I would like to add one very important factor as well as a summary. UDP can achieve a much higher throughput with the correct tuning because it does not employ congestion control. Congestion control in TCP is very very important. It controls the rate and throughput of the connection in order to minimize network congestion by trying to estimate the current capacity of the connection. Even when packets are sent over very reliable links, such as in the core network, routers have limited size buffers. These buffers fill up to their capacity and packets are then dropped, and TCP notices this drop through the lack of a received acknowledgement, thereby throttling the speed of the connection to the estimation of the capacity. TCP also employs something called slow start, but the throughput (actually the congestion window) is slowly increased until packets are dropped, and is then lowered and slowly increased again until packets are dropped etc. This causes the TCP throughput to fluctuate. You can see this clearly when you download a large file.

因为UDP没有使用拥塞控制，它可以更快，并且经历更少的延迟，因为它不会寻求最大化缓冲区直到丢弃点，也就是说，UDP数据包在缓冲区中花费的时间更少，到达那里的速度更快，延迟更少。由于UDP不采用拥塞控制，但TCP采用拥塞控制，因此它可以从TCP中占用生成UDP流的容量。

UDP仍然容易受到拥塞和数据包丢失的影响，所以你的应用程序必须准备好以某种方式处理这些问题，可能使用重传或错误纠正代码。

结果是UDP可以:

Achieve higher throughput than TCP as long as the network drop rate is within limits that the application can handle. Deliver packets faster than TCP with less delay. Setup connections faster as there are no initial handshake to setup the connection Transmit multicast packets, whereas TCP have to use multiple connections. Transmit fixed size packets, whereas TCP transmit data in segments. If you transfer a UDP packet of 300 Bytes, you will receive 300 Bytes at the other end. With TCP, you may feed the sending socket 300 Bytes, but the receiver only reads 100 Bytes, and you have to figure out somehow that there are 200 more Bytes on the way. This is important if your application transmit fixed size messages, rather than a stream of bytes.

总之，UDP可以用于TCP可以使用的任何类型的应用程序，只要您还实现了适当的重传输机制。UDP可以非常快，有更少的延迟，在连接的基础上不受拥塞的影响，传输固定大小的数据报，并可用于组播。

当TCP可以工作时，我有点不情愿建议使用UDP。问题是，如果TCP由于某种原因不能工作，因为连接太延迟或拥塞，将应用程序更改为使用UDP不太可能有帮助。一个坏的连接对UDP也不好。TCP在减少拥塞方面已经做得很好了。

我能想到的唯一需要UDP的情况是广播协议。在应用程序涉及两个已知主机的情况下，UDP可能只会提供边际的性能优势，而代码复杂性的成本则会大幅增加。

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