如果您实现自己的错误检查，为什么还要使用 TCP 而不是 UDP？答案

【问题标题】：Why would you ever use TCP instead of UDP if you implement your own error checking?如果您实现自己的错误检查，为什么还要使用 TCP 而不是 UDP？
【发布时间】：2021-04-12 15:22:54
【问题描述】：

我在网上阅读了很多关于为什么要使用 UDP 或 TCP 的资料，但我仍然需要帮助来理解一些东西。

如果我在我的应用程序中实现错误检查和重新传输，我为什么还要考虑使用 TCP？开发人员利用 TCP 的内置功能而不是自己在应用层实现它们是否更方便？我知道 TCP 包含流量控制，这使得它对网络上的其他服务更友好，但是，如果我是一个自私的混蛋，可以对其他人不屑一顾，并希望我的应用程序尽可能快，我不会选择 UDP在每种情况下？

在您的应用程序中重新实现 TCP 的功能是一项艰巨的任务吗？我只需要帮助理解为什么，如果 UDP 快得多，每个应用程序在每种情况下都不会使用 UDP。

【问题讨论】：

除了最初的 3 个数据包建立 TCP 连接外，两者没有太大区别。有效负载往往比数据包标头的大小大得多。
这很有趣。所以你说在你的应用程序中实现 TCP 特性的开销通常不值得付出努力？但是Bit Torrent开始使用UDP而不是TCP不是因为它“更快”吗？
当您比较在 UDP 流中实现自己的重新排序/重新传输/流量控制的开销时，没有。 UDP 真的是一劳永逸

标签： tcp network-programming udp network-protocols

【解决方案1】：

TCP 提供的不仅仅是错误检查，因此如果您想替换它，还有很多事情要做。以下是一些没有特别顺序的事情：

1.标准化

您已经编写了自己的传输协议。恭喜！自己使用它很有趣，因为您的实现是唯一的。另一方面，TCP 存在并且在任何平台上都经过了很好的测试。它受到防火墙、代理、路由器以及您的流量在网络中可能遇到的所有其他事物的支持。

2。拥塞控制

这就是您在说“流控制”时所想到的（请参阅下一个项目符号）。拥塞控制会限制 TCP 流以响应网络拥塞。但是你是一个自私的混蛋（这很好！）所以你问你为什么要关心。好吧，您大部分网络使用的瓶颈是您和您的提供商之间的链接。您的提供商通常配置良好，并且有网络工程师可供他使用。这些人知道如何保护网络免受过度使用以及如何避免热点。因此，TCP 的拥塞控制最能真正保护您和您的应用程序，确保单个应用程序不会阻塞整个连接。它有助于确保您不会因为从您的 PC 到路由器的链路可以支持 1Gbps 而做任何愚蠢的事情，例如通过 50Mbps 连接发送 1Gbps 的流量。

3.流量控制

流控制不是拥塞控制。简而言之，流量控制是在您不再能够处理传入信息时告诉对方闭嘴。想想一部手机试图从附近的 HTTP 服务器加载一个繁重的网页。服务器可以将整个页面转储到网络上，而手机处理它所需时间的一小部分。在这种情况下，瓶颈不是网络而是设备之一。您的 TCP 替代方案也必须解决此问题。

4.按订单发货

除了错误检测之外，TCP 还保证数据会以正确的顺序到达。这与错误检测不同，它是一个附加功能。

5.安全

TCP 三向握手和现代操作系统生成初始序列号的方式实际上向双方保证了对方主机的 IP 地址是真实的且不是伪造的。情况并非总是如此。早在初始序列号很容易预测的时候，these 攻击就已经存在。

此外，实现 TCP 的所有功能很困难，而且复杂性会滋生错误。众所周知，许多 TCP 实现包含各种错误，例如缓冲区溢出，其中一些具有严重的安全隐患。希望现在已经找到并修复了所有内容。新协议和新实现总是存在引入新安全漏洞的风险。

6.性能

网卡和现代操作系统减轻了应用程序管理 TCP 的负担，而且它们现在做得很好。您想使用自己的序列号和错误检测吗？您必须自己在用户空间中实现它们（并遭受性能损失，特别是如果您的应用程序是用 Java 之类的东西编写的）或准备编写内核和驱动程序补丁。

