深度剖析 TCP 与 UDP 的区别

Category（分类）: NET Protocol Status: 未知

网络协议是前端工程师需要掌握的基础知识。TCP/IP 协议族中有两个具有代表性的传输层协议：TCP 和 UDP。本文先介绍 TCP/IP 模型，再从连接方式、数据边界、可靠性、拥塞控制和使用场景等方面比较 TCP 与 UDP。

一、TCP/IP 网络模型

计算机和网络设备要相互通信，就必须遵守共同的规则，例如：如何发现通信目标、由哪一方先发起通信、数据如何表示、如何校验、如何结束通信等。这些规则统称为协议（Protocol）。

TCP/IP 是互联网相关协议族的总称，并不只包含 TCP 和 IP。TCP、UDP、IP、FTP、HTTP、ICMP、SMTP 等都属于 TCP/IP 协议族中的协议。

TCP/IP 通常抽象为四层：

• 网络接口层：负责本地链路上的帧传输，例如以太网、Wi-Fi、MAC 地址和物理介质；
• 网际层：负责 IP 寻址、路由和数据包转发；
• 传输层：负责主机之间进程到进程的数据传输，常见协议是 TCP 和 UDP；
• 应用层：为应用程序提供网络服务和数据格式，例如 HTTP、FTP、Telnet、DNS、SMTP。

在协议栈中，通信双方通常由对等层按照相应协议进行逻辑通信。实际数据发送时，数据从发送端的应用层向下封装；接收端从网络接口层向上解封装。

典型封装过程如下：

应用层数据
    ↓ 添加 TCP/UDP 首部
TCP 段 / UDP 数据报
    ↓ 添加 IP 首部
IP 数据报
    ↓ 添加链路层首部和尾部
链路层帧

链路层通常会增加帧首部和帧尾，传输层和网际层主要增加首部。路由器一般只处理收到的链路层帧和 IP 首部，再为下一条链路重新封装帧，不会把端到端的应用数据完全拆开。

二、UDP

UDP（User Datagram Protocol，用户数据报协议）位于传输层，运行在 IP 之上，是一种无连接、面向数据报的协议。

UDP 不提供 TCP 那样的可靠传输机制：它不负责确认、重传、按序交付、去重、流量控制和统一的拥塞控制。数据报是否到达、是否重复、是否乱序，需要由应用层自行决定是否处理。

1. 无连接

UDP 在发送数据前不需要像 TCP 一样通过三次握手建立连接。应用程序把数据交给 UDP 后，UDP 添加首部并交给 IP 层发送。

接收端的 IP 层将 UDP 数据报交给 UDP，UDP 校验首部和端口后，把数据交给对应的应用程序。UDP 协议本身不会因为发送方和接收方没有握手就保存连接状态。

某些操作系统提供“连接 UDP Socket”的 API，但那通常只是本地 API 记录默认对端和过滤来源，并不表示 UDP 协议执行了 TCP 那样的连接握手。

2. 支持单播、组播和广播

UDP 数据报可以承载在 IPv4 或 IPv6 的不同传输方式上：

• 单播：一对一；
• 组播：一对多，发送给加入组播组的主机；
• IPv4 广播：一对本地网络中的多个主机。

具体能否使用组播或广播，还取决于 IP 版本、网卡、路由器、交换机和网络配置。UDP 本身提供的是传输层数据报，并不单独决定底层的广播或组播路由。

3. UDP 面向报文

UDP 会保留应用层数据报的边界。应用程序一次交给 UDP 一个数据报，UDP 通常就为这个数据报添加一个首部并发送；接收端通常也按一个数据报交付给应用程序。

UDP 不会像 TCP 一样把多次写入合并为连续字节流，也不会把一个应用消息拆成多个可独立确认的部分。但如果 UDP 数据报过大，IP 层可能进行分片；分片丢失时，整个 IP 数据报可能无法交付给 UDP。

因此，应用程序需要选择合适的数据报大小，尽量避免 IP 分片。UDP 数据报的理论长度受 16 位长度字段限制，IPv4 中扣除 UDP 首部后最大有效负载约为 65507 字节，但实际还会受到路径 MTU 和网络设备限制。

4. 不提供可靠性

UDP 不可靠并不是因为“无连接”本身，而是因为协议没有提供 TCP 那样的可靠传输机制：

• 不确认数据是否到达；
• 不负责超时重传；
• 不保证数据顺序；
• 不负责删除重复数据；
• 不提供 TCP 式流量控制；
• 不提供统一的 TCP 式拥塞控制。

网络环境不稳定时，UDP 数据报可能丢失、重复、乱序或延迟。UDP 本身通常不会因为网络拥塞自动降低发送速率，因此应用如果持续高速发送，可能进一步加重网络拥塞。

