当前位置:  开发笔记 > 运维 > 正文

什么时候使用UDP而不是TCP?

如何解决《什么时候使用UDP而不是TCP?》经验,为你挑选了11个好方法。

由于TCP保证了数据包传输,因此可以被认为是"可靠的",而UDP不保证任何东西,数据包可能会丢失.在应用程序中而不是在TCP流上使用UDP传输数据有什么好处?在什么样的情况下,UDP是更好的选择,为什么?

我假设UDP更快,因为它没有创建和维护流的开销,但如果某些数据永远不会到达目的地那么这不是无关紧要的吗?



1> drudru..:

这是我最喜欢的问题之一.UDP被误解了.

在您真的希望快速获得另一台服务器的简单答案的情况下,UDP效果最佳.通常,您希望答案位于一个响应数据包中,并且您准备实施自己的协议以确保可靠性或重新发送.DNS是这个用例的完美描述.连接设置的成本太高(但DNS也支持TCP模式).

另一种情况是,当您提供可能丢失的数据时,因为新的数据将替换先前的数据/状态.我们会想到天气数据,视频流,股票报价服务(不用于实际交易)或游戏数据.

另一种情况是,当您管理大量状态并且您希望避免使用TCP时,因为操作系统无法处理那么多会话.这是今天罕见的情况.实际上,现在可以使用用户域TCP堆栈,以便应用程序编写者可以对该TCP状态所需的资源进行更细粒度的控制.在2003年之前,UDP真的是镇上唯一的游戏.

另一种情况是多播流量.UDP可以被多播到多个主机,而TCP根本不能这样做.



2> Stephan202..:

如果TCP数据包丢失,将重新发送.对于依赖于按特定顺序实时处理数据的应用程序而言,这并不方便.

示例包括视频流,尤其是VoIP(例如Skype).然而,在那些情况下,丢弃的数据包并不是什么大问题:我们的感官并不完美,所以我们甚至都不会注意到.这就是为什么这些类型的应用程序使用UDP而不是TCP.


我认为你倒退了.TCP重新排序数据包,以便按发送的顺序传送数据.UDP不会按照收到的顺序重新排序和传送数据.
@ Stephan202:我想我不得不在不注意Skype中丢失的数据包方面存在分歧;-)
@Kugel:请注意您可能正在实现新的TCP堆栈.你不太可能在这方面比操作系统做得更好.

3> S.Lott..:

UDP的"不可靠性"是一种形式主义.传输不是绝对保证.实际上,他们几乎总能通过.他们只是在超时后才会确认并重试.

协商TCP套接字和握手TCP数据包的开销很大.真的很大.没有明显的UDP开销.

最重要的是,您可以通过一些可靠的交付握手轻松补充UDP,这比TCP的开销更少.阅读:http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP对于在发布 - 订阅类型的应用程序中广播信息非常有用.IIRC,TIBCO大量使用UDP来通知状态变化.

使用UDP数据包可以很好地处理任何其他类型的单向"重要事件"或"日志记录"活动.您希望在不构建整个套接字的情况下发送通知.您不希望各种听众做出任何回应.

系统"心跳"或"我活着"的消息也是一个不错的选择.失踪的不是危机.缺少了六打(连续).


"作为一个实际问题,他们几乎总能通过".高度依赖于较低的网络层可靠性.

4> Mark Wilkins..:

我致力于支持客户端和服务器之间的UDP(IP)和TCP/IP通信的产品.它始于15年前的IPX,并在13年前增加了IP支持.我们在3或4年前添加了TCP/IP支持.疯狂的猜测:UDP到TCP的代码比率大约是80/20.该产品是数据库服务器,因此可靠性至关重要.我们必须处理在其他答案中已经提到过的UDP(数据包丢失,数据包加倍,数据包顺序等)所带来的所有问题.很少有任何问题,但有时会发生,所以必须处理.支持UDP的好处是我们能够根据自己的用途对其进行一些自定义,并从中调整一点性能.

