有趣的观点和问题！

是的，UDP所做的大部分工作是通过定义UDP 端口的概念，为使用相同 IP 地址的多个应用程序共存提供标准方法。

UDP 令人兴奋的部分不是网络协议，而是由操作系统和套接字库实现的 API。虽然不是 UDP 规范本身的一部分，但使用 POSIX 套接字 API 等抽象来轻松开发基于 UDP 等协议的软件的能力是 Internet 协议栈成功的关键。

UDP 是一种传输协议，类似于 TCP。这意味着它为应用程序提供了使用 IP 的协议。与 TCP 一样，UDP 具有应用程序绑定到的寻址（端口），以便注定要绑定应用程序的数据报由 UDP 发送到正确的应用程序。IPv4 的 UDP 还提供可选的校验和，但 IPv6 需要校验和。

UDP 是基于消息的协议，其中 TCP 是基于流的协议。UDP 可用于应用层协议提供 TCP 的一些但不是全部特性，并且许多应用程序或应用层协议不能利用 TCP 的可靠性，甚至被其破坏。例如，实时协议，如 VoIP、视频，甚至游戏，在丢失的数据报不再有用后就无法使用，因此让 TCP 重新发送数据会产生不好的结果。当您使用 VoIP 并且对方接听时，您想听到的是“你好”，而不是“哦，见鬼了”。

其他事物，例如多播，是单向的，但 TCP 需要在两个应用程序之间建立双向连接，而多播应用程序向许多接收器发送数据。TCP 不能真正做到这一点，但是很容易将 UDP 与多播一起使用。

我鼓励您看看使用 UDP 的更高级别的协议实际上是如何使用它的。经典且有据可查的示例是 DNS（至少在大多数情况下，可以通过 TCP 执行 DNS，但它确实不常见）、DHCP、NTP 和 PTP。

所有这些协议都有一些特定的共同点：

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

前两点被任何合理的传输层协议（甚至是像 TIPC 这样的奇特东西），包括 TCP 所覆盖。但是，TCP的其他两点很糟糕，因为它要求您在面向消息的协议的流之上滚动自己的消息帧协议，并且显着的连接启动和维护开销意味着它对于短时间不频繁的数据交换非常低效.

换句话说，UDP 的“特性”完全值得担心，因为它为前两点提供了最低限度，而不会像 TCP 对这些类型的应用程序那样妨碍您。它也比 TCP 有一点优势，因为它是微不足道的完全在硬件中或在具有小于 1Kb RAM 和极少量代码存储空间的微型系统上实现（这就是为什么 BOOTP、RARP、TFTP 和其他引导协议最初使用它的部分原因）。缺点是可靠性和对某些类型攻击的敏感性，如果在没有非常仔细的管理的情况下使用长期状态的“连接”，但是使用它并关心它的协议会自行处理它（请参阅 TFTP 的示例来处理可靠性问题，尽管以速度为代价）。

现在，有一些选项可以以更少的开销实现与 TCP 类似的功能集（甚至更全面的功能集），并且仍然允许面向消息的通信（主要示例包括 RUDP、DCCP 和 SCTP），但它们还没有真正实现由于多种原因而流行，所以 UDP 只是一种坚持。

重要的一点是UDP 不需要设置“连接”。

例如，在 TCP 之上实现 DHCP 将是困难和复杂的，如果不是不可能的话，客户端没有 IP 地址并且对现有网络环境零知识。因此“建立连接”是没有意义的，因为客户端不知道目标地址并且没有源地址。UDP 允许向现有网络广播 DHCP 请求，并且一个（希望只有一个）DHCP 服务器将响应一个提议，从而使这变得容易。

类似地，大多数网络广播操作对 TCP* 毫无意义，因为您无法与每个主机都接受和响应的“广播目标”建立“连接”。序列号和校验和之类的东西不会相加。

^{* 我们不是在谈论像MPI_Bcast(). 他们真的超出了这个问题的范围。}