何时使用UDP而不是TCP是合适的?[关闭]

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

在您真正希望快速得到另一台服务器的简单答案的情况下,UDP工作得最好。一般来说,您希望答案在一个响应包中,并且为了可靠性或重新发送,您准备实现自己的协议。DNS是这个用例的完美描述。连接设置的成本太高了(然而,DNS 也支持TCP模式)。

另一种情况是,当您传递的数据可能会丢失,因为传入的新数据将替换以前的数据/状态。天气数据、视频流、股票报价服务(不用于实际交易)或游戏数据浮现在脑海中。

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

另一种情况是多播通信。可以将UDP多播到多个主机,而TCP则根本无法做到这一点。

如果A TCP 数据包丢失,将重新发送。对于依赖于以特定顺序实时处理的数据的应用程序来说,这并不方便。

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

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

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

最重要的是,您可以轻松地用一些比TCP开销更低的可靠的传递握手来补充UDP。请阅读: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

在发布订阅类应用程序中,UDP可用于广播信息。iirc,tibco大量使用udp通知状态更改。

任何其他类型的单向“重大事件”或“日志记录”活动都可以用UDP包很好地处理。您希望在不构建整个套接字的情况下发送通知。您不期望来自不同听众的任何响应。

系统“心跳”或“我还活着”信息也是一个不错的选择。失踪不是危机。缺了半打(一排)是。

我在一个同时支持客户端和服务器之间的UDP(IP)和TCP/IP通信的产品上工作。它始于15年前的IPX,13年前又增加了IP支持。我们在3或4年前添加了TCP/IP支持。接下来的猜测是:UDP和TCP的代码比率大概是80/20。该产品是一个数据库服务器,因此可靠性至关重要。我们必须处理其他答案中已经提到的所有由UDP强加的问题(包丢失、包加倍、包顺序等)。很少有问题,但有时确实会发生,因此必须加以处理。支持UDP的好处在于,我们可以根据自己的使用对其进行一些定制,并对其进行一些性能调整。

每个网络都会有所不同,但对于我们来说,UDP通信协议通常要快一点。持怀疑态度的读者会正确地质疑我们是否正确地实现了一切。另外,你对一个2位数的人有什么期望呢?尽管如此,我只是出于好奇才进行了一次测试。测试读取100万条记录(从SomeTable中选择*)。我将每个客户机请求返回的记录数设置为1、10,然后是100(每个协议有三次测试运行)。服务器距离100mbit局域网只有两步之遥。这些数字似乎与其他人在过去的发现一致(大多数情况下,UDP速度大约快5%)。此特定测试的总时间(毫秒)如下:

1. 1记录
   • IP:390760毫秒
   • TCP:416903毫秒
2. 10记录
   • IP:91707毫秒
   • TCP:95662毫秒
3. 100记录
   • IP:29664毫秒
   • TCP:30968毫秒

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

udp是一种无连接的协议,用于诸如snmp(简单网络管理协议)、dns(域名系统)等应用程序中,在这些应用程序中,数据包的到达顺序不正确、不可靠且不受关注,并且数据包的直接发送很重要。

由于UDP不涉及连接建立,因此在需要避免连接建立延迟的应用程序(如DNS)中,UDP比TCP更受欢迎。

在SNMP中,作为网络管理的应用必须经常在网络压力下进行,即在可靠、拥塞控制的数据传输难以实现的情况下。

干杯

udp确实开销较小,并且适合处理诸如音频或视频之类的实时数据流,或者在任何情况下,如果数据丢失,也可以这样做。

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

因为UDP不使用拥塞控制,所以它可以更快,延迟也更低,因为它不会寻求将缓冲区最大化到丢弃点,也就是说,UDP包在缓冲区中花费的时间更少,并且以更低的延迟更快地到达缓冲区。因为UDP不采用拥塞控制,而TCP采用拥塞控制,所以它可以从产生UDP流的TCP中剥夺容量。

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

结果是,UDP可以:

• 只要网络丢弃率在应用程序可以处理的限制范围内,就可以实现比TCP更高的吞吐量。
• 传输数据包比TCP更快,延迟更少。
• 设置连接速度更快,因为没有初始握手来设置连接
• 传输多播数据包,而TCP必须使用多个连接。
• 传输固定大小的数据包,而TCP则以段的形式传输数据。如果您传输一个300字节的UDP数据包,您将在另一端接收300字节。使用TCP,您可以向发送套接字发送300个字节,但是接收器只读取100个字节,您必须以某种方式确定还有200个字节在发送中。如果应用程序发送固定大小的消息,而不是字节流,则这一点很重要。

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

