我们已经做了一些工作，让程序员可以同时享受这两个世界的好处。

SCTP

它是一个独立的传输层协议，但它可以用作在UDP上提供附加层的库。通信的基本单位是消息(映射到一个或多个UDP包)。有内置的拥塞控制。该协议有许多旋钮和旋钮可以打开

按顺序传递信息 自动重传丢失的消息，与用户定义的参数

如果您的特定应用程序需要其中任何一个。

这样做的一个问题是建立连接是一个复杂的(因此是缓慢的过程)

其他类似的东西

https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

还有一个类似的专利实验

https://en.wikipedia.org/wiki/QUIC

这也试图改进TCP的三重握手，并改变拥塞控制以更好地处理快速线路。

更新2022:Quic和HTTP/3

QUIC(上面提到的)已经通过rfc标准化了，甚至在最初的答案写出来之后就成为了HTTP/3的基础。有各种各样的库，如lucas-clemente/quic-go或microsoft/msquic或谷歌/quiche或mozilla/neqo (web浏览器需要实现这个)。

这些库在UDP传输之上向程序员公开可靠的类tcp流。RFC 9221 (QUIC的不可靠数据报扩展)增加了处理单个不可靠数据包的功能。

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

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

网络的设置对于任何测量都是至关重要的。如果您通过本地机器上的套接字或与世界的另一端进行通信，则会产生巨大的差异。

我想在讨论中补充三点:

您可以在这里找到一篇关于TCP与UDP的非常好的文章 游戏开发的背景。 此外，iperf (jperf增强iperf与GUI)是一个 这是一个很好的工具，可以通过测量来回答你的问题。 我用Python实现了一个基准测试(参见这个SO问题)。在平均10^6次迭代中，UDP发送8字节的差异大约是1-2微秒。

人们说TCP给你的主要东西是可靠性。但事实并非如此。TCP提供给您的最重要的东西是拥塞控制:您可以在DSL链路上运行100个TCP连接，所有的连接都以最大速度运行，并且所有的100个连接都将是高效的，因为它们都“感知”到可用带宽。用100个不同的UDP应用程序尝试一下，所有的应用程序都尽可能快地推送数据包，看看事情对你有多好。

在更大的范围内，这种TCP行为可以防止Internet陷入“拥塞崩溃”。

倾向于将应用程序推向UDP的事情:

Group delivery semantics: it's possible to do reliable delivery to a group of people much more efficiently than TCP's point-to-point acknowledgement. Out-of-order delivery: in lots of applications, as long as you get all the data, you don't care what order it arrives in; you can reduce app-level latency by accepting an out-of-order block. Unfriendliness: on a LAN party, you may not care if your web browser functions nicely as long as you're blitting updates to the network as fast as you possibly can.

但即使你关心性能，你可能也不想使用UDP:

现在，您要考虑的是可靠性，您为实现可靠性所做的许多事情最终可能比TCP已经实现的要慢。 现在您对网络不友好，这可能会在共享环境中引起问题。 最重要的是，防火墙会阻止你。

通过将多个TCP连接“集群化”在一起，可以潜在地克服一些TCP性能和延迟问题;iSCSI这样做是为了绕过局域网上的拥塞控制，但是你也可以这样做来创建一个低延迟的“紧急”消息通道(TCP的“紧急”行为完全被破坏)。

UDP比TCP快，原因很简单，因为它不存在允许连续数据包流的确认数据包(ACK)，而不是使用TCP窗口大小和往返时间(RTT)来确认一组数据包的TCP。

要了解更多信息，我推荐简单但非常容易理解的Skullbox解释(TCP vs. UDP)