每个网络都会有所不同,但UDP通信协议对我们来说通常要快一点.持怀疑态度的读者会正确地质疑我们是否正确实施了一切.另外,对于一个拥有2位数代表的人,您能期待什么?尽管如此,我刚刚出于好奇而进行了测试.该测试读取了100万条记录(从某些表中选择*).我设置要返回的记录数,每个客户端请求为1,10,然后是100(每个协议运行三次).服务器在100Mbit LAN上只有两跳.这些数字似乎与其他人过去发现的数据一致(在大多数情况下UDP速度提高了约5%).此特定测试的总时间(以毫秒为单位)如下:

    1条记录

    IP:390,760毫秒

    TCP:416,903毫秒

    10条记录

    IP:91,707毫秒

    TCP:95,662毫秒

    100条记录

    IP:29,664毫秒

    TCP:30,968毫秒

对于IP和TCP,传输的总数据量大致相同.我们有UDP通信的额外开销,因为我们有一些与TCP/IP(校验和,序列号等)"免费"相同的东西.例如,Wireshark显示对下一组记录的请求是带有UDP的80字节和带有TCP的84字节.


谢谢具体的数字!它增加的复杂性使得5%的改进有点令人失望.

5> Andy..:

这里已经有很多好的答案,但我想补充一个非常重要的因素,以及摘要.UDP可以通过正确的调整实现更高的吞吐量,因为它不使用拥塞控制.TCP中的拥塞控制非常重要.它通过尝试估计连接的当前容量来控制连接的速率和吞吐量,以最小化网络拥塞.即使数据包是通过非常可靠的链路(例如核心网络)发送的,路由器也只能使用有限大小的缓冲区.这些缓冲区填满其容量,然后丢弃数据包,TCP通过缺少收到的确认来注意到这种情况下降,并限制连接速度以估计容量.TCP还使用称为慢启动的东西,但吞吐量(实际上是拥塞窗口)缓慢增加,直到数据包被丢弃,然后降低并再次缓慢增加,直到数据包被丢弃等.这导致TCP吞吐量波动.下载大文件时,您可以清楚地看到这一点.

因为UDP不使用拥塞控制,所以它可以更快,并且经历更低的延迟,因为它不会寻求最大化缓冲区直到丢弃点,即UDP分组在缓冲区中花费更少的时间并且以更低的延迟更快地到达那里.因为UDP不使用拥塞控制,但TCP会这样做,它可以从TCP中带走产生UDP流量的容量.

UDP仍然容易受到拥塞和数据包丢失的影响,因此您的应用程序必须准备好以某种方式处理这些较少的丢失,可能使用重传或纠错码.

结果是UDP可以:

只要网络丢弃率在应用程序可以处理的限制范围内,就可以实现比TCP更高的吞吐量.

比TCP更快地传送数据包,延迟更少.

设置连接速度更快,因为没有初始握手来设置连接

传输多播数据包,而TCP必须使用多个连接.

传输固定大小的数据包,而TCP以段传输数据.如果传输300字节的UDP数据包,则另一端将收到300字节.使用TCP,您可以为发送套接字提供300字节,但接收方只读取100字节,您必须弄清楚路上还有200字节.如果您的应用程序传输固定大小的消息而不是字节流,这一点很重要.

总之,只要您还实现了正确的重传机制,UDP就可以用于TCP可以使用的每种类型的应用程序.UDP可以非常快,具有低延迟,不受连接拥塞的影响,传输固定大小的数据报并且可以用于多播.



6> Arnkrishn..:

UDP是一种无连接协议,用于SNMP(简单网络管理协议),DNS(域名系统)等应用程序,其中数据包无序到达,不可靠而且不受关注,并且数据包的立即发送很重要.

由于UDP不涉及连接建立,因此存在需要避免连接建立延迟的DNS之类的应用,UDP优于TCP.

在SNMP中使用,因为网络管理时通常必须进行网络管理,即在可靠的情况下,很难实现拥塞控制的数据传输.

干杯



7> Dana Holt..:

UDP确实具有较少的开销,并且可以用于传输诸如音频或视频之类的实时数据,或者在数据丢失的任何情况下都可以.