我所知道的这个问题的最佳答案之一来自 user zAy0LfpBZLC8mAC at Hacker News . 这个答案太好了,我只想原封不动地引用一下。

TCP具有队列头阻塞,因为它保证完整和有序 因此,当一个包在传输过程中丢失时,它必须等待 重新传输丢失的数据包,而UDP将数据包传递到 申请书,包括副本,无任何副本 保证一个包裹全部到达或他们到达的订单(它 实际上是具有端口号和(可选)有效负载的IP 添加了校验和),但这对于电话来说是很好的,例如 通常只要几毫秒的音频 不见了,但是耽搁很烦人,所以你不必费心 重传,你只需丢弃任何重复的数据包,将重新排序的数据包排序到 几百毫秒抖动缓冲的正确顺序,以及 如果数据包没有及时出现或者根本没有出现,它们就被跳过了, 可能在编解码器支持的情况下插入。

另外,TCP的一个主要部分是流控制,以确保 尽可能多的吞吐量,但不会使网络过载 有点多余,因为超载的网络会丢掉你的数据包, 这意味着您必须重新传输,这会影响吞吐量),udp 没有任何这样的功能-这对于像 电话,因为具有给定编解码器的电话需要一定数量的 带宽,你不能“减速”,而且额外的带宽也 不会让通话更快。

除了实时/低延迟应用程序外,UDP对 非常小的事务,比如DNS查找,仅仅因为 没有TCP连接建立和拆卸开销, 无论是在延迟方面还是在带宽使用方面。如果你 请求小于一个典型的MTU,而repsonse可能是, 你也可以一次往返,不需要保持任何状态 在服务器上,以及流控制ALS排序和所有这些 对于这种用途也不是特别有用。

然后,您可以使用udp来构建自己的tcp替换。 当然,但如果没有一些深度的话,这可能不是一个好主意。 了解网络动态,现代的TCP算法很漂亮 复杂的。

另外,我想应该提到的是,除了UDP和 TCP,如SCTP和DCCP。目前唯一的问题是 (ipv4)互联网上充满了nat网关,这使得它不可能 在最终用户应用程序中使用除UDP和TCP之外的协议。

udp的开销较低,正如前面所述,对于视频和音频之类的流媒体来说已经很好了,在这种情况下,最好先丢失一个包,然后再尝试重新发送并赶上。

TCP传输没有保证,只需告诉您套接字是否断开连接,或者基本上数据是否不会到达。否则它会在到达那里时到达那里。

人们忘记的一件大事是,udp是基于包的,tcp是基于字节流的,不能保证你发送的“tcp包”是出现在另一端的包,它可以被分解成路由器和堆栈所需要的任意多的包。因此,您的软件有额外的开销,将字节解析回可用的数据块,这可能需要相当多的开销。UDP可能不正常,因此如果您愿意,您必须对数据包进行编号,或者使用其他机制来重新排序。但是,如果您得到了这个UDP包,它将以与离开时相同的顺序到达所有相同的字节,不会发生任何更改。因此,术语udp包是有意义的,但tcp包并不一定。TCP有自己的重新尝试和排序机制,这对您的应用程序来说是隐藏的,您可以用UDP重新发明它,使其适合您的需要。

UDP在两端编写代码要容易得多,基本上是因为您不必建立和维护点对点连接。我的问题通常是,您希望TCP开销出现在什么情况下?如果你走捷径,比如假设接收到的TCP“包”是发送的完整包,你会过得更好吗?(如果您要检查长度/内容,可能会丢弃两个数据包)

视频流是使用UDP的完美例子。

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

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

在某些情况下,其他人强调,包的保证到达并不重要,因此使用UDP是可以的。在其他情况下,UDP优于TCP。

一种独特的情况是,您希望使用UDP而不是TCP,在这种情况下,您将通过另一个协议(例如隧道、虚拟网络等)来隧道TCP。如果您通过TCP来隧道TCP,那么每个TCP的拥塞控制将互相干扰。因此,人们通常更喜欢通过UDP(或其他一些无状态协议)来隧道TCP。参见TechRepublic文章: Understanding TCP Over TCP: Effects of TCP Tunneling on End-to-End Throughput and Latency .

关键问题与“UDP在哪种情况下比TCP更好”有关。

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

随着移动应用程序的大量增长,以及与之配套的“偶尔连接”或“偶尔断开连接”模式,在某些情况下,当连接很难实现时,TCP尝试维护连接的开销肯定会导致UDP及其“面向消息”性质的强大案例。

