什么时候适合使用UDP，而不是TCP？ [关闭] 什么时候适合使用UDP，而不是TCP？ [关

由于TCP保证数据包传输，因此可以被认为是“可靠的”，而UDP并不能保证任何事情和数据包可能会丢失。 这将是在一个应用程序，而不是通过TCP流使用UDP传输数据的优势在哪里？ 在什么样的情况将UDP是更好的选择，为什么？

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

Answer 1:

这是我最喜欢的问题之一。 UDP是如此误解。

在你真的想快速得到一个简单的答案到另一台服务器的情况下，UDP效果最好。 在一般情况下，你想要的答案是在一个响应包，你准备实现自己的可靠性协议或者重新发送。 DNS是该用例的完美描述。 连接设置的成本太高了（但是，DNS不支持TCP模式以及）。

另一种情况是，当您提供的可能会丢失，因为新的数据在未来将取代以前的数据/状态数据。 天气数据，视频流，一个股票行情服务（不用于实际交易），或游戏数据浮现在脑海。

另一种情况是当你管理状态的大量，你要避免使用TCP因为操作系统无法处理如此之多的会议。 这是今天的一个罕见的情况。 事实上，现在有可以使用，使应用程序编写者可以有超过需要的是TCP状态的资源更细粒度的控制用户空间TCP堆栈。 2003年之前，UDP是真正在镇上唯一的游戏。

另一种情况是多播流量。 UDP可以多播到多台主机，而TCP不能做到这一点的。

Answer 2:

如果一个TCP数据包丢失，它会重新发送。 这是不是很方便对于依赖于数据的实时特定的顺序被处理的申请。

例子包括视频流媒体，尤其是网络电话 （如Skype的 ）。 在这些情况下，然而，丢失一个包是不是这样一个大问题：我们的感觉是不完美的，所以我们甚至可能不会注意到。 这就是为什么这些类型的应用程序使用UDP ，而不是TCP。

Answer 3:

在UDP的“不可靠”是形式主义。 传输不是绝对保证。 作为一个实际问题，他们几乎总是打不通。 他们只是不承认并在超时后重试。

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

最重要的是，你可以很容易地与一些可靠的交付握手，这比TCP开销少补充UDP。 阅读： http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

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

任何其他种类的单向“显著事件”或“日志”活动可以很好地与UDP数据包进行处理。 您要发送的通知没有构建一个完整的插座。 你不要指望从不同的听众任何回应。

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

Answer 4:

我对支持UDP（IP）和TCP / IP客户端和服务器之间的通信产品工作。 它早在15年前开始了IPX与IP的支持增加了13年前。 我们3或4年前添加TCP / IP的支持。 胡乱猜测来了：UDP协议TCP代码比例大概是80/20。 该产品是一个数据库服务器，因此可靠性是至关重要的。 我们必须处理所有的在其他的答案已经提到的通过UDP带来的问题（数据包丢失，包加倍，包秩序，等等）。 很少有什么问题，但有时确实会发生，所以必须进行处理。 支持UDP的好处是，我们能够有点定制，以我们自己的使用情况和调整了它更多的性能。

每个网络将是不同的，但UDP通信协议通常是快一点点我们。 持怀疑态度的读者会质疑正确，我们是否正确实施的一切。 此外，你还能从具有2位数代表一个人期待什么呢？ 尽管如此，我刚才跑了测试出于好奇。 该测试读取100万条记录（选择sometable *）。 余设置的记录数与每个单独的客户机请求，返回为1，10，然后100（三个测试与每个协议运行）。 服务器是仅有的两个客场跳在100Mbps的LAN。 这些数字似乎别人对自己过去所发现的同意（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的显示，为下一组的记录的请求是80个字节，UDP和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:

一个最好的答案，我知道这个问题来自于用户zAy0LfpBZLC8mAC在黑客新闻 。 这个答案是那么好，我只是要引用它原样。

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。

一个独特情况下，你会想，而不是使用TCP UDP是你在哪里隧道TCP在另一个协议（如隧道，虚拟网络等）。 如果隧道TCP通过TCP，每个拥塞控制会互相干扰。 因此一个通常倾向于隧道TCP通过UDP（或一些其它的无状态协议）。 见TechRepublic的文章： 了解TCP在TCP：在终端到终端的吞吐量和时延TCP隧道的影响 。

Answer 13:

关键的问题是有关“什么样的情况下将UDP是更好的选择[通过TCP]”

上面有很多伟大的答案，但所缺乏的是运输的不确定性在TCP性能的影响任何正式的，客观的评价。

随着移动应用的迅猛增长，以及“偶尔连接”或“偶尔断线”范式与他们去，当然也有情况下TCP的企图的开销保持连接时连接是很难通过导线来一个强案例UDP和它的“面向消息”的性质。

现在，我没有对这个数学/科研/数字，但我有有更可靠的工作使用和ACK / NAK和消息编号通过UDP不是可以用TCP来实现连接时普遍较差老TCP差产生的应用刚刚度过它的时间和我的客户的钱只是尝试连接。 您在许多西方国家的地区和农村地区得到这个....

Answer 14:

当一个应用程序更在乎的“实时”数据，而不是确切的数据复制UDP可以使用。 例如，VOIP可以使用UDP和应用程序会担心重新排序分组，但最终VOIP并不需要每一个数据包，但更重要的是需要很多人的连续流。 也许你在这里的声音质量“毛刺”，但主要目的是，你得到的消息，而不是它是完全重新创建另一侧。 UDP也被用在情况下创建连接，并与TCP同步远远大于有效载荷的代价。 DNS查询是一个很好的例子。 一个数据包时，一个数据包发送回，每次查询。 如果使用TCP这将是更加密集。 如果你不”获得DNS响应回来，你在执行一次。

Answer 15:

UDP当速度是必要的，如果数据包的准确度是不是和TCP当你需要的精度。

UDP往往更难那就是你必须以这样的方式写你的程序，它不依赖于数据包的准确度。

Answer 16:

这并不总是很明确。 但是，如果你需要保证的分组传输，无损失，正确的顺序则TCP可能是你想要的东西。

在另一方面UDP适合于发送的信息短分组，其中的信息序列是较不重要的或其中数据可以放入单个数据包中。

当你想广播相同信息给许多用户来说，也是适当的。

其他时候，它是在适当的时候你发送的有序数据，但如果它的一些失踪后你不必太在意（如VoIP应用）。

有些协议是比较复杂的，因为我们所需要的TCP的功能有一些（但不是全部），但比UDP提供些什么。 这就是应用层来实现更多的功能。 在这种情况下，UDP也是合适的（如网络电台，顺序很重要，但不是每一个数据包需要打通）。

的，其中它是实施例/可使用1）时间服务器广播的正确时间到LAN上的一堆机器。 2）VoIP协议3）DNS查询4）请求LAN服务例如，你在哪里？ 5）网络电台6）和许多其他...

在Unix上你可以键入grep的UDP / etc / services中获取的今天实现UDP协议列表...有数百个。

Answer 17:

看看史蒂芬的第22.4 unix网络编程 “何时使用UDP而不是TCP的”。

另外，看到这个其他SO回答有关该UDP总是比TCP更快的误解 。

什么史蒂芬的说，可以归纳如下：

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

Answer 18:

我们知道，UDP是无连接的协议，所以它是

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

具体的例子：

• 在使用SNMP
• 用于一些路由更新协议，如RIP

Answer 19:

与UDP比较TCP，UDP等无连接的协议保证速度，但不包传输的可靠性。 例如，在视频游戏通常并不需要一个可靠的网络，但速度是最重要的，使用UDP游戏具有降低网络延迟的优势。

Answer 20:

你想在失去一些沿途的数据不会完全破坏正在传送的数据的情况下使用UDP通过TCP。 很多它的用途是在实时应用，如游戏（即FPS，你并不总是要知道每一名球员在任何给定时间，如果你失去了几包前进的道路上，新数据将正确地告诉你哪里的球员都是这样），以及实时视频流（一个腐败的框架是不会破坏观看体验）。

Answer 21:

我们有有更多的电脑数以千计的WinForms客户端的Web服务。 这些电脑有DB后端没有连接，所有的访问都通过Web服务。 因此，我们决定开发一个监听UDP端口上和所有客户端将在收到被倾倒到一个数据库表中的XML错误日志包（使用log4net的UDP附加目的地）中央日志服务器。 因为我们真的不关心，如果几个错误日志的未接来电和数千客户的速度快了专用日志记录服务不加载主Web服务。

Answer 22:

我有点不情愿建议UDP TCP时可以运转。 问题是，如果TCP工作不因某种原因，因为连接太laggy或拥挤，改变使用UDP是不太可能有帮助的应用程序。 一个坏的连接是坏的UDP了。 TCP已经做最大限度地减少拥堵的一个很好的工作。

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

Answer 23:

仅使用UDP，如果你真的知道自己在做什么。 UDP是当今极为罕见的情况下，但（即使是非常有经验）的专家谁也试图处处坚持下去的数量似乎是不相称的。 也许他们喜欢执行错误处理和连接维护的代码本身。

TCP应该期望与现代网络接口卡更快由于什么作为校验的印记 。 出人意料的是，在计算校验和连接速度快（如1Gbps的）将是一大负荷的CPU，因此被卸载到识别的TCP数据包的印记NIC硬件 ，它不会为您提供相同的服务。

Answer 24:

UDP是完美的VoIP解决其中的数据包必须被送到方面少其可靠性......视频聊天是UDP的例子（你可以在任何视频聊天期间Wireshark的网络捕获检查）。也TCP不工作DNS和SNMP协议。 UDP没有任何开销，同时TCP有很多间接的

文章来源: When is it appropriate to use UDP instead of TCP? [closed]