不过，这并不意味着所有 UDP 应用都没有可靠性。QUIC 就运行在 UDP 之上，并在应用协议层实现了确认、重传、拥塞控制和多路复用；一些实时通信协议也会根据业务需要实现选择性重传、丢包隐藏和码率调整。

UDP 常用于对实时性要求较高、能够容忍部分丢包，或者由应用自行设计可靠性机制的场景，例如 DNS、DHCP、实时音视频和部分在线游戏通信。

5. 头部开销小

UDP 首部固定为 8 字节，包含以下字段：

• 源端口：16 位，可以为 0 表示没有有效源端口；
• 目的端口：16 位；
• UDP 长度：包含 UDP 首部和数据的总长度；
• 校验和：用于检测 UDP 首部、数据和 IP 伪首部中的传输错误。

UDP 首部固定为 8 字节，而 TCP 首部最小为 20 字节，带选项时通常最大为 60 字节。因此，在不需要 TCP 可靠机制的场景中，UDP 具有较小的首部开销。

IPv4 中 UDP 校验和在传统规范下可以省略；IPv6 中通常要求使用 UDP 校验和。校验和只能发现部分传输错误，不能恢复丢失的数据。

三、TCP

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接、可靠、有序、基于字节流的传输层协议。TCP 的现代规范可以参考 RFC 9293，RFC 793 是早期的重要规范。

当应用需要完整、按序地传输数据时，例如网页资源、文件、邮件等，TCP 可以通过序列号、确认、重传、流量控制和拥塞控制提供可靠的字节流服务。

“字节流”表示 TCP 不保留应用层的消息边界。应用程序调用两次 send()，接收端可能一次 recv() 读到，也可能分多次读到，应用层需要自行设计消息边界。

1. TCP 连接过程

TCP 建立连接通常需要三次握手：

第一次握手

客户端向服务端发送 SYN 报文，报文中包含客户端选择的初始序列号 ISN。发送后客户端进入 SYN-SENT 状态。

客户端 -> 服务端
SYN=1, seq=x

第二次握手

服务端收到客户端的 SYN 后，如果同意建立连接，就返回 SYN-ACK 报文，同时携带服务端自己的初始序列号，并确认客户端的 SYN：

服务端 -> 客户端
SYN=1, ACK=1, seq=y, ack=x+1

服务端进入 SYN-RECEIVED 状态。

第三次握手

客户端收到服务端的 SYN-ACK 后发送 ACK：

客户端 -> 服务端
ACK=1, seq=x+1, ack=y+1

客户端通常可以进入 ESTABLISHED；服务端收到第三次握手的 ACK 后也进入 ESTABLISHED，连接建立完成。

SYN 和 FIN 控制位各占用一个序列号。第三个 ACK 在某些情况下可以携带数据，TCP Fast Open 还允许在握手早期携带数据，但普通应用通常在连接建立后发送数据。

为什么需要三次握手，而不是两次？

三次握手用于同步双方的初始序列号，并让双方都确认对方已经收到自己的握手信息：

• 第一次握手：服务端知道客户端能够发送，且服务端能够接收；
• 第二次握手：客户端知道服务端能够发送和接收，并知道服务端收到了自己的 SYN；
• 第三次握手：服务端知道客户端已经收到自己的 SYN-ACK。

如果只有两次握手，服务端无法确认客户端是否收到自己的响应。一个在网络中延迟的旧 SYN 可能被服务端误认为新的连接请求并占用连接资源。第三次 ACK 能够降低这种旧请求误建立连接的风险。

2. TCP 断开连接

TCP 是全双工的，两个方向可以分别关闭。典型主动关闭过程通常需要四个报文，但如果 ACK 和 FIN 合并，或者双方同时关闭，实际报文数量和状态可能不同。

假设客户端 A 先主动关闭：

第一次挥手

A 发送 FIN 报文：

A -> B
FIN=1, seq=u

A 停止向 B 发送数据，进入 FIN-WAIT-1。

第二次挥手

B 收到 FIN 后发送 ACK：

B -> A
ACK=1, seq=v, ack=u+1

B 进入 CLOSE-WAIT，A 收到 ACK 后进入 FIN-WAIT-2。此时 A 到 B 的发送方向关闭，但 B 仍然可以继续向 A 发送剩余数据。

第三次挥手

B 发送完剩余数据后，发送 FIN-ACK：

B -> A
FIN=1, ACK=1, seq=w, ack=u+1

B 进入 LAST-ACK，等待 A 的确认。

第四次挥手

A 收到 B 的 FIN 后发送 ACK：

A -> B
ACK=1, seq=u+1, ack=w+1

A 进入 TIME-WAIT。B 收到 ACK 后进入 CLOSED。A 通常等待 2MSL 后进入 CLOSED。

主动关闭的一方通常进入 TIME-WAIT，但不一定是客户端；如果服务端主动关闭，服务端也可能进入 TIME-WAIT。

