TCP 和 UDP 有什么区别：从可靠性到速度，从头部到场景

TCP 和 UDP 有什么区别从可靠性到速度从头部到场景01. 前言传输层的“双雄”02. 核心区别一句话总结03. TCP 详解可靠的“电话模式”3.1 TCP 核心特征3.2 TCP 通信流程3.3 TCP 头部结构20~60 字节04. UDP 详解无连接的“明信片模式”4.1 UDP 核心特征4.2 UDP 通信流程4.3 UDP 头部结构固定 8 字节05. 详细对比10 个维度逐项分析5.1 连接性5.2 可靠性5.3 有序性5.4 头部大小5.5 流量控制5.6 拥塞控制5.7 消息边界5.8 一对多通信5.9 速度与延迟5.10 丢包处理06. 头部对比图文字版07. 适用场景对比08. 选择决策流程图09. 实际应用案例分析9.1 为什么 DNS 用 UDP9.2 为什么视频直播用 UDP9.3 为什么游戏用 UDP10. 常见问题与误区Q1UDP 比 TCP 快很多吗Q2UDP 不安全吗Q3可以用 UDP 实现可靠传输吗Q4TCP 和 UDP 能共用同一个端口吗11. 对比总结表12. 总结The Begin点点关注收藏不迷路01. 前言传输层的“双雄”TCP 和 UDP 是传输层的两大核心协议几乎所有网络应用都建立在它们之上。TCPTransmission Control Protocol可靠、有序、面向连接——像打电话UDPUser Datagram Protocol不可靠、无序、无连接——像寄明信片两者最大的区别在于TCP 为了可靠性牺牲了部分速度和灵活性UDP 为了速度放弃了可靠性保障。本文从 10 个维度全面对比 TCP 与 UDP包括连接方式、可靠性、头部结构、流量控制、适用场景等并附上选择决策流程图。02. 核心区别一句话总结维度TCPUDP连接性面向连接需三次握手无连接发就完了可靠性可靠确认重传、排序、去重不可靠尽最大努力交付有序性保证有序序列号重排不保证有序可能乱序速度较慢握手、确认、重传开销较快无额外开销头部大小20~60 字节8 字节固定流量控制✅ 有滑动窗口❌ 无拥塞控制✅ 有慢启动、拥塞避免❌ 无面向字节流报文数据报一对多不支持一对一支持单播/组播/广播典型应用HTTP、HTTPS、SSH、FTP、SMTPDNS、VoIP、视频直播、游戏、DHCP03. TCP 详解可靠的“电话模式”3.1 TCP 核心特征┌─────────────────────────────────────────────────────────────────┐ │ TCP 特征 │ ├─────────────────────────────────────────────────────────────────┤ │ ✓ 面向连接通信前必须建立连接三次握手 │ │ ✓ 可靠传输确认重传、超时重传 │ │ ✓ 有序交付序列号保证数据按发送顺序到达 │ │ ✓ 流量控制滑动窗口匹配收发速度 │ │ ✓ 拥塞控制避免压垮网络 │ │ ✓ 全双工双方可同时收发 │ │ ✓ 字节流没有消息边界 │ └─────────────────────────────────────────────────────────────────┘3.2 TCP 通信流程客户端 服务器 │ │ │ ──────── 三次握手 ────────────────────────→ │ 建立连接 │ ←──────────────────────── 三次握手 ──────── │ │ │ │ ──────── 数据 ACK ──────────────────────→ │ 可靠传输 │ ←──────────────── 数据 ACK ────────────── │ 每包都要确认 │ │ │ ──────── FIN ─────────────────────────────→ │ 关闭连接 │ ←──────────────── ACK FIN ────────────── │ │ ──────── ACK ─────────────────────────────→ │3.3 TCP 头部结构20~60 字节0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- | 源端口 | 目标端口 | -------------------------------- | 序列号Sequence Number | -------------------------------- | 确认号Acknowledgment Number | -------------------------------- | 数据偏移 | 保留 |标志位| 窗口大小Window | -------------------------------- | 校验和 | 紧急指针 | -------------------------------- | 选项可选最多40字节 | -------------------------------- | 数据 | --------------------------------关键字段序列号每个字节的编号用于排序和去重确认号告诉对方下一个期望收到的字节序号窗口流量控制告诉对方还能收多少字节标志位SYN建连、ACK确认、FIN关闭、RST复位等04. UDP 详解无连接的“明信片模式”4.1 UDP 核心特征┌─────────────────────────────────────────────────────────────────┐ │ UDP 特征 │ ├─────────────────────────────────────────────────────────────────┤ │ ✗ 无连接发送前不需要建立连接 │ │ ✗ 不可靠不保证送达不重传 │ │ ✗ 无序包可能乱序到达 │ │ ✗ 无流量控制发送速度不受接收方限制 │ │ ✗ 无拥塞控制可能加剧网络拥堵 │ │ ✓ 轻量头部仅 8 字节 │ │ ✓ 低延迟无握手、无确认、无重传 │ │ ✓ 支持广播/组播 │ │ ✓ 保留消息边界数据报 │ └─────────────────────────────────────────────────────────────────┘4.2 UDP 通信流程客户端 服务器 │ │ │ 无连接建立直接发数据 │ │ ──────── 数据报1 ─────────────────────────→ │ │ ──────── 数据报2 ─────────────────────────→ │ │ ──────── 数据报3 ─────────────────────────→ │ │ │ │ 服务器可能回复也可能不回复 │ │ ←──────────────────────── 数据报4 ───────── │ │ │ │ 无连接关闭发完即止 │4.3 UDP 头部结构固定 8 字节0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- | 源端口 | 目标端口 | -------------------------------- | 长度 | 校验和 | -------------------------------- | 数据 | --------------------------------UDP 极其简单只有端口、长度、校验和没有任何可靠性字段。05. 详细对比10 个维度逐项分析5.1 连接性协议连接方式说明TCP面向连接三次握手建立状态四次挥手关闭UDP无连接不建立状态直接发送TCP 三次握手 SYN → SYNACK → ACK UDP 无握手 直接发送数据包5.2 可靠性协议可靠性机制TCP可靠确认应答ACK 超时重传 快速重传UDP不可靠尽最大努力交付丢包不重传5.3 有序性协议有序性说明TCP保证有序序列号重排应用层收到的是顺序数据UDP不保证有序应用层收到的可能乱序需自己处理5.4 头部大小协议头部大小说明TCP20~60 字节基础 20 字节 选项如时间戳、SACKUDP8 字节固定长度无选项5.5 流量控制协议流量控制说明TCP✅ 有滑动窗口防止接收方被淹没UDP❌ 无发送方想发多快就多快5.6 拥塞控制协议拥塞控制说明TCP✅ 有慢启动、拥塞避免、快重传、快恢复UDP❌ 无无内置拥塞控制可能加剧网络拥堵5.7 消息边界协议数据模型说明TCP字节流无消息边界多次 send 可能一次 recv 收到UDP数据报报文保留边界一次 send 对应一次 recvTCP 字节流示例 发送端send(Hello) send(World) 接收端recv() 可能一次收到 HelloWorld边界丢失 UDP 数据报示例 发送端send(Hello) send(World) 接收端recv() 收到 Hello下次 recv() 收到 World边界保留5.8 一对多通信协议一对多支持说明TCP❌ 不支持点对点只能一对一UDP✅ 支持单播、组播多播、广播5.9 速度与延迟协议速度原因TCP较慢握手、确认、重传、拥塞控制等额外开销UDP较快无额外机制数据直接发出5.10 丢包处理协议丢包后行为说明TCP重传直到成功应用层无感知但延迟增加UDP丢弃不通知应用层需自己检测并处理如用 FEC 或重传06. 头部对比图文字版TCP 头部20~60字节 ┌──────────────┬──────────────┬──────────────┬──────────────┐ │ 16bit 源端口 │ 16bit 目标端口│ │ ├──────────────┴──────────────┼──────────────┬──────────────┤ │ 32bit 序列号 │ │ ├─────────────────────────────┼──────────────┬──────────────┤ │ 32bit 确认号 │ │ ├──────────────┬──────────────┼──────┬───────┼──────┬───────┤ │4bit偏移│保留 │8bit 标志位 │16bit 窗口 │ │ ├──────────────┼──────────────┼──────────────┼──────────────┤ │16bit 校验和 │16bit 紧急指针│ │ ├──────────────┴──────────────┴──────────────┴──────────────┤ │ 选项最多40字节 │ └───────────────────────────────────────────────────────────┘ UDP 头部固定8字节 ┌──────────────┬──────────────┐ │ 16bit 源端口 │16bit 目标端口│ ├──────────────┼──────────────┤ │ 16bit 长度 │16bit 校验和 │ └──────────────┴──────────────┘07. 适用场景对比场景推荐协议原因网页浏览HTTP/HTTPSTCP需要可靠、完整、有序的页面数据文件下载FTPTCP不能丢字节丢一点文件就坏了电子邮件SMTP/IMAPTCP可靠性优先SSH 远程登录TCP每个字符都不能丢数据库连接MySQL/RedisTCP数据一致性要求高DNS 查询UDP一个包搞定重试成本低不需要连接开销视频直播/流媒体UDP丢几帧没关系延迟更重要VoIP 语音通话UDP宁可丢包也不等重传重传反而更糟在线游戏FPSUDP低延迟 可靠性丢包用插值/预测处理DHCPUDP广播特性简单快速SNMPUDP简单网络管理偶发丢包可接受实时监控/日志UDP量大偶尔丢几条可接受HTTP/3 (QUIC)UDP在 UDP 上实现类似 TCP 的可靠性但解决队头阻塞08. 选择决策流程图需要传输数据 │ ▼ ┌─────────────────┐ │ 数据必须可靠吗 │ │ 不能丢不能错│ └────────┬────────┘ │ ┌──────────────┴──────────────┐ │ 是 │ 否 ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ 需要顺序到达吗 │ │ 延迟敏感吗 │ └────────┬────────┘ └────────┬────────┘ │ │ 是 │ 否 是 │ 否 ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ TCP │ │ UDP │ │ 可靠有序 │ │ 最快可丢包 │ └─────────────────┘ └─────────────────┘ │ │ │ 如需更好的 │ 如需一定可靠性 │ 拥塞控制 │ 但不想用 TCP ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ 也可考虑 │ │ QUIC │ │ SCTP少见 │ │ HTTP/3底层 │ └─────────────────┘ └─────────────────┘ 附加考虑 - 需要广播/组播→ 只能用 UDP - 一对多通信→ 只能用 UDP - 超低延迟如游戏→ UDP 应用层丢包处理09. 实际应用案例分析9.1 为什么 DNS 用 UDPDNS 查询 客户端www.example.com 的 IP 是多少 服务器93.184.216.34 特点 - 一问一答数据量小通常 512 字节 - 一个 UDP 包就能完成 - 如果丢包客户端超时后重试应用层重试 - 无需 TCP 的三次握手开销节省 RTT9.2 为什么视频直播用 UDP视频直播场景 每秒 30 帧视频每帧分成多个包 如果某个包丢了 TCP 行为等待重传 → 卡顿、延迟增加 UDP 行为丢就丢了 → 下一帧继续用户看到轻微花屏 用户感受 卡顿TCP 远比 花屏UDP 难受9.3 为什么游戏用 UDPFPS 游戏如《CS:GO》《守望先锋》 每帧发送玩家位置、射击事件 如果某个位置包丢了 TCP 重传等重传时其他玩家已经移动了 → 落后了 UDP 丢包客户端用预测插值继续下个包更新位置 体验宁可短暂瞬移也不能卡顿10. 常见问题与误区Q1UDP 比 TCP 快很多吗不绝对。对于小数据量、单包场景UDP 省去握手和确认确实快。但对于大数据量传输TCP 的拥塞控制反而能更高效地利用带宽两者差异不大。Q2UDP 不安全吗不是。UDP 本身不提供加密但可以在应用层实现加密如 DTLS、QUIC。安全性与协议无关与是否加密有关。Q3可以用 UDP 实现可靠传输吗可以。很多应用层协议在 UDP 上实现了可靠性如 QUIC、RUDP、UDT。但需要考虑丢包检测、重传、排序、拥塞控制等——这些 TCP 已经帮你做好了。Q4TCP 和 UDP 能共用同一个端口吗可以。端口号是传输层的概念TCP 和 UDP 是独立的命名空间。例如DNS 服务同时监听 TCP/53 和 UDP/53。11. 对比总结表对比维度TCPUDP全称Transmission Control ProtocolUser Datagram Protocol连接性面向连接无连接可靠性可靠确认重传不可靠尽力而为有序性保证有序不保证有序头部大小20~60 字节8 字节流量控制有滑动窗口无拥塞控制有无消息边界字节流无边界数据报有边界广播/组播不支持支持速度较慢较快典型应用Web、Email、SSH、数据库DNS、VoIP、直播、游戏12. 总结┌─────────────────────────────────────────────────────────────────┐ │ TCP vs UDP 一句话总结 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ TCP 可靠但慢 → 像打电话建立连接确认每句话 │ │ UDP 快但可能丢 → 像寄明信片扔进邮筒不确认是否收到 │ │ │ │ 选择原则 │ │ • 数据不能丢 → TCP │ │ • 速度快优先 → UDP │ │ • HTTP/HTTPS → TCP但 HTTP/3 用 UDPQUIC │ │ • 视频/游戏/DNS → UDP │ │ │ └─────────────────────────────────────────────────────────────────┘面试回答模板TCP 和 UDP 的主要区别在于TCP 是面向连接的、可靠的、有序的、有流量控制和拥塞控制的字节流协议头部 20-60 字节UDP 是无连接的、不可靠的、无序的、无流量控制的报文协议头部仅 8 字节。TCP 适用于 HTTP、FTP、SSH 等需要可靠传输的场景UDP 适用于 DNS、视频直播、游戏等对延迟敏感、可容忍丢包的场景。The End点点关注收藏不迷路