因为TCP保证数据包的传递,因此可以被认为是“可靠的”,而UDP不保证任何东西,数据包可能会丢失。在应用程序中使用UDP而不是TCP流传输数据的优势是什么?在什么情况下UDP是更好的选择,为什么?
我假设UDP更快,因为它没有创建和维护流的开销,但如果一些数据从未到达目的地,这不是无关紧要的吗?
因为TCP保证数据包的传递,因此可以被认为是“可靠的”,而UDP不保证任何东西,数据包可能会丢失。在应用程序中使用UDP而不是TCP流传输数据的优势是什么?在什么情况下UDP是更好的选择,为什么?
我假设UDP更快,因为它没有创建和维护流的开销,但如果一些数据从未到达目的地,这不是无关紧要的吗?
当前回答
视频流是使用UDP的一个很好的例子。
其他回答
UDP确实有更少的开销,适合做一些事情,比如流式实时数据,如音频或视频,或者在任何情况下,如果数据丢失是ok的。
当TCP可以工作时,我有点不情愿建议使用UDP。问题是,如果TCP由于某种原因不能工作,因为连接太延迟或拥塞,将应用程序更改为使用UDP不太可能有帮助。一个坏的连接对UDP也不好。TCP在减少拥塞方面已经做得很好了。
我能想到的唯一需要UDP的情况是广播协议。在应用程序涉及两个已知主机的情况下,UDP可能只会提供边际的性能优势,而代码复杂性的成本则会大幅增加。
UDP can be used when an app cares more about "real-time" data instead of exact data replication. For example, VOIP can use UDP and the app will worry about re-ordering packets, but in the end VOIP doesn't need every single packet, but more importantly needs a continuous flow of many of them. Maybe you here a "glitch" in the voice quality, but the main purpose is that you get the message and not that it is recreated perfectly on the other side. UDP is also used in situations where the expense of creating a connection and syncing with TCP outweighs the payload. DNS queries are a perfect example. One packet out, one packet back, per query. If using TCP this would be much more intensive. If you dont' get the DNS response back, you just retry.
UDP的“不可靠性”是一种形式主义。传播并不能绝对保证。实际上,他们几乎总是能通过。它们只是在暂停后不被确认和重试。
协商TCP套接字和握手TCP数据包的开销是巨大的。真的很大。没有明显的UDP开销。
最重要的是,您可以轻松地用一些可靠的传输握手来补充UDP,开销比TCP要少。读这个:http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
UDP对于在发布-订阅类型的应用程序中广播信息非常有用。IIRC, TIBCO大量使用UDP来通知状态变化。
任何其他类型的单向“重要事件”或“日志记录”活动都可以用UDP包很好地处理。您希望在不构造整个套接字的情况下发送通知。你不期望从不同的听众那里得到任何回应。
系统“心跳”或“我还活着”消息也是一个不错的选择。错过一个不是危机。(连续)少了半打就是。
在某些情况下,如果丢失一些数据不会完全破坏正在传输的数据,则应该使用UDP而不是TCP。它的很多应用都是在实时应用中,比如游戏(例如FPS,你不需要知道每个玩家在特定时间的位置,如果你丢失了一些数据包,新的数据会正确地告诉你玩家在哪里),以及实时视频流(一个损坏的帧不会破坏观看体验)。