此外，现有的 TCP 实现本身已经经过整代工程师的审查和优化。自己创造出像自己打磨的东西是非常具有挑战性的。

【讨论】：

我喜欢这个答案，因为您解决了 TCP 的每个功能。我没想到如果没有拥塞控制，您实际上可能会伤害自己。不过，当您谈论“标准化”时，我感到很困惑。我问的不是实现你自己的传输层协议，我的意思是在应用层实现 TCP 的功能。在这种情况下，只要用户安装了您的应用程序，它就可以工作。您的意思是，由于您必须与应用程序打包附加功能，因此移植到其他平台会变得更加困难？
@red888 首先，标准化意味着您不必重新发明轮子，因为轮子存在于您可以想象的每个平台上。另外，到目前为止，它是一个非常坚固的轮子。其次，使用自定义传输协议是可能的，但这就像在轨道之间建造一条非标准距离的铁路。只要您的火车只需要在您的车站之间行驶，您的火车就会在上面运行良好。但是，如果有一天你想把火车送到其他地方，你就会遇到问题。

【解决方案2】：

您可以使用 UDP 构建您自己的 TCP 相似。谷歌正在使用 QUIC 做到这一点。他们正试图以一种与互联网兼容的方式来修复 TCP 的缺陷，这种方式几乎只将 UDP 作为底层传输。

QUIC的主要创新点有：

多个流。丢包只会延迟单个流。其他人继续。
前向纠错，以便在丢包的情况下完全不停止。

如您所见，替换TCP是完全可行和有效的。

这很可能不值得。 QUIC 不是为了吞吐量，而是为了延迟。预期的用例肯定是网页浏览。 UDP当然不是“快得多”。为什么会这样？ TCP 和 UDP 都可以在减去一些相当小的开销的线路速度下运行。

一种流行的混合方案是首先通过 UDP 发送数据。如果需要重试，则通过 TCP 重新发送。

【讨论】：

OP的问题不是能否替代TCP，而是为什么开发者选择使用它。

【解决方案3】：

我只需要帮助理解为什么，如果 UDP 速度如此之快，那么每个应用程序都不会在每种情况下都使用 UDP。

UDP 本身并不快。它甚至可以更慢：

UDP 是基于数据报的，即每个send 都会生成一个带有所有相关开销的新数据包。相反，TCP 是基于流的，并尝试通过将多个 send 合并在一起来创建具有最佳大小 (MTU) 的数据包。因此，它通过自动调整实现了更少的开销，而对于 UDP，您需要显式调整才能获得相同的性能。
在数据包丢失时，TCP 会降低发送速度，这样它就不会丢失更多的数据包。使用 UDP，您要么必须低于线路的最大连接以确保安全，要么必须预期会有大量数据包丢失。当然，您可以实现与 TCP 类似的方法，或者您可以实现更好的方法，该方法不是通用的，但更适合您的用例。
UDP 对于短连接可以更快，因为您没有初始握手。但是您仍然需要注意数据包丢失，请参阅 SIP (RFC3261) 了解如何处理此问题的示例。
UDP 通常用于音频/视频的实时流式传输。但这并不是因为它更快，而是因为低延迟更为重要，并且使用的编解码器可以处理数据包丢失。在这种情况下，使用 TCP 重新传输数据是没有用的。
相反，TCP 用于以可靠的方式传输大量数据，例如 FTP 和 HTTP。

【讨论】：

【解决方案4】：

选择 TCP 的另一个原因可能是：

当您需要通过 NAT 路由器进行通信时，您不必在使用 TCP 时发送那么多 IP 数据包。这样做的原因是，在任何协议上，NAT 路由器都会在一段时间后丢弃内部和外部网络地址之间的关联（可能是两端都死了）。但是在典型的 NAT 路由器上使用 TCP 超时在几十分钟内，而在 UDP 上使用相同的超时在几十秒内。

这在移动设备上尤其重要，因为移动设备发送的每个数据包都会耗尽电池。因此，许多手机更喜欢使用 SIP 协议而不是 TCP 连接，而不是使用 UDP。

【讨论】：