UDP根本不做任何事情吗？

#1 楼

有趣的观点和问题！
是的，UDP所做的大部分工作是通过定义UDP端口的概念，为使用相同IP地址的多个应用程序共存提供一种标准方法。
令人兴奋的部分UDP并不是网络协议，而是由操作系统和套接字库实现的API。尽管不是UDP规范本身的一部分，但使用POSIX套接字API之类的抽象来轻松开发基于UDP之类协议的软件的能力是Internet协议栈成功的关键。

#2 楼

UDP是一种传输协议，类似于TCP。这意味着它为应用程序提供使用IP的协议。像TCP一样，UDP具有应用程序绑定到的地址（端口），以便发往绑定应用程序的数据报被UDP发送到正确的应用程序。 UDP for IPv4还提供了可选的校验和，但是IPv6需要校验和。
UDP是基于消息的协议，其中TCP是基于流的协议。 UDP对于提供应用程序层协议的某些功能（但不是全部）很有用，并且许多应用程序或应用程序层协议不能利用TCP的可靠性，甚至会受到其可靠性的损害。例如，诸如VoIP，视频甚至游戏之类的实时协议在不再有用之后就无法利用丢失的数据报，因此让TCP重新发送数据将产生不良后果。当您使用VoIP且对方回答时，您想听到的是“你好”，而不是“哦，地狱”。
其他内容（例如多播）是单向的，但是TCP需要建立双向连接在两个应用程序之间，而多播应用程序将数据发送到许多接收者。 TCP不能真正做到这一点，但是将UDP与多播一起使用很容易。

#3 楼

我鼓励您看一下利用UDP的高层协议实际上是如何使用它的。 DNS（最常见的情况是至少在大多数情况下可以通过TCP进行DNS，但实际上并不常见），DHCP，NTP和PTP。
所有这些协议都有一些特定的共同点：

他们关心能够与同一系统上的其他服务共存。
他们关心其消息的某种程度的数据完整性。
它们是面向消息的，而不是面向流的
它们主要涉及非常短且经常不频繁的数据交换。

前两点被包括TCP在内的任何合理的传输层协议（甚至像TIPC这样的奇特的东西）所覆盖。但是，TCP对于其他两点来说是可怕的，因为它要求您将自己的消息框架协议滚动到面向消息的协议的流之上，并且显着的连接启动和维护开销意味着它对于短时间不频繁的数据交换非常低效。换句话说，UDP的“功能”使所有值得担心的地方是，它为前两点提供了最低限度的要求，而不会像这些类型的应用程序那样妨碍您的工作。与TCP相比，它还有一点优势，因为它可以简单地在硬件中实现，也可以在RAM不足1Kb的微型系统上实现，并且代码存储空间也很小（这就是BOOTP，RARP， TFTP和其他引导协议最初使用它）。缺点是，如果在没有非常仔细的管理的情况下对它使用长期的有状态“连接”，就会对某些类型的攻击具有可靠性和易感性，但是使用它并关心它的协议会自己处理（请参阅TFTP）可靠性问题，尽管要牺牲速度）。
现在，有一些选项可以用更少的开销实现与TCP类似的功能集（甚至更全面的功能集），并且仍然允许面向消息的通信（主要示例包括RUDP，DCCP和SCTP），但是它们还没有由于多种原因而流行，因此UDP仍然存在。

#4 楼

重要的一点是，UDP不需要建立“连接”。
例如，如果不是不可能的话，在TCP之上实现DHCP将会非常困难和复杂，即使客户端没有IP地址，零知识的现有网络环境。因此，“建立连接”毫无意义，因为客户端不知道目标地址，也没有源地址。 UDP通过允许向现有网络广播DHCP请求来简化此操作，并且一个（希望只有一个）DHCP服务器将提供一个响应。您无法与“广播目标”建立“连接”，每个主机都接受并做出响应。诸如序号和校验和之类的东西不会累加。
*我们不是在谈论诸如MPI_Bcast()之类的东西。他们真的超出了这个问题的范围。

#5 楼

对我来说，UDP要做的关键是提供源端口号和目标端口号，因此不仅允许多个不同的应用程序协议，而且允许同一应用程序协议的多个实例。
原则上，您可以直接在该协议上构建应用程序协议IP的顶部并为其获取协议号。如果每个主机上只有一个应用程序协议实例，那很好用，但是如果您想在每个主机上有多个相同应用程序协议的实例，它就不能很好地工作。端口号并建立惯例，即客户端使用临时端口，而服务器使用众所周知的端口，并且响应交换端口号，UDP支持在同一主机上使用同一应用协议的多个实例。

#6 楼

它为上层（App）提供多路复用/多路分解服务，因此它可以处理来自不同进程的数据。有了校验和，它也将带给您错误检测。
UDP是这样一种简单的协议，对于更喜欢快速通信而无需建立连接或可靠数据传输的上层协议很有用。 >除此之外，某些协议（例如DNS）将UDP用于其用途...

#7 楼

我认为重要的是要注意DHCP 100％依赖UDP，并且使用极为广泛。