8> Shital Shah..:

我知道这个问题的最佳答案之一来自Hacker News的用户zAy0LfpBZLC8mAC.这个答案非常好,我只是按原样引用它.

TCP具有队列阻塞功能,因为它可以保证完整和有序传送,因此当数据包在传输过程中丢失时,它必须等待丢失数据包的重新传输,而UDP会在数据包到达时将数据包传送到应用程序,包括重复,并且不保证数据包完全到达或它们到达的顺序(它实际上基本上是带有端口号的IP和添加的(可选的)有效负载校验和),但这对于电话很好,例如,通常当几毫秒的音频丢失时无关紧要,但是延迟非常烦人,所以你不需要重新传输,只需删除任何重复项,将重新排序的数据包按正确的顺序排序几百毫秒的抖动缓冲区如果数据包没有及时显示或根本没有显示,则只需跳过它们,可以在编解码器支持的情况下进行插值.

此外,TCP的主要部分是流量控制,以确保您获得尽可能多的吞吐量,但不会使网络过载(这有点多余,因为过载的网络会丢弃您的数据包,这意味着您必须做转发,这会损害吞吐量),UDP没有任何 - 这对于电话等应用是有意义的,因为具有给定编解码器的电话需要一定量的带宽,你不能"减速",并且还有额外的带宽不会使通话更快.

除了实时/低延迟应用程序之外,UDP对于真正的小型事务(例如DNS查找)也很有意义,因为它在延迟和带宽使用方面没有TCP连接建立和拆除开销.如果您的请求小于典型的MTU并且repsonse也可能是,那么您可以在一次往返中完成,无需在服务器上保持任何状态,并且流量控制也可以排序,所有这些可能都不是特别有用用于此类用途.

然后,您可以使用UDP来构建自己的TCP替换,当然,如果没有对网络动态的深刻理解,它可能不是一个好主意,现代TCP算法非常复杂.

另外,我想应该提到的不仅仅是UDP和TCP,例如SCTP和DCCP.目前唯一的问题是(IPv4)互联网充满了NAT网关,这使得在最终用户应用程序中无法使用UDP和TCP以外的协议.



9> old_timer..:

UDP具有较低的开销,如上所述已经很好地用于流式传输视频和音频之类的东西,其中最好丢失数据包然后尝试重新发送并赶上.

TCP交付没有任何保证,你应该被告知套接字是否断开连接,或者基本上是否数据不会到达.否则它会到达那里.

人们忘记的一件大事是udp是基于数据包的,tcp是基于字节流的,不能保证你发送的"tcp数据包"是出现在另一端的数据包,它可以被分解成尽可能多的数据包正如路由器和堆栈所希望的那样.因此,您的软件会有额外的开销,将字节解析回可用的数据块,这可能需要相当大的开销.UDP可能出现故障,因此您必须对数据包进行编号,或者如果您愿意,可以使用其他机制对其进行重新排序.但是如果你得到那个udp数据包它会以与它离开时相同的顺序到达所有相同的字节,没有变化.因此术语udp数据包是有意义的,但tcp数据包不一定.TCP有自己的重新尝试和排序机制,隐藏在您的应用程序之外,您可以使用UDP重新创建它以根据您的需要进行定制.

UDP在两端编写代码要容易得多,主要是因为您不必制作和维护点对点连接.我的问题通常是你想要TCP开销的情况在哪里?如果您采取快捷方式,例如假设收到的tcp"数据包"是已发送的完整数据包,那么你最好离开吗?(如果你懒得检查长度/内容,你可能会丢掉两个数据包)



10> Daniel A. Wh..:

视频流是使用UDP的完美示例.



11> 17 of 26..:

视频游戏的网络通信几乎总是通过UDP完成。

速度是最重要的,是否错过更新并不重要,因为每次更新都包含玩家可以看到的完整当前状态。


正常情况下根本不是完整状态,而是自上次确认以来的增量,因此更新会逐渐变大。
推荐阅读
linjiabin43
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有