因为TCP保证数据包的传递,因此可以被认为是“可靠的”,而UDP不保证任何东西,数据包可能会丢失。在应用程序中使用UDP而不是TCP流传输数据的优势是什么?在什么情况下UDP是更好的选择,为什么?
我假设UDP更快,因为它没有创建和维护流的开销,但如果一些数据从未到达目的地,这不是无关紧要的吗?
因为TCP保证数据包的传递,因此可以被认为是“可靠的”,而UDP不保证任何东西,数据包可能会丢失。在应用程序中使用UDP而不是TCP流传输数据的优势是什么?在什么情况下UDP是更好的选择,为什么?
我假设UDP更快,因为它没有创建和维护流的开销,但如果一些数据从未到达目的地,这不是无关紧要的吗?
当前回答
这是我最喜欢的问题之一。UDP被误解了。
当你真的想快速地向另一个服务器得到一个简单的答案时,UDP是最好的选择。通常,您希望答案在一个响应包中,并准备实现自己的协议以提高可靠性或重新发送。DNS是这个用例的完美描述。连接设置的成本太高了(然而,DNS 不支持TCP模式以及)。
另一种情况是,当您交付的数据可能会丢失,因为新的数据将取代之前的数据/状态。天气数据、视频流、股票报价服务(不用于实际交易)或游戏数据浮现在脑海中。
另一种情况是,当您正在管理大量的状态时,您希望避免使用TCP,因为操作系统无法处理那么多会话。这在今天是一个罕见的案例。事实上,现在可以使用用户专用的TCP堆栈,以便应用程序编写人员可以对该TCP状态所需的资源进行更细粒度的控制。在2003年之前,UDP是唯一的游戏。
另一种情况是多播流量。UDP可以多播到多个主机,而TCP根本不能这样做。
其他回答
UDP的“不可靠性”是一种形式主义。传播并不能绝对保证。实际上,他们几乎总是能通过。它们只是在暂停后不被确认和重试。
协商TCP套接字和握手TCP数据包的开销是巨大的。真的很大。没有明显的UDP开销。
最重要的是,您可以轻松地用一些可靠的传输握手来补充UDP,开销比TCP要少。读这个:http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
UDP对于在发布-订阅类型的应用程序中广播信息非常有用。IIRC, TIBCO大量使用UDP来通知状态变化。
任何其他类型的单向“重要事件”或“日志记录”活动都可以用UDP包很好地处理。您希望在不构造整个套接字的情况下发送通知。你不期望从不同的听众那里得到任何回应。
系统“心跳”或“我还活着”消息也是一个不错的选择。错过一个不是危机。(连续)少了半打就是。
当TCP可以工作时,我有点不情愿建议使用UDP。问题是,如果TCP由于某种原因不能工作,因为连接太延迟或拥塞,将应用程序更改为使用UDP不太可能有帮助。一个坏的连接对UDP也不好。TCP在减少拥塞方面已经做得很好了。
我能想到的唯一需要UDP的情况是广播协议。在应用程序涉及两个已知主机的情况下,UDP可能只会提供边际的性能优势,而代码复杂性的成本则会大幅增加。
如果TCP数据包丢失,将重新发送。这对于依赖于以特定顺序实时处理数据的应用程序来说并不方便。
例如视频流,特别是VoIP(例如Skype)。然而,在这些情况下,一个掉落的包并不是什么大问题:我们的感官并不完美,所以我们甚至可能不会注意到。这就是为什么这些类型的应用程序使用UDP而不是TCP。
UDP确实有更少的开销,适合做一些事情,比如流式实时数据,如音频或视频,或者在任何情况下,如果数据丢失是ok的。
请参阅Steven的Unix网络编程的22.4节,“何时使用UDP而不是TCP”。
另外,请参阅关于UDP总是比TCP更快的误解的其他SO回答。
史蒂文的话可以总结如下:
使用UDP广播和组播,因为这是你唯一的选择(任何新的应用程序使用组播) 你可以在简单的请求/回复应用中使用UDP,但你需要构建自己的ack、超时和重传 不要使用UDP进行批量数据传输。