我在线阅读了很多关于你为什么要使用UDP或TCP的东西,但我仍然需要帮助来理解一些东西。
如果我在我的应用程序中实现错误检查和重新传输,为什么我甚至会考虑使用TCP?开发人员使用TCP的内置功能而不是在应用程序层自己实现它们是否更方便?我知道TCP包含流量控制,这使得它对网络上的其他服务更友好,但是,如果我是一个自私的混蛋谁可能对其他人都很讨厌,并希望我的应用尽可能快,我不会选择UDP在每种情况下?
在您的应用程序中重新实现TCP的功能是否是一项相当大的工作?我只需要帮助理解为什么,如果UDP速度快得多,每个应用程序都不会在每种情况下都使用UDP。
答案 0 :(得分:2)
您可以使用UDP构建自己的TCP外观。 Google正在与QUIC合作。他们试图以互联网兼容的方式修复TCP缺陷,这几乎只会将UDP作为底层传输。
QUIC的主要创新是:
正如您所看到的,替换TCP是完全可行和有效的。
很可能不值得。 QUIC不是为了吞吐量而是为了延迟。预期的用例肯定是网页浏览。 UDP肯定不是“快得多”。为什么会这样? TCP和UDP都可以以线速运行减去一些相当小的开销。
一种流行的混合方案是首先通过UDP发送数据。如果需要重试,则通过TCP重新发送。
答案 1 :(得分:2)
TCP提供的不仅仅是错误检查,如果要替换它,还有很多要实现的。以下是我想到的一些事情:
<强> 1。标准化强>
您已编写自己的传输协议。恭喜!玩得开心,因为你的是唯一的实现。 TCP是标准的,在任何平台上实施和测试。它受到防火墙,代理,路由器以及您可能在网络中遇到的所有其他内容的支持。
<强> 2。拥塞控制
当你说&#34; Flow Control&#34;这就是你想到的。 (见下一个子弹)。拥塞控制会限制TCP流以响应网络拥塞。但你是一个自私的混蛋(那很好)所以你要问你为什么要关心。嗯,您的大多数网络使用的瓶颈是您和您的提供商之间的链接。您提供的服务通常配置齐全,并有网络工程师随时为您服务。这些人知道如何保护网络免受过度使用,以及如何避免热点。因此,TCP的拥塞控制最重要的是保护您和您的应用程序,确保单个应用程序无法阻塞该线路。并确保您不要做任何愚蠢的事情,例如通过50Mbps连接发送1Gbps的流量,因为从PC到路由器的链路可以支持1Gbps。
第3。流量控制
流量控制 NOT 拥塞控制。简而言之,流量控制告诉对方在您不再能够处理传入信息时关闭。想想手机试图从附近的HTTP服务器加载繁重的网页。服务器可以将整个页面转储到网络上,只需花费手机处理它的时间。在这种情况下,瓶颈不是网络而是其中一个设备。您的TCP替代方案也必须解决此问题。
<强> 4。按顺序交付
除了错误检测之外,TCP还可以保证数据以正确的顺序到达。这与错误检测不同,它是一个附加功能。
<强> 5。安全强>
TCP三向握手和现代操作系统生成初始序列号的方式实际上向双方保证其他主机的IP地址是真实的,而不是欺骗性的。事情并非如此。当初始序列号易于预测时,存在these攻击。
<强> 6。卸载强>
网卡和现代操作系统负责管理应用程序中的TCP,他们做得很好。您想使用自己的序列号和错误检测吗?您必须自己在用户空间中实现它们(并且会受到性能损失,特别是如果您的应用程序是用Java编写的)或者准备编写内核和网卡补丁。
答案 2 :(得分:1)
我只需要帮助理解为什么,如果UDP速度快得多,每个应用程序都不会在每种情况下都使用UDP。
UDP本身并不快。它甚至可能更慢:
send
生成一个包含所有相关开销的新数据包。 TCP取而代之是基于流,并尝试通过将多个send
合并在一起来创建具有最佳大小(MTU)的数据包。因此,它通过自动调整实现了更少的开销,而使用UDP,您需要进行显式调整以实现相同的性能。答案 3 :(得分:0)
无论如何选择TCP的另一个原因可能是:
当您需要通过NAT路由器进行通信时,您不必在使用TCP时发送那么多IP数据包。原因是,在任何协议上,NAT路由器将在一段时间后丢弃内部和外部网络地址之间的关联(可能两端都已经死亡)。但是在典型的NAT路由器上使用TCP超时是几十分钟,而UDP上的超时是在几十秒内。
这对于移动设备来说尤其重要,因为移动设备会为每个发送的数据包耗尽电量。因为许多移动电话优先使用TCP协议上的SIP协议而不是使用UDP。