TCP (Transmission Control Protocol) 和 UDP (User Datagram Protocol) 是工作在 TCP/IP 模型或 OSI 模型传输层 的两个核心协议，它们提供了在网络上进行进程间通信的不同方式。它们的主要区别在于其可靠性、连接方式、速度、资源消耗和适用场景。
以下是它们之间关键区别的详细对比：
| 特性 | TCP | UDP |
|---|---|---|
| 连接导向 | 面向连接 (Connection-Oriented) | 无连接 (Connectionless) |
| 通信前必须建立连接 (三次握手) | 发送数据前无需建立连接 | |
| 通信结束后要释放连接 (四次挥手) | 发送完数据即结束 | |
| 可靠性 | 高可靠 (Reliable) | 不可靠 (Unreliable) |
| 确保数据顺序交付、无差错、不丢失、不重复 | 不保证数据一定能到达目的地 | |
| 使用确认机制 (ACK)、重传机制 | 无确认、无重传机制 | |
| 提供流量控制 (滑动窗口) 和拥塞控制 | 无流量控制、无拥塞控制 | |
| 数据传输模式 | 字节流 (Byte Stream) | 数据报 (Datagrams / Message) |
| 将应用层交下来的数据视作无结构的连续字节流 | 每次发送的是一个完整的独立的消息包 | |
| 发送方将字节流分成 TCP 段传输 | 发送端/接收端以一个个报文为单位处理 | |
| 接收方重新组装字节流交付应用层 | 接收端直接交付应用层消息包 | |
| 顺序保证 | 保证顺序 | 不保证顺序 |
| 确保接收方接收到的数据顺序与发送方一致 | 包可能以任意顺序到达，应用需自行处理 | |
| 传输速度 | 相对较慢 | 相对更快 |
| 需要建立连接、确认、重传等额外开销 | 无连接建立、无确认、无重传、控制机制少 | |
| 拥塞控制会主动限制速度以避免网络拥塞 | 可以尽可能快地发送数据 | |
| 头部开销 | 较大 (通常 20 字节) | 较小 (仅 8 字节) |
| 包含序列号、确认号、控制标志位、窗口大小等字段 | 仅包含源端口、目的端口、长度、校验和 | |
| 资源消耗 | 较高 | 较低 |
| 维护连接状态、缓存数据、处理重传和确认 | 几乎不需要维护连接状态信息 | |
| 需要较多的 CPU 和内存资源 | 资源消耗小 | |
| 适用场景 | 需要高可靠性的应用 | 对速度敏感、能容忍部分丢失的应用 |
| 文件传输 (FTP, SFTP) | 实时音视频流 (视频通话、直播) | |
| 网页浏览 (HTTP/HTTPS) | 在线游戏 (多人在线对战) | |
| 电子邮件发送/接收 (SMTP, POP3, IMAP) | DNS 查询 | |
| 远程管理 (SSH) | 简单网络管理 (SNMP Trap) | |
| 数据库复制 | 广播/多播应用 (如视频会议分发) | |
| 数据边界 | 不保留数据边界 | 保留数据边界 |
| 接收方可能一次读到多个数据包合并的内容，需要应用层解析 | 接收方每次读操作收到一个完整的发送方消息包 | |
| 常见比喻 | 挂号信或打电话 | 普通明信片或寄信 |
| 保证对方收到、有回应、按顺序 | 投入邮箱，无法保证对方收到 |
关键区别的进一步解释
- 面向连接 vs 无连接：
- TCP 像打电话： 必须先拨号（建立连接），确认对方在线（握手），然后通话（数据传输），最后说再见挂断（释放连接）。提供持续的会话语境。
- UDP 像寄明信片： 直接写上地址（目的IP和端口）、内容（数据），丢进邮筒（网络接口）。不需要知道对方是否在家，寄出去就完了。每张明信片都是一个独立的消息单元。
- 可靠交付 vs 尽最大努力交付：
- TCP 机制保障可靠：
- 序列号和确认号： 每个字节被编号（序列号）。接收方收到后必须发送确认 (ACK)，告知已收到的最高序列号+1（即期望的下一个字节）。发送方根据ACK知道哪里需要重发。
- 重传定时器： 发送数据后启动定时器。如果超时未收到ACK，则重新发送该数据。
- 校验和： 检测数据传输中的错误，出错则丢弃包（引发重传）。
- 流量控制 (滑动窗口)： 防止接收方被淹没。接收方告知自身缓存区剩余空间（窗口大小），发送方发送的数据量不得超过此窗口。
- 拥塞控制： 感知网络拥塞状况并主动降低发送速率（如慢启动、拥塞避免、快速重传、快速恢复等算法），避免加剧网络堵塞。
- UDP 简单交付：
- 不实现上述任何机制。它只提供基本的端到端传输：源端口+目标端口+长度+校验和。
- 如果校验失败（比如网络干扰导致数据损坏），UDP 会直接丢弃该包，不会触发重传。
- 网络拥堵时，路由器可能丢弃任何包（包括 TCP 和 UDP），但 TCP 会察觉到拥塞并降低速率，而 UDP 会继续按应用要求的速度发送（导致更多包被丢弃）。
- TCP 机制保障可靠：
- 数据表示：字节流 vs 数据报：
- TCP 字节流： 应用交给 TCP 发送的是连续的字节序列（就像水管里的水流）。TCP 会将其拆分成合适大小的 TCP 段发送。接收方重新组装成连续的字节流交给应用。应用需要自己定义消息边界（如长度前缀或特殊分隔符）来区分原始消息。
- UDP 数据报： 应用交给 UDP 发送的每一个数据单元（称为用户数据报或消息包）都必须 封装在一个独立的 UDP 报文中发送。接收方每次读操作都会收到一个完整的发送方发出的数据报。数据边界被协议保留。
如何选择？
选择 TCP 还是 UDP，本质上是在 可靠性/有序性 和 速度/低延迟/低开销 之间权衡，并考虑应用的容错性：
- 请选择 TCP： 当数据必须完整无缺、按顺序到达，且延迟稍高一点也能接受（通常在几百毫秒内）。例如：传输一个重要的文件、访问网站、发送邮件、登录服务器等。
- 请选择 UDP： 当速度、低延迟是最关键因素 ，且应用自身能处理偶尔的丢包、乱序 ，或者数据本身就具有时效性 （丢失的旧数据没有重发的价值）。例如：
- 实时音视频通话/直播： 丢失几个视频帧或几毫秒的音频（表现为马赛克或轻微爆音）比等待重传导致视频卡顿几秒更可接受。
- 在线多玩家游戏： 角色的位置、动作状态需要极快地（几十毫秒级）更新。丢了一两次位置更新，可以通过预测算法（根据之前的运动轨迹推算）或等待下一次更新来弥补，比因延迟过高导致游戏卡顿无法操作（因为TCP重传或拥塞控制）体验更好。现代游戏常在UDP基础上实现自定义可靠性层用于关键指令（如开枪命中）。
- DNS 查询： 简单快捷为主，一次查询对应一个请求和一个响应包（或重试）。延迟高会影响整个网页加载体验。
- 广播/多播： UDP 天然支持（TCP不行）。比如网络发现、视频会议分发给多个节点。
- 简单的网络管理（SNMP Trap）： 设备主动上报告警信息，上报一次即可，即使丢失也可等待下一次上报。
重要补充 (现代技术)
- QUIC (HTTP/3 的底层协议)： 为了解决 TCP 在移动网络环境（IP切换）和提升 HTTPS 性能的痛点，在 UDP 基础上实现了自定义的可靠传输、有序交付、流量控制、拥塞控制、多路复用等机制。它结合了 TCP 的可靠性和 UDP 的灵活性与速度（避免了 TCP 的队头阻塞问题），并且默认集成了 TLS 加密。
- 混合使用： 大型应用常混合使用两者。比如视频会议：
- 信令通道 (控制信息)： 使用 TCP 或可靠 UPD (如 QUIC/DTLS-SRTP)，用于建立连接、交换密钥、成员状态、重要控制命令（如举手请求发言）。
- 媒体流通道 (音视频数据)： 主要使用 UDP，因为数据量大，要求低延迟，可以容忍部分丢包。
总而言之，TCP 提供了安全的、有序的数据传输高速公路 ；UDP 则提供了快速、轻便的单行道，风险自担。理解两者的区别和适用场景是网络编程的基础。