3. TCP 的主要特点

面向连接

发送应用数据前，TCP 通常先通过三次握手建立连接。连接中双方维护序列号、确认号、窗口和状态信息。

仅支持点对点连接

一条 TCP 连接由一个四元组标识：

源 IP、源端口、目的 IP、目的端口

TCP 连接只支持两个端点之间的通信，不直接支持 IP 广播或 IP 组播。需要一对多通信时，通常使用 UDP 组播、应用层转发或其他协议。

面向字节流

TCP 不保留应用层报文边界，只向上层提供连续、有序的字节流。应用协议需要自行设计长度字段、分隔符或固定格式来区分消息。

可靠传输

TCP 使用序列号、确认号和校验和检测数据状态，并结合以下机制提高可靠性：

• 超时重传；
• 快速重传；
• 累积确认和选择确认（SACK）；
• 按序交付和重复数据处理；
• 接收窗口和流量控制；
• 拥塞控制。

发送方在合理的重传超时时间内没有收到确认时，可能重传对应数据。具体 RTO、快速重传和拥塞控制策略由 TCP 实现决定。

拥塞控制

当网络出现拥塞时，TCP 会根据拥塞窗口、丢包、RTT 等信号调整向网络注入数据的速率，以减少拥塞进一步加重。流量控制则主要用于防止发送方超过接收方的处理能力，两者不是同一个概念。

全双工通信

TCP 连接的两个方向可以同时传输数据。两端都具有发送和接收缓冲区，应用可以在任意方向发送数据。TCP 可能根据发送缓冲区、拥塞窗口、MSS、Nagle 算法等因素决定何时形成和发送 TCP 段。

四、TCP 和 UDP 的比较

UDP 并不一定比 TCP 更快，TCP 也不一定在所有场景都更慢。具体性能取决于网络质量、数据大小、应用需求、拥塞控制和实现方式。

五、TCP 和 UDP 的应用场景

UDP

UDP 适合以下场景：

• 应用可以容忍部分丢包；
• 对实时性要求较高；
• 数据报边界很重要；
• 应用希望自行设计重传、冗余和拥塞控制；
• 需要使用组播或 IPv4 广播。

常见例子包括 DNS、DHCP、实时音视频、在线游戏，以及作为 QUIC 底层传输的 UDP。实时音视频通常还会通过应用层机制处理抖动、丢包和码率变化。

TCP

TCP 适合对完整性、顺序和可靠性要求较高的场景，例如：

• HTTP/1.1 和 HTTP/2；
• 文件传输；
• SMTP、POP3、IMAP 等邮件协议；
• SSH 远程登录；
• 需要可靠字节流的业务通信。

六、运行在 TCP 或 UDP 之上的应用协议

常见运行在 TCP 之上的协议

• HTTP/1.1：超文本传输协议；
• HTTP/2：通常运行在 TCP 之上；
• HTTPS：HTTP over TLS，现代 HTTPS 使用 TLS 1.2 或 TLS 1.3；
• FTP：文件传输协议；
• POP3：邮局协议第 3 版；
• SMTP：简单邮件传输协议；
• TELNET：远程终端协议，明文传输，安全性较差；
• SSH：安全远程登录协议。

HTTP/3 不运行在 TCP 上，而是运行在 QUIC 之上，QUIC 使用 UDP 作为底层传输。

常见运行在 UDP 之上的协议

• BOOTP：早期启动配置协议；
• NTP：网络时间协议；
• DHCP：动态主机配置协议，通常使用 UDP 67/68 端口；
• DNS：传统查询通常使用 UDP，特定情况下也会使用 TCP；
• SNMP：传统上主要使用 UDP，部分实现支持其他传输方式。

其他协议

• ECHO：回显协议，可以运行在 TCP 或 UDP 上，但现代使用较少；
• ARP：IPv4 局域网地址解析协议，不运行在 TCP 或 UDP 之上；
• IPv6 使用 NDP 完成邻居发现，不使用 ARP。

七、总结

• TCP 向上层提供面向连接、可靠、有序的字节流服务；
• UDP 向上层提供无连接、面向数据报的尽力而为服务；
• UDP 保留应用数据报边界，TCP 不保留应用消息边界；
• TCP 通过序列号、确认、重传、流量控制和拥塞控制提高可靠性；
• UDP 没有统一的可靠传输机制，但应用层或 QUIC 可以在 UDP 之上实现可靠能力；
• TCP 一条连接只支持两个端点，UDP 可以承载单播、组播和 IPv4 广播；
• 具体选择 TCP 还是 UDP，应根据可靠性、顺序、实时性、数据边界和网络控制需求决定。

参考规范：

• RFC 768：User Datagram Protocol
• RFC 9293：Transmission Control Protocol
• RFC 8085：UDP Usage Guidelines