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

Question

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

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

Answer 1

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

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

另一种情况是，当您提供可能丢失的数据时，因为新的数据将替换之前的数据/状态。想到天气数据，视频流，股票报价服务（不用于实际交易）或游戏数据。

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

Answer 4

我的产品支持客户端和服务器之间的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. 1条记录
   • IP：390,760 ms
   • TCP：416,903 ms
2. 10条记录
   • IP：91,707 ms
   • TCP：95,662 ms
3. 100条记录
   • IP：29,664 ms
   • TCP：30,968 ms

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

Answer 5

UDP是一种无连接协议，用于SNMP（简单网络管理协议），DNS（域名系统）等应用程序，其中数据包无序到达，不可靠且无关紧，并立即通过数据包发送事情..

由于UDP不涉及连接建立，因此需要避免连接建立延迟等DNS应用，而UDP优先于TCP。

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

欢呼声

Answer 6

这里已经有很多好的答案，但我想添加一个非常的重要因素以及摘要。 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速度非常快，延迟低，不受连接拥塞的影响，传输固定大小的数据报，可用于组播。

Answer 7

UDP确实具有较少的开销，并且适用于像流式传输实时数据（如音频或视频），或者在任何情况下，如果数据丢失都可以。

Answer 8

我对此问题的最佳答案之一来自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以外的协议。

Answer 9

UDP具有较低的开销，如上所述已经适用于视频和音频之类的流媒体，其中最好丢失数据包然后尝试重新发送并赶上。

无法保证TCP传输，您应该被告知是否断开连接，或者基本上是否数据不会到达。否则它会到达那里。

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

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

Answer 10

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

Answer 11

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

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

Answer 12

在某些情况下，其他人突出显示，保证数据包的到达并不重要，因此使用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。

Answer 13

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

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

随着移动应用程序的大量增长，以及随之而来的“偶尔连接”或“偶尔断开连接”的范例，当然有些情况下，当连接难以通过时，TCP尝试维持连接的开销对于UDP及其“面向消息”性质的强有力的案例。

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

Answer 14

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

Answer 15

我们知道UDP是一种无连接协议，因此它是

1. 适用于需要简单的请求 - 响应通信的过程。
2. 适用于具有内部流程，错误控制的过程
3. 适合广泛的铸造和多播

具体例子：

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

Answer 16

请参阅Steven的Unix Network Programming第22.4节，“何时使用UDP而不是TCP”。

另外，请参阅另一个关于the misconception that UDP is always faster than TCP的其他答案。

史蒂文所说的可以总结如下：

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

Answer 17

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

另一方面，UDP适用于传输短信息包，其中信息序列不太重要或者数据可以放入单个信息中 分组。

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

其他时候，当您发送有序数据时，它是合适的，但如果有的话 想你不太关心（例如VOIP申请）。

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

可以使用/可以使用的示例 1）时间服务器向LAN上的一堆机器广播正确的时间。 2）VOIP协议 3）DNS查找 4）请求LAN服务，例如你在哪？ 5）网络电台 6）和其他许多人......

在unix上，您可以键入grep udp / etc / services以获取已实现的UDP协议列表 今天......有数百个。

Answer 18

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

UDP通常更难以编写程序，使其不依赖于数据包的准确性。

Answer 19

当应用程序更关心“实时”数据而非精确数据复制时，可以使用

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

Answer 20

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

Answer 21

如果在此过程中丢失一些数据不会完全破坏正在传输的数据，则需要使用UDP over TCP。它的很多用途都是在实时应用程序中，例如游戏（即FPS，你不必总是知道每个玩家在任何特定时间的位置，如果你在途中丢失了一些数据包，那么新的数据会正确告诉你玩家在哪里），以及实时视频流（一个损坏的帧不会破坏观看体验）。

Answer 22

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

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

Answer 23

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

由于所谓的校验和印记，使用现代网络接口卡的TCP应该会更快。令人惊讶的是，在快速连接速度（例如1Gbps）下，计算校验和将是CPU的一大负载，因此卸载到NIC硬件可识别TCP数据包以进行打印，并且它不会为您提供相同的服务。

Answer 24

UDP是完美的VoIP寻址，必须发送数据包的可靠性较低...... 视频聊天是UDP的一个例子（您可以在任何视频聊天期间通过wireshark网络捕获来检查它）。 TCP也不能与DNS和SNMP协议一起使用。 当TCP有大量的开销

时，UDP没有任何开销