什么时候用UDP代替TCP比较合适?

视频流是使用UDP的一个很好的例子。

UDP确实有更少的开销，适合做一些事情，比如流式实时数据，如音频或视频，或者在任何情况下，如果数据丢失是ok的。

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

例子包括视频流，特别是网络电话(例如Skype)。然而，在这些情况下，一个掉落的包并不是什么大问题:我们的感官并不完美，所以我们甚至可能不会注意到。这就是为什么这些类型的应用程序使用UDP而不是TCP。

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

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

最重要的是，您可以轻松地用一些可靠的传输握手来补充UDP，开销比TCP要少。读这个:http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

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

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

系统“心跳”或“我还活着”消息也是一个不错的选择。错过一个不是危机。(连续)少了半打就是。

在某些情况下，如果丢失一些数据不会完全破坏正在传输的数据，则应该使用UDP而不是TCP。它的很多应用都是在实时应用中，比如游戏(例如FPS，你不需要知道每个玩家在特定时间的位置，如果你丢失了一些数据包，新的数据会正确地告诉你玩家在哪里)，以及实时视频流(一个损坏的帧不会破坏观看体验)。

UDP是一种无连接协议，用于SNMP和DNS等协议，在这些协议中，无序到达的数据包是可以接受的，数据包的即时传输很重要。

在SNMP中使用它是因为网络管理通常必须在网络处于压力状态时进行，即当可靠的、拥塞控制的数据传输难以实现时。

它用于DNS，因为它不涉及连接建立，从而避免了连接建立延迟。

干杯

当应用程序更关心“实时”数据而不是精确的数据复制时，可以使用UDP。例如，VOIP可以使用UDP，应用程序会担心重新排序数据包，但最终VOIP不需要每个数据包，更重要的是需要许多数据包的连续流。也许你在这里听到了声音质量的“故障”，但主要目的是你得到消息，而不是它在另一边被完美地重新创建。UDP也用于创建连接和与TCP同步的费用超过有效负载的情况。DNS查询就是一个很好的例子。每次查询，一个数据包发送，一个数据包返回。如果使用TCP，这将更加密集。如果您没有得到DNS响应，请重试。

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

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

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

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

电子游戏的网络通信几乎都是通过UDP完成的。

速度是最重要的，如果错过更新也无关紧要，因为每次更新都包含玩家所能看到的完整当前状态。

UDP具有较低的开销，如前所述，它对视频和音频等流媒体很好，最好只是丢失一个数据包，然后尝试重新发送和追赶。

TCP传输没有保证，你只是被告知套接字是否断开，或者数据是否没有到达。否则它会在到达目的地的时候到达目的地。

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

UDP更容易在两端编写代码，基本上是因为你不需要建立和维护点到点连接。我的问题是在什么情况下你需要TCP开销?如果你走捷径，比如假设接收到的tcp“数据包”是发送的完整数据包，你会更好吗?(如果你费心检查长度/内容，你可能会扔掉两个包)

在某些情况下，保证数据包的到达并不重要，因此使用UDP是可以的。在其他情况下，UDP比TCP更可取。

你想要使用UDP而不是TCP的一个独特情况是你在另一个协议(例如隧道，虚拟网络等)上建立TCP隧道。如果您在TCP上建立隧道，则每个TCP的拥塞控制将相互干扰。因此，人们通常更喜欢在UDP(或其他无状态协议)上传输TCP。参见TechRepublic文章:理解TCP Over TCP: TCP隧道对端到端吞吐量和延迟的影响。

UDP在需要速度时使用，如果数据包不需要，则使用精度，而TCP在需要精度时使用。

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

当TCP可以工作时，我有点不情愿建议使用UDP。问题是，如果TCP由于某种原因不能工作，因为连接太延迟或拥塞，将应用程序更改为使用UDP不太可能有帮助。一个坏的连接对UDP也不好。TCP在减少拥塞方面已经做得很好了。

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

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

每个网络都是不同的，但UDP通信协议通常对我们来说要快一些。持怀疑态度的读者会正确地质疑我们是否正确地执行了所有内容。另外，你还能指望一个拥有两位数业绩的人怎么样?尽管如此，出于好奇，我刚刚进行了一个测试。测试读取了100万条记录(从sometable中选择*)。我将每个客户端请求返回的记录数量设置为1、10和100(每个协议运行三次测试)。服务器在100Mbit LAN上只有两跳远。这些数字似乎与其他人过去的发现一致(UDP在大多数情况下要快5%左右)。该测试的总时间(以毫秒为单位)如下所示:

<李> 1记录
• IP: 390760 ms
• TCP: 416,903毫秒
李< / ul > < / > <李> 10记录
• IP: 91,707 ms
• TCP: 95,662毫秒
李< / ul > < / > <李> 100条记录
• IP: 29,664 ms
• TCP: 30,968毫秒
李< / ul > < / >

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

这并不总是明确的。然而，如果您需要保证数据包以正确的顺序无丢失地传递，那么TCP可能是您想要的。

当您希望向许多用户广播相同的信息时，这种方法也很合适。

