UDP——快，但可能丢东西

UDP 的一方只要知道对方的 IP 地址和端口号就可以发送 UDP报文，而不会进行三次握手来建立连接，更不会进行四次挥手来关闭连接。

因为少了握手环节，所以速度非常快。

由于不需要建立连接，因此 UDP 支持广播（向所有主机发送数据）和多播（向一组主机发送数据）通信，并且一个 UDP 套接字可以同时与一个或多个 UDP 套接字进行通信。

UDP 不保证数据的可靠传递，也不保证数据的按序到达。

UDP 报文一旦发送出去，不会保留已经发送的数据，因为不需要对方确认是否收到。

即使数据报文丢失，应用层也感知不到。因此在传输过程中，数据报文可能丢失、重复或乱序。

但是对于某些场景来说是可以接受的，例如实时音视频传输，因为这些应用更关心实时性而非数据的完整性。

UDP 没有像 TCP 那样的流量控制和拥塞控制等机制，因此 UDP 可以毫无顾虑地将数据以接近网卡或者带宽的最大发送速率发送，进而数据报文的延时会比较低，适用于对实时性要求非常高的应用场景。

UDP 可能导致网络拥塞，不仅会导致 UDP 本身丢包，还会导致同一网络环境下的其他协议丢包。然而 UDP 丢包了也可以无限制地发送数据，体现了 UDP缺乏公平性，因此有些网络运营商和路由器会对 UDP 进行限制。

UDP的应用场景

（1）DNS（域名系统）：由于 DNS 的查询数据报文通常比较小，并且不需要建立持久连接，查询一次就结束，因此 UDP 的无连接性适合域名解析场景。

（2）实时音视频：UDP 常用于实时音频和视频传输，在这类应用中，实时性非常重要，例如谁也不想看到十几秒前的直播画面，而丢失少量数据可能会被接受（例如噪音或者画面不清晰）。因此 UDP 的最大交付特点很适合这类场景。

（3）IoT（Internet of Things）：大多数物联网设备的内存和 CPU 资源比较少，性能差，维护 TCP 的代价太大，并且物联网设备还对实时性的要求比较高，因此 UDP 的最大交付和最小开销特点适合这类场景。

（4）QUIC（Quick UDP Internet Connections，快速 UDP 互联网连接）：这是一种基于 UDP 改进的应用层通信协议，与 Quick（快）谐音。它最初由Google 设计并在 2013 年首次提出，QUIC 的目标是提供更快的建立连接、更低的延迟和更高的安全性。QUIC 于 RFC9000 中被正式标准化。QUIC 提供了类似TCP 的一整套完备的网络传输的解决方案，包括握手、挥手、确认、重传、纠错、 流量控制和拥塞控制等机制，进而规避了 UDP 的不可靠性，利用了 UDP 的优点。

以上内容摘自《程序员进阶之路：缓存、网络、内存与案例》