现在我不知道这方面的数学/研究/数字,但是我已经开发出了一些应用程序,这些应用程序在UDP上使用ACK/NAK和消息编号时比在TCP上工作更可靠,而在连接能力一般较差的情况下,旧的TCP只是花时间和我的客户的钱来连接。你可以在许多西方国家的地区和农村地区找到这个……

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

udp当速度是必需的,而准确性如果包不是,而tcp当你需要准确性。

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

这并不总是一帆风顺的。但是,如果您需要保证不丢失、按正确顺序发送数据包,那么TCP可能就是您想要的。

另一方面,UDP适合于在信息序列不太重要或数据可以放入单个数据包的情况下传输短信息包。 小包裹。

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

其他时候,在发送顺序数据时是合适的,但是如果其中一些数据丢失了 错过你不太关心(例如VoIP应用程序)。

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

使用地点/可使用地点示例 1)时间服务器向局域网上的一组机器广播正确的时间。 2)VoIP协议 3)DNS查找 4)请求LAN服务,例如,您在哪里? 5)互联网广播 6)还有许多其他的……

在Unix上,您可以键入grep-udp/etc/services以获取已实现的udp协议列表。 今天…有几百个。

看看史蒂文的第22.4节 Unix Network Programming “何时使用UDP而不是TCP”。

另外,看看这另一个所以回答关于 the misconception that UDP is always faster than TCP .

史蒂文的话可以概括为:

• 使用UDP进行广播和多播,因为这是您唯一的选择(对任何新应用使用多播)
• 您可以将UDP用于简单的请求/回复应用程序,但您需要构建自己的确认、超时和重新传输。
• 不要使用UDP进行批量数据传输。

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

1. 适用于需要简单请求-响应通信的进程。
2. 适用于具有内部流程、误差控制的过程
3. 适用于宽频铸造和多播

具体示例:

• 在SNMP中的应用
• 用于某些路由更新协议,如RIP

与TCP和UDP相比,UDP等无连接协议保证了数据包传输的速度,但不能保证数据包传输的可靠性。 例如,在视频游戏中,通常不需要可靠的网络,但速度是最重要的,而在游戏中使用UDP具有减少网络延迟的优势。

如果在传输过程中丢失一些数据不会完全破坏正在传输的数据,则需要使用TCP上的UDP。它的很多用途都是在实时应用程序中,例如游戏(即,fps,在这种应用程序中,你不必总是知道每个玩家在任何给定的时间都在哪里,如果一路上丢失了一些数据包,新的数据将正确地告诉你玩家在哪里),以及实时视频流(一个损坏的帧不会破坏观看体验)。)。

我们的网络服务有成千上万的winforms客户机在尽可能多的PC上。这些PC与数据库后端没有连接,所有的访问都是通过网络服务进行的。因此,我们决定开发一个在UDP端口上侦听的中央日志服务器,并且所有客户机都发送一个XML错误日志包(使用log4net udp appender),该包在收到后被转储到一个db表。由于我们不关心是否遗漏了一些错误日志,而且对于成千上万的客户机,专用日志记录服务不加载主Web服务的速度很快。

当TCP可能工作时,我有点不愿意建议使用UDP。问题是,如果TCP由于某种原因不能工作,因为连接太慢或拥塞,将应用程序更改为使用UDP不太可能有帮助。一个不好的连接对UDP也是不好的。TCP已经很好地减少了拥塞。

我能想到的唯一一个需要UDP的情况是广播协议。在一个应用程序涉及两个已知主机的情况下,UDP可能只提供边际性能优势,从而大幅增加代码复杂性的成本。

只有当你真正知道自己在做什么的时候才使用UDP。目前,UDP的情况极为罕见,但试图将其应用到任何地方的专家(甚至是经验丰富的专家)的数量似乎不相称。也许他们喜欢自己实现错误处理和连接维护代码。

由于TCP被称为 校验和印记 . 令人惊讶的是,在连接速度很快的情况下(例如1Gbps),计算校验和对于CPU来说是一个很大的负载,所以它是 卸载到NIC硬件 它可以识别用于印记的TCP数据包,并且不会为您提供相同的服务。

对于需要发送数据包的VOIP地址来说,UDP是完美的,它的可靠性较低。 视频聊天是UDP的一个例子(您可以在任何视频聊天期间通过Wireshark网络捕获来检查它)。 另外,TCP不适用于DNS和SNMP协议。 UDP没有任何开销,而TCP有很多开销