TCP vs UDP 2026 全面对比

TCP 与 UDP 是 OSI 第四层最核心的两个传输协议，几乎所有上层应用最终都建立在它们之上。两者诞生于上世纪七十年代末，分别走出可靠传输和最简传输两条路线。本文从握手、有序、丢包恢复、拥塞控制、延迟与可靠性权衡讲起，结合 HTTP、视频通话、网络游戏的真实案例，最后讨论 QUIC、HTTP/3 与 2026 年的工程选型趋势，让你彻底理解这两兄弟的分工与未来。

1. 协议出身与设计哲学的根本差异

TCP（Transmission Control Protocol）出现在 RFC 793，1981 年定稿。它的核心目标是把不可靠、可能乱序、可能重复、可能丢失的 IP 数据包链路，包装成对应用透明的可靠字节流。换句话说，TCP 想让程序员写得像在打开一个本地文件，而不必关心底层物理网络的混乱。它通过序号、确认、重传、滑动窗口、拥塞控制把一切复杂度藏在内核里。

UDP（User Datagram Protocol）出现得更早，RFC 768，1980 年。设计哲学反过来：尽量薄、尽量透明、尽量不替应用做决定。UDP 报头只有 8 字节，仅包含源端口、目标端口、长度、校验和，几乎是 IP 层之上一层壳。它把一切控制权和复杂度都交给应用，开发者既享有极致的灵活性，也要承担可靠性、顺序、拥塞控制等所有责任。

所以一句话总结：TCP 是替你想好一切的保姆型协议，UDP 是只给你一个信封的极简快递。两者没有谁更优秀，只有谁更合适。

2. 三次握手、四次挥手与连接状态

TCP 是面向连接的，发送数据前必须先建立连接，结束时再优雅关闭。建立连接通过经典的三次握手完成：客户端发 SYN，服务器回 SYN-ACK，客户端再回 ACK。这三次交互交换初始序号、窗口大小、MSS、SACK 选项等关键参数。在高延迟链路上，仅握手就能消耗一两百毫秒。

关闭连接需要四次挥手：双方独立关闭各自方向的写入，因此需要两个 FIN 和两个 ACK。设计上允许半关闭，例如 HTTP 早期版本中客户端发完请求就关闭写入但仍可读取响应。TCP 还维护非常多的连接状态：LISTEN、SYN_SENT、SYN_RECV、ESTABLISHED、FIN_WAIT_1/2、TIME_WAIT、CLOSE_WAIT 等等。

UDP 完全没有连接状态，发就发，收就收。一个端口可以同时和成千上万的客户端通信，没有握手开销，第一次发包就携带数据，对极低延迟的场景非常友好。代价是没有任何防御机制，恶意方可以伪造源 IP 进行反射放大攻击，因此 DNS、NTP 等基于 UDP 的服务长期受 DDoS 困扰。

3. 有序交付、丢包重传与队头阻塞

TCP 通过序号保证字节流有序：每个字节都有唯一编号，接收方按序号重组并向应用层提交连续字节，乱序到达的包先放入接收缓冲区等待补齐。如果某个包丢失，后续到达的包必须等它重传，这就是著名的队头阻塞。

丢包检测有两种主要机制：超时重传（RTO）和快速重传（收到三个重复 ACK 即认为前一个包丢了）。现代 TCP 还普遍支持 SACK 选择性确认，让接收方告诉发送方具体哪些段缺失，避免重传整个窗口。Linux 4.x 之后默认启用 BBR 拥塞控制，进一步提升吞吐。

UDP 则没有任何重传或排序保证。每个 datagram 是独立的，应用收到什么就是什么。这看似简陋，但对实时音视频反而有利：丢一个包还不如直接跳过，等后面新鲜的数据到了立刻播放。如果非要可靠性，应用可以自己实现序号、ACK、FEC，QUIC 就是这种思路的集大成者。

4. 流量控制、拥塞控制与公平性

TCP 内置两套限速机制。流量控制基于接收方的窗口大小，避免接收方缓冲区溢出。拥塞控制则基于网络的反馈：从慢启动开始，指数增大窗口，遇到丢包就大幅缩小，再重新探测，著名的算法包括 Reno、CUBIC、BBR。这套机制让 TCP 在拥塞链路上自动让步，多个 TCP 流之间能粗略公平共享带宽。

UDP 没有任何拥塞控制。一个失控的 UDP 流可以瞬间占满链路把别人挤垮。这也是早期网络运营商对 UDP 又爱又恨的原因。今天负责任的 UDP 协议（QUIC、WebRTC、SRT）都在应用层重新实现了类似 TCP 甚至比 TCP 更先进的拥塞控制，避免欺负 TCP 邻居。

理解这一点很重要：自己写 UDP 协议而不实现拥塞控制，本质上是不文明上网。生产级别的 UDP 协议必须包含拥塞控制和公平性策略，这是 QUIC 标准化过程中花了大量篇幅讨论的话题。

5. 报头大小、效率与开销

TCP 报头基本 20 字节，启用选项后可达 60 字节。UDP 报头固定 8 字节。对于小数据频繁交互的场景（DNS 查询、游戏状态同步），UDP 的开销显著更低。

除了字节数，TCP 还有时间开销：握手 1.5 个 RTT、TLS 又 1 个 RTT、HTTP 请求才能开始。在 200ms RTT 的跨洲链路上，光协商就要半秒。HTTP/3 把这一切压缩到 0 到 1 个 RTT，体感快得多。