其他时候，当你发送序列数据时，它是合适的，但如果它的一些 缺少你不太关心的东西(例如VOIP应用程序)。

它在哪里/可以使用的例子 1)时间服务器向局域网上的一堆机器广播正确的时间。 2) VOIP协议 3) DNS查找 4)请求局域网服务，例如:where are you? 5)网络电台 6)和许多其他的…

在unix上，您可以输入grep udp /etc/services以获得实现的udp协议列表 今天……有上百个

我们有web服务，在许多电脑上有数千个winforms客户端。pc与DB后端没有连接，所有访问都是通过web服务。因此，我们决定开发一个中央日志服务器，在UDP端口上监听，所有客户端发送一个xml错误日志包(使用log4net UDP appender)，在收到时转储到DB表。因为我们真的不关心是否错过了一些错误日志，并且有数千个客户端，所以使用专用的日志服务不加载主web服务是很快的。

只使用UDP，如果你真的知道你在做什么。UDP在今天是在极其罕见的情况下，但数量(甚至非常有经验)专家谁会试图坚持到处似乎是不成比例。也许他们喜欢自己实现错误处理和连接维护代码。

由于所谓的校验和印记，使用现代网络接口卡，TCP应该会快得多。令人惊讶的是，在快速连接速度下(比如1Gbps)，计算校验和对CPU来说是一个很大的负载，所以是卸载到网卡硬件识别TCP数据包的印记，它不会提供相同的服务。

请看Steven Unix网络编程的22.4节，“何时使用UDP而不是TCP”。

另外，请参阅关于UDP总是比TCP快的误解的另一个SO答案。

史蒂文的话可以总结如下:

• 使用UDP广播和组播，因为这是你唯一的选择(任何新的应用程序使用组播)
• 你可以在简单的请求/回复应用中使用UDP，但你需要构建自己的ack、超时和重传
• 不要使用UDP进行批量数据传输。

关键的问题是“在什么情况下UDP是更好的选择[而不是tcp]”

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

随着移动应用程序的大量增长，以及“偶尔连接”或“偶尔断开”的范式，在很难获得连接的情况下，TCP试图维持连接的开销肯定会导致UDP及其“面向消息”的性质的强烈情况。

现在我没有数学/研究/数字，但我制作的应用程序使用ACK/NAK和UDP上的消息编号比使用TCP更可靠，当时连接通常很差，可怜的旧TCP只是花费了时间和客户的金钱来尝试连接。在许多西方国家的地区和农村地区都有这种情况....

我们知道UDP是一种无连接协议，的确如此

1. 适用于需要简单请求-响应通信的流程。
2. 适用于有内部流动、误差控制的工艺
3. 适用于广泛铸造和多播

具体的例子:

• 用于SNMP
• 用于RIP等路由更新协议

我所知道的这个问题的最好答案之一来自用户zAy0LfpBZLC8mAC在黑客新闻。这个答案太好了，我就原原本本地引用它吧。

TCP具有队列首阻塞，因为它保证了完整和有序 传输，所以当一个包在传输中丢失时，它必须等待一个 重发送丢失的数据包，而UDP将数据包发送到 申请，包括副本和没有任何副本 保证一个数据包到达或他们到达的顺序(它 实际上是带有端口号和有效载荷(可选)的IP 校验和添加)，但这是很好的电话，例如，在那里 通常情况下，几毫秒的音频并不重要 思念，只是耽误很烦，所以你不要再烦了 重传，你只需要删除所有重复的，重新排序的数据包 正确的顺序几百毫秒的抖动缓冲器，和 如果数据包没有及时出现或根本没有出现，它们就会被跳过， 在编解码器支持的地方可能插入 同样，TCP的一个主要部分是流控制，以确保你得到 尽可能多的吞吐量，但不会使网络过载(这 有点多余，因为过载的网络会丢包， 这意味着你必须重传，这会影响吞吐量)，UDP 这些都没有，这对应用程序来说是有意义的 电话，因为电话与给定的编解码器需要一定数量的 带宽，你不能“放慢它”，而额外的带宽也

除了实时/低延迟应用程序，UDP也适用于 真正的小事务，如DNS查找，只是因为它 没有TCP连接建立和拆除的开销， 在延迟和带宽使用方面。如果你的 请求小于典型的MTU，响应可能是， 同样，您可以在一次往返中完成，而不需要保持任何状态 在服务器上，流控制可能是在排序

然后，你可以使用UDP来构建你自己的TCP替换 当然，但如果没有深层的 了解网络动态，现代TCP算法都很不错 复杂。< / p > 此外，我想应该提到的是，有超过UDP和 TCP协议，如SCTP、DCCP等。目前唯一的问题是 (IPv4)互联网充满了NAT网关，这使得它不可能 在终端用户应用程序中使用UDP和TCP以外的协议

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

UDP是完美的VoIP地址，其中数据包必须发送而不考虑其可靠性… 视频聊天是UDP的一个例子(你可以在任何视频聊天期间通过wireshark网络捕获来检查它)。 而且TCP不能与DNS和SNMP协议一起使用。 UDP没有任何开销，而TCP有很多开销