说说 UDP 和 TCP 的区别及应用场景
Category（分类）: NET Protocol Status: 未知
上一篇聊完一文彻底搞懂 TCP 三次握手、四次挥手过程及原理，这次聊聊 TCP 和 UDP 的区别以及使用场景。
一、TCP/IP 中的 TCP 和 UDP
TCP/IP 协议族中有两个具有代表性的传输层协议，分别是 TCP 和 UDP。它们都位于 IP 之上，为应用程序提供端到端的数据传输能力，但设计目标不同：
- TCP 更关注可靠、有序地传输连续字节；
- UDP 更关注低开销地发送独立数据报，并保留数据报边界。
传输层在 OSI 七层模型和 TCP/IP 四层模型中的位置如下：
OSI 模型和 TCP/IP 模型并不是严格的一一对应关系。通常可以粗略地理解为：TCP、UDP 位于传输层，IP 位于网际层，网卡和链路协议位于网络接口层，而 HTTP、DNS、DNS over HTTPS、QUIC 等属于不同层次或组合下的上层协议。
那么，TCP 和 UDP 的区别以及使用场景分别是怎样的？
二、TCP
TCP（Transmission Control Protocol，传输控制协议）是面向连接的、可靠的、有序的字节流协议。
“面向连接”表示通信双方在传输数据前需要建立连接状态，双方还可以进行全双工通信；它并不表示 TCP 能证明对端应用一定存在，也不代表对端业务一定处理了数据。
“字节流”表示 TCP 不保留应用层消息边界。应用程序连续调用两次 send()：
send(data1)
send(data2)
接收端可能一次读到 data1 + data2，也可能先读到 data1 的一部分。一次 send() 不一定对应一次 recv()，如果应用层需要独立消息，就必须自行增加长度字段、分隔符或其他封包格式。
TCP 的可靠性和控制机制
TCP 为提供可靠传输，使用了顺序控制、确认应答、丢包重传等机制，同时还具备流量控制和拥塞控制等功能。TCP 的可靠性主要通过以下机制共同实现：
- 序列号（Sequence Number）：标识字节流中的数据范围；
- 确认号（Acknowledgment Number）：确认已经收到的字节范围；
- 校验和（Checksum）：检测传输中的部分错误，但本身不能恢复丢失数据；
- 超时重传和快速重传：发现可能丢失的数据后重新发送；
- 接收窗口和流量控制：避免发送方压垮接收方的缓冲区；
- 拥塞控制：根据网络拥塞情况调整发送速率，保护网络；
- 连接管理：通过握手、关闭和状态机管理连接生命周期。
TCP 的可靠性是针对传输层字节流而言的。连接可能因为超时、RST、网络断开或对端进程退出而失败，应用程序仍然需要处理错误、超时和重连；TCP ACK 也不等于服务端业务已经成功执行。
TCP 有以下特点：
- TCP 充分实现了数据传输时的各种控制功能，可以在丢包时进行重传控制，也可以对乱序到达的数据按照序列号重新排序；
- TCP 是面向连接的协议，连接建立后双方维护传输状态；
- TCP 在 IP 这种尽力而为的无连接网络之上，提供可靠、有序、无重复的字节流；
- TCP 的流量控制和拥塞控制是两个不同概念：前者保护接收方，后者主要保护网络。
TCP 建立连接不等于确认业务对端
传统资料经常说：
TCP 只有在确认通信对端存在时才会发送数据。
这个说法不够准确。TCP 三次握手可以让双方建立连接状态并确认一定程度的双向可达性，但它不能保证：
- 对端应用进程仍然存活；
- 对端已经读取数据；
- 对端已经完成业务处理；
- 网络之后不会中断。
如果需要确认业务是否成功，仍应使用应用层响应、状态码或业务 ACK。
三、UDP
UDP（User Datagram Protocol，用户数据报协议）是无连接的、面向数据报的传输协议。
所谓面向数据报，是指应用层交给 UDP 一段多长的数据，UDP 通常就把它作为一个独立数据报发送。接收端使用数据报 Socket 接收时，通常一次操作对应一个 UDP 数据报，因此 UDP 保留了数据报边界；这和 TCP 连续的字节流不同。
不过，UDP 的数据报边界不代表数据一定可靠到达。UDP 不保证数据报一定到达，也不保证到达顺序、不重复和不丢失。
UDP 的长度和分片
应用程序必须选择合适大小的 UDP 数据报：
- 数据报过大时，可能触发 IP 分片；
- IP 分片中的任意一个分片丢失，都可能导致整个 UDP 数据报不可用；
- 分片还会增加丢包风险和处理开销；
- 数据报过小时，UDP/IP 首部相对于有效载荷的比例增加，带宽利用率降低；
- 如果数据超过系统或路径允许的大小，发送操作还可能失败。
UDP 长度字段理论上允许较大的数据报，但公网路径的有效 MTU 往往小得多。实际应用通常应避免依赖 IP 分片，根据路径 MTU、Packetization Layer PMTUD 或协议自身的最大报文限制选择大小。不能简单地把“UDP 最大长度”当作“互联网安全可发送长度”。
接收端还必须提供足够大的缓冲区。如果接收缓冲区小于完整 UDP 数据报，具体 Socket API 可能截断数据报或丢弃多余部分；这与 TCP 中剩余字节留在接收缓冲区的行为不同。
UDP 的校验和
UDP 首部包含源端口、目的端口、长度和校验和字段。UDP 校验和用于检测数据报在传输过程中的错误，不负责重传和纠正丢包。
在 IPv4 中，UDP 校验和在传统规范下可以为零；在 IPv6 中通常要求使用 UDP 校验和，但存在少数特定例外。现代互联网应用通常应使用校验和，不应把 UDP 当作完全没有错误检测的协议。
UDP 的可靠性和拥塞控制
UDP 不提供 TCP 那样的复杂控制机制，它利用 IP 提供尽力而为的无连接数据报服务：
- 传输途中出现丢包时，UDP 不负责重发；
- 数据报乱序到达时，UDP 不负责排序；
- UDP 不负责删除重复数据报；
- UDP 本身不提供 TCP 式的流量控制；
- UDP 本身也不提供 TCP 式的拥塞控制。
如果应用需要可靠性、顺序、去重、重传、流量控制或拥塞控制，就需要在应用层实现，或者使用已经实现这些能力的协议，例如 QUIC。
但“UDP 没有内置拥塞控制”并不意味着应用可以在公网中无限速发送。面向互联网的 UDP 应用应当进行合理的速率控制、拥塞控制和发送节奏管理，避免对网络造成不公平的压力。RFC 8085 建议 UDP 应用根据目标和网络情况采用合适的拥塞控制策略，并尽量避免 IP 分片。
UDP 的特点和应用场景
UDP 常见于以下场景：
- 数据量较少、允许应用自行处理可靠性的通信：例如 DNS、NTP、部分 SNMP 场景；
- 实时音视频通信：例如 RTP、WebRTC 媒体传输，实时性有时比等待重传更重要；
- 广播和组播通信：例如局域网发现、IPv4 广播和 IP 组播；
- 需要自定义传输机制的场景：例如 QUIC 在 UDP 之上实现可靠 Stream、TLS、拥塞控制和连接迁移；
- 受控网络中的低延迟通信：例如部分局域网设备协议。
这些只是常见场景，并不是绝对限制。DNS 也可以使用 TCP、TLS 或 HTTPS；音视频也可以运行在 TCP、QUIC 或其他协议之上，最终要根据可靠性、延迟、顺序、广播能力和网络环境选择。
四、UDP 和 TCP 的应用场景
TCP 常见场景
TCP 适合需要可靠、有序字节流的应用，例如：
- HTTP/1.1、HTTP/2；
- 文件传输；
- SSH、远程终端；
- 数据库连接；
- 邮件传输；
- 需要可靠传输的自定义协议。
HTTP/3 不运行在 TCP 上，而是运行在 QUIC 之上；但 HTTP/1.1 和 HTTP/2 仍然通常使用 TCP + TLS。
UDP 常见场景
UDP 适合以下情况：
- 应用可以容忍少量丢包，或者自行处理丢包；
- 更关注低延迟，不希望等待所有丢失数据重传；
- 需要保留独立数据报边界；
- 需要广播或组播；
- 应用希望自行设计可靠传输或拥塞控制机制。
使用 UDP 不代表一定更快。UDP 虽然减少了连接状态和传输层机制，但如果应用自己实现可靠传输、排序、重传、流量控制和拥塞控制，整体系统可能比直接使用 TCP 更复杂。
五、TCP 和 UDP 的区别
| 对比项 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接，有连接状态和握手 | 无连接，不建立 TCP 意义上的连接 |
| 数据模型 | 有序、可靠的字节流 | 独立的数据报，保留报文边界 |
| 可靠性 | 提供确认、重传、排序和去重等能力 | 不保证到达、顺序和去重 |
| 接收方式 | 一次读取可能得到半条、多条或一条半消息 | 一次数据报接收通常对应一个数据报，缓冲区不足时可能截断 |
| 流量控制 | 内置接收窗口和流量控制 | 不提供 TCP 式流量控制 |
| 拥塞控制 | 内置拥塞控制机制 | UDP 本身不提供，公网应用应自行考虑 |
| 传输开销 | 状态和首部机制相对复杂 | 首部较小，机制简单 |
| 消息边界 | 不保留应用层消息边界，需要封包拆包 | 保留数据报边界，但不保证可靠到达 |
| 广播/组播 | 通常不直接支持广播和组播 | 支持 IPv4 广播和 IP 组播等场景 |
| 典型应用 | Web、文件、数据库、SSH | DNS、实时音视频、广播/组播、QUIC 承载 |
TCP 和 UDP 不是简单的快慢比较
TCP 和 UDP 的优缺点无法简单、绝对地比较：
- TCP 适用于传输层需要可靠、有序字节流的情况；
- UDP 适用于需要数据报边界、低延迟、广播/组播或自定义可靠机制的情况；
- QUIC 说明了 UDP 并不只能提供“不可靠数据报”，也可以在其上构建可靠且安全的传输协议；
- 如果应用没有充分理由自定义可靠传输，直接使用 TCP 或成熟的 QUIC 实现通常更稳妥。
TCP 和 UDP 应该根据应用目的、数据模型、可靠性要求、实时性、网络环境和部署成本按需选择，而不是单纯因为“UDP 更快”或“TCP 更安全”就做决定。
六、总结
TCP 和 UDP 都是传输层协议，但服务目标不同：
- TCP 是面向连接、可靠、有序的字节流协议；
- UDP 是无连接、面向数据报的协议，保留消息边界但不保证可靠到达；
- TCP 通过序列号、确认、重传、流量控制和拥塞控制实现可靠传输；
- UDP 不负责重传、排序和拥塞控制，必要时由应用层或上层协议负责；
- TCP 接收端需要处理部分读取和应用层消息封包；
- UDP 接收端需要注意数据报大小、缓冲区容量、截断和 IP 分片；
- TCP 适合可靠传输，UDP 适合低延迟、数据报、广播/组播或自定义传输机制；
- HTTP/3 使用 QUIC，QUIC 再使用 UDP，但这不意味着 UDP 本身具备 QUIC 的可靠能力。