另一个隐藏开销是内核态切换。每个 TCP socket 需要在内核维护连接状态，并通过系统调用读写。高并发服务（如百万长连接）必须用 epoll、kqueue、io_uring 等机制摊薄开销。UDP 服务因为无状态，常配合 SO_REUSEPORT 多核扩展，单机轻松撑住数百万 QPS。

6. 真实场景对比：HTTP、视频通话、网络游戏

HTTP/1.1 和 HTTP/2 都跑在 TCP 上。HTTP/2 已经支持多路复用，但底层 TCP 的队头阻塞依然存在：一个 TCP 段丢了会卡住所有逻辑流。这是 Google 推出 QUIC 和 HTTP/3 的直接动机。

视频通话与直播绝大多数走 UDP。WebRTC 默认通过 SRTP（基于 UDP）传输音视频流，结合 NACK、FEC、抖动缓冲、自适应码率提供端到端体验。直播协议 SRT、RIST、QUIC-based RTMP 也都基于 UDP，目标是低延迟、可丢失。

网络游戏分两类。FPS、MOBA、格斗等强实时游戏几乎都用 UDP，确保几十毫秒的输入延迟；卡牌、回合制、棋牌则常用 TCP 或基于 TCP 的 WebSocket，因为可靠性比延迟更重要。MMORPG 通常混用：战斗与移动走 UDP，聊天与交易走 TCP。

如果你需要把网络数据格式化、调试，请尝试 JSON 格式化工具与 curl 命令生成器，可以帮助你快速构造 HTTP 请求并比较 HTTP/1.1、HTTP/2、HTTP/3 的表现。

7. QUIC 与 HTTP/3：UDP 的逆袭

QUIC 是 IETF 在 2021 年标准化的传输层协议，跑在 UDP 之上。它把可靠传输、流多路复用、TLS 1.3 加密、连接迁移、0-RTT 重连全部塞进一个协议，并完全运行在用户态。这意味着浏览器和服务器无需等待操作系统升级就能更新 QUIC 实现，迭代速度远超 TCP。

2026 年，HTTP/3（基于 QUIC）的 Web 部署率已经接近 35%，主流 CDN（Cloudflare、Akamai、Fastly、阿里云）默认开启。它解决了 TCP 的队头阻塞、握手开销、连接迁移（手机切换 WiFi 不断流）等老问题，是面向未来的事实标准。

但 QUIC 不是银弹。它对路径中间盒（NAT、防火墙）有较高要求，部分企业网络仍会阻塞 UDP 443，需要自动 fallback 到 HTTP/2 over TCP。运维上要密切关注 UDP buffer 调优、负载均衡器对 QUIC 的支持。

8. 2026 年工程选型与最佳实践

给出一个简洁的选型清单：纯后端服务调用、数据库连接、消息队列、SSH、FTP、邮件、工业自动化协议，继续用 TCP；面向公网的 Web/API，优先开启 HTTP/3 + HTTP/2 双栈；实时音视频、游戏、IoT 大量短小报文，使用 UDP 或基于 UDP 的封装协议；自研传输协议时，认真评估 QUIC 是否能满足需求，避免从零造轮子。

监控方面，TCP 服务关注重传率、RTT、握手失败率；UDP 服务关注丢包率、抖动、乱序率。两者都要监控连接建立速率、SYN/UDP flood、放大攻击迹象。带 BBR/CUBIC 的 TCP 调优、增大内核 UDP buffer、启用 GSO/GRO，都是常见性能手段。

最后提醒：永远先测量再优化。盲目从 TCP 切到 UDP 可能引入更多复杂度，反而恶化稳定性。多数 Web 业务把现有 HTTP 栈升级到 HTTP/2 或 HTTP/3，就已经能拿到 80% 的性能红利。

常见问题

TCP 和 UDP 最核心的区别是什么？

TCP 是面向连接的可靠传输协议，提供三次握手、有序交付、丢包重传、流量控制和拥塞控制；UDP 是无连接的不可靠协议，只在 IP 层之上加了端口和校验和，不保证送达、不保证顺序、不保证不重复。简单来说 TCP 用复杂换可靠，UDP 用极简换低延迟。

为什么视频通话和游戏喜欢用 UDP 而不是 TCP？

实时音视频和竞技游戏对延迟极度敏感，丢一两个数据包远比晚到几百毫秒友好。TCP 的丢包重传和有序保证会引发队头阻塞，老的数据卡住新的数据；UDP 把控制权交给应用，可以丢就丢、跳帧续传，加上 FEC 前向纠错，体验明显更顺滑。

HTTP/3 用 UDP 是否意味着 TCP 要被淘汰？

不会。HTTP/3 基于 QUIC，QUIC 跑在 UDP 上但自己实现了可靠性、拥塞控制、加密和多路复用，本质上是把 TCP 那套搬到用户态以便快速演进。TCP 仍然是数据库连接、SSH、FTP、邮件、绝大多数后端服务的默认选择，操作系统级稳定性短期不可替代。

UDP 完全不可靠，开发者怎么用？

开发者要么接受丢包（DNS 单次查询、NTP、监控指标这类幂等场景），要么在应用层自己加可靠性，比如序号、ACK、超时重传、FEC、滑动窗口。QUIC、WebRTC、KCP、SRT 都是这种模式，根据业务对延迟和可靠性的权衡灵活定制策略。

2026 年应该如何在 TCP 和 UDP 之间做选型？

通用规则：业务必须保证完整有序、可以容忍 100ms 级延迟，选 TCP；强实时、可丢可补、对首包延迟敏感，选 UDP 或基于 UDP 的 QUIC。新建 Web 服务直接用 HTTP/2 或 HTTP/3，由库帮你处理协议；自研协议优先评估 QUIC，避免重复发明 TCP 的轮子。