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

Question

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

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

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

Answer 1

TCP 提供的不仅仅是错误检查，因此如果您想替换它，还有很多需要实现的。以下是一些不分先后顺序想到的事情:

<强>1。标准化

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

<强>2。拥塞控制

这就是您在说“流量控制”时想到的(见下一个项目符号)。拥塞控制会限制 TCP 流以响应网络拥塞。但你是个自私的 SCSS (这很好!)所以你问为什么要关心。嗯，大部分网络使用的瓶颈是你和你的供应商之间的联系。您的供应商通常配备齐全，并有网络工程师随时待命。这些人知道如何保护网络免受过度使用以及如何避免热点。所以 TCP 的拥塞控制真正保护了您和您的应用程序，确保单个应用程序不会阻塞整个连接。它有助于确保您不会做任何愚蠢的事情，比如仅仅因为从您的 PC 到路由器的链路可以支持 1Gbps，就通过您的 50Mbps 连接发送值(value) 1Gbps 的流量。

<强>3。流量控制

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

<强>4。按顺序交付

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

<强>5。安全性

TCP 三向握手和现代操作系统生成初始序列号的方式实际上向双方保证了另一台主机的 IP 地址是真实的而不是欺骗性的。情况并非总是如此。回到初始序列号很容易预测的时候，these存在攻击。

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

6.性能

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

此外，现有的 TCP 实现本身已经经过整代工程师的审查和优化。自己动手创作这样的东西是非常具有挑战性的。