I will just make things clear. TCP/UDP are two cars are that being driven on the road. suppose that traffic signs & obstacles are Errors TCP cares for traffic signs, respects everything around. Slow driving because something may happen to the car. While UDP just drives off, full speed no respect to street signs. Nothing, a mad driver. UDP doesn't have error recovery, If there's an obstacle, it will just collide with it then continue. While TCP makes sure that all packets are sent & received perfectly, No errors , so , the car just passes obstacles without colliding. I hope this is a good example for you to understand, Why UDP is preferred in gaming. Gaming needs speed. TCP is preffered in downloads, or downloaded files may be corrupted.

根据我的经验，UDP稍微快一点，但也快不了多少。选择不应该基于性能，而应该基于消息内容和压缩技术。

如果它是一种带有消息交换的协议，我建议使用TCP所带来的轻微性能损失是值得的。你得到了两个端点之间的连接它能提供你所需要的一切。不要尝试在UDP之上创建自己可靠的双向协议，除非你对自己的工作非常非常有信心。

如果不考虑网络情况，只讨论TCP或UDP是没有意义的。 如果两点之间的网络质量非常高，UDP绝对比TCP快，但在其他一些情况下，如GPRS网络，TCP可能比UDP更快，更可靠。

每个TCP连接都需要在数据传输之前进行初始握手。此外，TCP报头包含大量用于不同信号和消息传递检测的开销。对于消息交换，如果失败的可能性很小，UDP可能就足够了。如果必须验证收据，TCP是最好的选择。

具有容错功能

你是说“容忍损失”吗?

基本上，UDP不是“容错”的。你可以发送100个包给某人，他们可能只收到其中的95个包，有些包的顺序可能是错误的。

对于视频流媒体和多人游戏之类的东西，错过一个数据包总比延迟它后面的所有其他数据包要好，这是显而易见的选择

然而，对于大多数其他事情，丢失或“重新排列”的数据包是至关重要的。你必须编写一些额外的代码来运行在UDP之上，以便在遗漏内容时重试，并强制执行正确的顺序。这在某些地方会增加一点开销。

值得庆幸的是，一些非常非常聪明的人已经做到了这一点，他们称之为TCP。

可以这样想:如果一个数据包丢失了，您是希望尽快获得下一个数据包并继续(使用UDP)，还是您实际上需要丢失的数据(使用TCP)。开销并不重要，除非你在一个真正的边缘情况下。

如果你需要在两个还没有通话的IP之间快速发送消息，那么UDP到达的速度至少要快3倍，通常是5倍。