首页 文章

什么时候使用UDP而不是TCP? [关闭]

提问于
浏览
272

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

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

24 回答

  • 2

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

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

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

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

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

  • 54

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

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

  • 3

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

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

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

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

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

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

  • 1

    我的产品支持客户端和服务器之间的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 ms

    • TCP:95,662 ms

    • 100条记录

    • IP:29,664 ms

    • TCP:30,968毫秒

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

  • 2

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

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

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

    干杯

  • 1

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

  • 2

    这里已经有很多好的答案,但我想补充一个非常重要的因素,以及总结 . 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可以非常快,具有低延迟,不受连接拥塞的影响,传输固定大小的数据报并且可以用于多播 .

  • 2

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

    TCP具有队列阻塞功能,因为它可以保证完整和按顺序传送,因此当数据包在传输过程中丢失时,它必须等待重新传输丢失的数据包,而UDP会将数据包传送到应用程序,因为它们到达,包括重复,并且没有任何保证数据包完全到达或它们到达的顺序(它实际上基本上是带有端口号的IP和添加的(可选的)有效负载校验和),但这对于电话很好,例如,它在哪里通常只是在几毫秒的音频丢失时无关紧要,但延迟非常烦人,所以你不需要重复传输,只需删除任何重复数据,将重新排序的数据包按正确的顺序排序几百毫秒的抖动缓冲区,如果数据包没有及时显示或根本没有显示,则只需跳过它们,可能在编解码器支持的情况下进行插值 . 此外,TCP的主要部分是流量控制,以确保您获得尽可能多的吞吐量,但不会过载网络(有点多余,因为过载的网络会丢弃你的数据包,这意味着你必须进行重传,这会损害吞吐量),UDP没有任何 - 这对于电话等应用来说是有意义的,具有给定编解码器的电话需要一定量的带宽,您不能“减速”,而额外的带宽也不能使呼叫更快 . 除了实时/低延迟应用程序之外,UDP对于真正的小型事务(例如DNS查找)也很有意义,因为它在延迟和带宽使用方面没有TCP连接 Build 和拆除开销 . 如果您的请求小于典型的MTU并且repsonse也可能是,那么您可以在一次往返中完成,不需要在服务器上保持任何状态,并且流量控制也可以排序,所有这些可能都不是特别有用用于此类用途 . 然后,您可以使用UDP来构建自己的TCP替换,当然,如果没有对网络动态的深入理解,它可能不是一个好主意,现代TCP算法非常复杂 . 另外,我想应该提到的不仅仅是UDP和TCP,例如SCTP和DCCP . 目前唯一的问题是(IPv4)互联网充满了NAT网关,这使得在最终用户应用程序中无法使用UDP和TCP以外的协议 .

  • 8

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

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

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

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

  • 3

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

  • 12

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

    速度至关重要,如果错过更新并不重要,因为每次更新都包含玩家可以看到的完整当前状态 .

  • 2

    在某些情况下,其他人已经强调,保证数据包的到达并不重要,因此使用UDP很好 . 在其他情况下,UDP优于TCP .

    您希望使用UDP而不是TCP的一种独特情况是您通过其他协议(例如隧道,虚拟网络等)隧道化TCP . 如果通过TCP隧道TCP,则每个的拥塞控制将相互干扰 . 因此,人们通常倾向于通过UDP(或一些其他无状态协议)隧道TCP . 请参阅TechRepublic文章:Understanding TCP Over TCP: Effects of TCP Tunneling on End-to-End Throughput and Latency .

  • 4

    关键问题与“UDP是哪种情况更好的选择[over tcp]”有关

    上面有很多很好的答案,但缺乏的是对运输不确定性对TCP性能影响的任何正式,客观的评估 .

    随着移动应用程序的大量增长,以及与它们一起出现的“偶尔连接”或“偶尔断开连接”的范例,当然存在TCP连接难以实现时尝试维持连接的开销导致强大的问题UDP的案例及其“面向消息”的本质 .

    现在我没有这方面的数学/研究/数字,但我已经制作了使用和ACK / NAK以及UDP上的消息编号更可靠地工作的应用程序,而当连接通常很差且旧的TCP很差时,可以用TCP实现只是花了时间和我的客户的钱只是想连接 . 你在许多西方国家的地区和农村地区得到这个....

  • 26

    当应用程序更关心“实时”数据而不是精确数据时,可以使用UDP数据复制 . 例如,VOIP可以使用UDP,应用程序将担心重新排序数据包,但最终VOIP不需要每个数据包,但更重要的是需要连续流动其中许多数据包 . 也许你这里的声音质量“小故障”,但主要目的是你得到的信息,而不是它在另一边完美再现 . UDP也用于创建连接和与TCP同步的费用超过有效负载的情况 . DNS查询就是一个很好的例子 . 每个查询一个数据包输出,一个数据包返回 . 如果使用TCP,这将更加密集 . 如果您没有收到DNS响应,则只需重试即可 .

  • 6

    需要速度时的UDP和数据包不存在时的准确性,以及需要准确性时的TCP .

    UDP通常比较困难,因为您必须以不依赖于数据包准确性的方式编写程序 .

  • 1

    它并不总是清晰明确 . 但是,如果您需要保证无错误地传输数据包并且顺序正确,那么TCP可能就是您想要的 .

    另一方面,UDP适用于传输信息序列不太重要的短信息包或者数据可以装入单个包的情况 .

    当您想要向许多用户广播相同的信息时,它也是合适的 .

    其他时候,当您发送有序数据时它是合适的,但如果其中一些丢失则您不太关注(例如VOIP应用程序) .

    有些协议更复杂,因为需要的是TCP的一些(但不是全部)功能,但比UDP提供的功能更多 . 这就是应用层必须实现附加功能的地方 . 在这些情况下,UDP也是合适的(例如,互联网无线电,订单很重要,但不是每个数据包都需要通过) .

    其中/可以使用的示例1)时间服务器向LAN上的一堆机器广播正确的时间 . 2)VOIP协议3)DNS查找4)请求LAN服务,例如你在哪? 5)互联网广播6)和许多其他...

    在unix上,你可以输入grep udp / etc / services来获取今天实现的UDP协议列表......有数百个 .

  • 317

    请看Steven的Unix Network Programming,"When to Use UDP Instead of TCP"的第22.4节 .

    另外,请参阅关于the misconception that UDP is always faster than TCP的其他SO答案 .

    史蒂文所说的可归纳如下:

    • 使用UDP进行广播和多播,因为这是您唯一的选择(对任何新应用使用多播)

    • 您可以将UDP用于简单的请求/回复应用程序,但是您需要构建自己的ack,超时和重新传输

    • 不要使用UDP进行批量数据传输 .

  • 13

    我们知道UDP是一种无连接协议,所以它是

    • 适用于需要简单请求 - 响应通信的进程 .

    • 适用于具有内部流量,错误控制的过程

    • 适合广泛的铸造和组播

    具体例子:

    • 在SNMP中使用

    • 用于某些路由更新协议,例如RIP

  • 0

    在沿途丢失一些数据不会完全破坏正在传输的数据的情况下,您希望使用UDP over TCP . 它的许多用途都是在实时应用程序中,例如游戏(即FPS,你不必总是知道每个玩家在任何特定时间的位置,如果你在途中丢失了一些数据包,那么新的数据将正确地告诉你玩家在哪里)和实时视频流(一个损坏的帧不会破坏观看体验) .

  • 13

    我们拥有Web服务,在尽可能多的PC中拥有数千个winforms客户端 . PC与DB后端无关,所有访问都通过Web服务进行 . 因此,我们决定开发一个监听UDP端口的中央日志记录服务器,并且所有客户端都会发送一个xml错误日志数据包(使用log4net UDP appender),该数据包在收到时会被转储到数据库表中 . 由于我们并不真正关心是否错过了一些错误日志,并且有数千个客户端,因此专用日志记录服务无法加载主Web服务 .

  • 15

    将TCP与UDP进行比较,UDP等无连接协议可确保速度,但不保证数据包传输的可靠性 . 例如,在视频游戏中通常不需要可靠的网络,但速度是最重要的,并且使用UDP用于游戏具有减少网络延迟的优点 .

    enter image description here

  • -2

    当TCP可能工作时,我有点不愿意建议UDP . 问题是如果TCP由于某种原因不起作用,因为连接太滞后或拥塞,更改应用程序以使用UDP不太可能有所帮助 . 糟糕的连接也不利于UDP . TCP已经在减少拥塞方面做得非常好 .

    我能想到UDP所需的唯一情况是广播协议 . 在应用程序涉及两个已知主机的情况下,UDP可能仅为代码复杂性的显着增加成本提供边际性能益处 .

  • -1

    如果你真的只使用UDP知道你在做什么 . UDP在今天非常罕见,但是那些试图在任何地方坚持下去的(即使非常有经验的)专家的数量似乎也不成比例 . 也许他们喜欢自己实现错误处理和连接维护代码 .

    由于所谓的 checksum imprint ,使用现代网络接口卡应该可以更快地实现TCP . 令人惊讶的是,在快速连接速度(例如1Gbps)下,计算校验和对于CPU来说将是一个很大的负载,因此它可以识别TCP数据包以进行压印,并且它不会为您提供相同的服务 .

  • 57

    UDP是完美的VoIP寻址,其中数据包必须发送,而不是其可靠性...视频聊天是UDP的一个例子(您可以通过wireshark网络捕获在任何视频聊天期间检查它)..此外,TCP无法使用DNS和SNMP协议 . UDP没有任何开销,而TCP有很多开销

相关问题