TCP 的速度与您利用其可靠性属性所做的一样快。如果您只需要，比如说，排序和错误检测，UDP 可以完美地服务。这是大多数实时协议（如语音、视频流等）的基础，其中滞后和抖动比“绝对”纠错更重要。

从根本上说，TCP 表示最终可以依赖其数据流. 多快取决于各种计时器、速度等。解决错误所需的时间可能无法预测，但在没有错误的情况下，基本操作会尽可能快。如果系统知道可能发生的错误类型，它可能会做一些 TCP 无法做到的事情。例如，如果单比特错误的可能性特别大，您可以对这些比特错误使用纠错编码：但是，这在链路层中实现得更好。再举一个例子，如果整个数据包丢失的短突发很常见，您可以通过多次传输解决这个问题而无需等待丢失，但显然这在带宽上是昂贵的。或者，降低速度直到错误概率可以忽略不计：带宽也很昂贵。到底，

在实现方面，您会发现在 TCP 上投入的程序员世纪将使其比您负担得起的任何通用产品更快，并且在模糊的边缘情况下更可靠。

TCP 提供： 一种无处不在的连接方法（在通信系统没有共同控制的情况下必不可少），提供可靠的、有序的（和去重的）、双向、窗口化的字节流，并在任意距离的多跳网络上进行拥塞控制。

如果应用程序不需要无处不在（您的软件在两端都运行），或者不需要 TCP 的所有功能，那么许多人会使用其他协议（通常在 UDP 之上）获利。示例包括 TFTP（极简，错误处理效率低下，QUIC 旨在减少开销（仍标记为实验性），以及lidgren 等库，它可以精确控制所需的可靠性功能。[感谢评论者。 ]

具有可靠性的UDP确实可以替代TCP。我们已经有一个例子：它叫做QUIC。

来自维基百科：

在其他应用程序中，QUIC 提高了当前使用 TCP 的面向连接的 Web 应用程序的性能。它通过在用户数据报协议 (UDP) 上在两个端点之间建立多个多路复用连接来实现这一点。

与创建全新的传输层协议相比，使用 UDP 的优势在于路由器和其他网络设备已经了解它。

您可以使用 UDP 在应用层（可靠性、适应性）实现 TCP 功能。您也可以一开始就使用 TCP，除非您的应用程序真正需要的东西不能用 TCP 来完成。如果你自己实现这些功能，你很可能会比使用 TCP 更糟糕。增加的开销也会降低整体效率。

TCP 并不慢——它只需要在传输之前握手和传输窗口来适应信道。它可以很好地将其吞吐量整形到手头的传输通道并适应流期间的变化，而这些都是 UDP 无法做到的（靠它自己）。

然而，传输层之上的协议在这里是题外话。

在干净的网络上，它们非常等效。在某些情况下，TCP 会挂起一段时间（有人见过 HTTP 屏幕在加载时冻结吗？）但它不会传送垃圾或混淆数据包，并且很少完全放弃。

UDP 可以让应用层以大量工作为代价更好地控制流量。

你的问题的答案是，有时它是这样做的。需要低延迟的游戏通常就是这样做的。这是大量的工作，但是能够准确控制您可以拥有多少未完成的数据包以及重试它们的频率通常是值得的。

所以总的来说，区别在于 TCP 是一个非常好的通用实现，但是 UDP 可以做一些特定的目的，TCP 要么做得很差，要么根本没有——例如：

• 永不放弃（使用 TCP 连接有时会挂起，您必须断开连接并重新启动它）
• 发送不需要回复的快速数据包流，您不介意偶尔丢失一些数据包（只有最近的数据包很重要，其他数据包都可以丢弃）——想想游戏位置更新——你可能会得到一点“跳跃”而不是每一步，但您可以更快、更可靠地获得相同的结果。
• 通过分析数据包丢失并动态改变重试频率和速度来处理不确定的网络——甚至可能是最大数据包大小。

但总的来说，这是不值得的，TCP 是非常理想的，那么为什么要进行所有额外的工作并增加一个（大）增加错误和安全漏洞的机会呢？