因为TCP保证数据包的传递,因此可以被认为是“可靠的”,而UDP不保证任何东西,数据包可能会丢失。在应用程序中使用UDP而不是TCP流传输数据的优势是什么?在什么情况下UDP是更好的选择,为什么?
我假设UDP更快,因为它没有创建和维护流的开销,但如果一些数据从未到达目的地,这不是无关紧要的吗?
因为TCP保证数据包的传递,因此可以被认为是“可靠的”,而UDP不保证任何东西,数据包可能会丢失。在应用程序中使用UDP而不是TCP流传输数据的优势是什么?在什么情况下UDP是更好的选择,为什么?
我假设UDP更快,因为它没有创建和维护流的开销,但如果一些数据从未到达目的地,这不是无关紧要的吗?
当前回答
关键的问题是“在什么情况下UDP是更好的选择[而不是tcp]”
上面有很多很好的答案,但是缺少的是对传输不确定性对TCP性能影响的正式、客观的评估。
随着移动应用程序的大量增长,以及“偶尔连接”或“偶尔断开”的范式,在很难获得连接的情况下,TCP试图维持连接的开销肯定会导致UDP及其“面向消息”的性质的强烈情况。
现在我没有数学/研究/数字,但我制作的应用程序使用ACK/NAK和UDP上的消息编号比使用TCP更可靠,当时连接通常很差,可怜的旧TCP只是花费了时间和客户的金钱来尝试连接。在许多西方国家的地区和农村地区都有这种情况....
其他回答
电子游戏的网络通信几乎都是通过UDP完成的。
速度是最重要的,如果错过更新也无关紧要,因为每次更新都包含玩家所能看到的完整当前状态。
在某些情况下,如果丢失一些数据不会完全破坏正在传输的数据,则应该使用UDP而不是TCP。它的很多应用都是在实时应用中,比如游戏(例如FPS,你不需要知道每个玩家在特定时间的位置,如果你丢失了一些数据包,新的数据会正确地告诉你玩家在哪里),以及实时视频流(一个损坏的帧不会破坏观看体验)。
这并不总是明确的。然而,如果您需要保证数据包以正确的顺序无丢失地传递,那么TCP可能是您想要的。
另一方面,UDP适用于传输信息的短数据包,其中信息的顺序不太重要,或者数据可以放入单个数据包中 包。
当您希望向许多用户广播相同的信息时,这种方法也很合适。
其他时候,当您正在发送序列数据时,它是合适的,但如果有些数据丢失了 错过你不太关心的(例如VOIP应用程序)。
有些协议更复杂,因为需要的是TCP的一些(但不是全部)功能,但比UDP提供的功能更多。这就是应用层必须做到的 实现附加功能。在这些情况下,UDP也是合适的(例如,互联网广播,顺序很重要,但不是每个数据包都需要通过)。
它在哪里/可以被使用的例子 1)时间服务器向局域网上的一堆机器广播正确的时间。 2) VOIP协议 3) DNS查找 4)请求局域网服务,例如:where are you? 5)网络电台 还有许多其他的……
在unix上,您可以输入grep udp /etc/services以获得实现的udp协议列表 今天……有几百个。
这是我最喜欢的问题之一。UDP被误解了。
当你真的想快速地向另一个服务器得到一个简单的答案时,UDP是最好的选择。通常,您希望答案在一个响应包中,并准备实现自己的协议以提高可靠性或重新发送。DNS是这个用例的完美描述。连接设置的成本太高了(然而,DNS 不支持TCP模式以及)。
另一种情况是,当您交付的数据可能会丢失,因为新的数据将取代之前的数据/状态。天气数据、视频流、股票报价服务(不用于实际交易)或游戏数据浮现在脑海中。
另一种情况是,当您正在管理大量的状态时,您希望避免使用TCP,因为操作系统无法处理那么多会话。这在今天是一个罕见的案例。事实上,现在可以使用用户专用的TCP堆栈,以便应用程序编写人员可以对该TCP状态所需的资源进行更细粒度的控制。在2003年之前,UDP是唯一的游戏。
另一种情况是多播流量。UDP可以多播到多个主机,而TCP根本不能这样做。
UDP具有较低的开销,如前所述,它对视频和音频等流媒体很好,最好只是丢失一个数据包,然后尝试重新发送和追赶。
TCP传输没有保证,你只是被告知套接字是否断开,或者数据是否没有到达。否则它会在到达目的地的时候到达目的地。
A big thing that people forget is that udp is packet based, and tcp is bytestream based, there is no guarantee that the "tcp packet" you sent is the packet that shows up on the other end, it can be dissected into as many packets as the routers and stacks desire. So your software has the additional overhead of parsing bytes back into usable chunks of data, that can take a fair amount of overhead. UDP can be out of order so you have to number your packets or use some other mechanism to re-order them if you care to do so. But if you get that udp packet it arrives with all the same bytes in the same order as it left, no changes. So the term udp packet makes sense but tcp packet doesnt necessarily. TCP has its own re-try and ordering mechanism that is hidden from your application, you can re-invent that with UDP to tailor it to your needs.
UDP更容易在两端编写代码,基本上是因为你不需要建立和维护点到点连接。我的问题是在什么情况下你需要TCP开销?如果你走捷径,比如假设接收到的tcp“数据包”是发送的完整数据包,你会更好吗?(如果你费心检查长度/内容,你可能会扔掉两个包)