TCP和UDP有什么区别？服务器应用场景与通信机制详解

装完一台 Linux 服务器，第一件事往往是开放防火墙端口。可你有没有想过，同样是放行一个端口，为什么 SSH 走的是 TCP，DNS 查询却默认用 UDP？为什么视频会议卡顿掉帧，而下载文件却几乎不会出错？

这背后就是传输层的两种协议：TCP 和 UDP。它们同属 TCP/IP 协议栈的第四层，却走了两条完全相反的设计路线。这篇文章把两者的机制讲清楚，给出头部结构、对比表格和典型业务选型建议，让你在排查网络问题、配置防火墙、设计服务时,能准确判断某个服务到底该用哪种协议。文章面向运维新手和中小企业 IT，所有命令在 RHEL/CentOS/Rocky 与 Debian/Ubuntu 上都能直接跑。

一、先搞懂"传输层"在干什么

网络通信可以粗分为四层：链路层负责同一个局域网内的帧传输，网络层（IP）负责把数据包从一台主机送到另一台主机，传输层（TCP/UDP）负责"进程到进程"的通信，应用层则是 HTTP、DNS 这些具体协议。

注意一个关键点：IP 层只认 IP 地址，它把数据送到主机就完事了，但一台服务器上跑着几十上百个进程，数据到底该给谁？这就需要传输层用"端口号"来区分。所以 TCP 和 UDP 都要携带端口号，区别在于它们如何对待可靠性。

TCP 的全称是传输控制协议，它的设计目标是"可靠、有序、面向连接"。UDP 的全称是用户数据报协议，设计目标是"简单、快速、不保证可靠"。这不是谁好谁坏的问题，而是针对不同业务做的不同取舍。

二、TCP：面向连接的可靠传输

TCP 在正式传数据之前，必须先"握手"建立连接，双方确认彼此在线、序号从哪开始，这个过程就是著名的三次握手。连接建立后，TCP 保证四件事：

可靠交付。每个字节都有序号，接收方收到后要回 ACK 确认。发送方在一定时间内没收到确认，就重传。所以丢包对应用层是透明的，底层的重传会把它补上。

按序到达。数据被切成一段段报文，网络可能乱序，TCP 会在接收端按序号重新排好，再交给应用。

流量控制。接收方通过窗口字段告诉发送方"我还能接多少"，防止发得太快把对方缓冲区撑爆。

拥塞控制。TCP 会根据网络状况动态调整发送速率，慢启动、拥塞避免、快速重传这些算法，都是为了不在网络拥堵时火上浇油。

代价是什么？头部大（20 字节起步）、握手有延迟、有状态（双方要维护连接状态表）、发生丢包时会等待重传。所以 TCP 适合"数据不能错、可以慢一点"的场景。

TCP 头部大约 20 字节（不含选项），关键字段包括源端口、目的端口、序号（Seq）、确认号（Ack）、标志位（SYN/ACK/FIN/RST/PSH/URG）、窗口大小、校验和。你可以用抓包看到这些字段。

三、UDP：无连接的轻量选手

UDP 干脆得多：想发就发，不问对方在不在，不建立连接，不保证送达，不保证顺序。它的头部只有 8 字节，四个字段：源端口、目的端口、长度、校验和。

因为省掉了握手、确认、重传、排序这些机制，UDP 的开销极小、延迟极低。代价是：丢包了应用层自己负责，乱序了应用层自己排，重复了应用层自己去重。换句话说，UDP 把可靠性这件事完全甩给了上层。

这也带来一个常被忽略的好处：UDP 天然适合"广播"和"组播"，也天然适合需要自己控制重传策略的场景。比如实时音视频，丢一帧画面比等一秒重传来的体验更好，与其让协议层死等重传，不如上层直接丢掉、继续播下一帧。

四、TCP 与 UDP 全面对比

这张表建议背下来。你在看防火墙规则、排查连接数、分析抓包时，判断服务用哪种协议是最基础的一步。

五、典型应用场景与选型

用 TCP 的场景

凡是"数据完整性优先"的业务，都选 TCP：

• Web 服务：HTTP/1.1 和 HTTP/2 都基于 TCP，端口 80/443。浏览器加载页面时少一个字节都可能出错，必须可靠。
• 远程登录：SSH 走 TCP 22 端口，传输的命令不能丢不能乱。
• 数据库：MySQL 默认 TCP 3306，Redis 6379。事务数据错一个字节都是灾难。
• 邮件传输：SMTP 25、IMAP 143、POP3 110 都基于 TCP。
• 文件传输：FTP、SFTP 依赖 TCP 保证文件完整。

用 UDP 的场景

凡是"实时性优先、能容忍少量丢失"的业务，都选 UDP：

• DNS 查询：默认 UDP 53 端口，一次一问一答，追求快。响应超过 512 字节（或启用 EDNS0 后更大）时才回退到 TCP。
• 实时音视频：VoIP、视频会议用 UDP，宁可有杂音、卡一帧，也不要因重传导致整体延迟飙升。
• 在线游戏：玩家位置、动作指令用 UDP，几十毫秒的延迟就可能影响操作手感。
• DHCP：67/68 端口，客户端还没 IP 地址时用广播获取，UDP 更合适。
• NTP 时间同步：123 端口，本身就是"取个大致时间"。
• QUIC（HTTP/3）：在 UDP 之上自己实现了可靠传输与拥塞控制，兼顾低延迟和可靠性。

选型决策的小口诀

需要"完整、有序、可重传"选 TCP；需要"低延迟、可容忍丢失、自己控制重传"选 UDP。拿不准时，先问一句：这个业务丢一条数据，用户能接受吗？能接受就 UDP，不能就 TCP。

六、用命令验证：你到底在用哪个协议

在服务器上确认服务监听的协议，最直接的工具是 ss。

# 列出所有 TCP 监听端口
ss -lnt

# 列出所有 UDP 监听端口
ss -lnu

# 一起看，并显示进程
sudo ss -lntup

# 查 DNS 服务（通常是 UDP 53 + TCP 53 都在听）
sudo ss -lnup | grep ':53'

参数含义：-l 只看监听状态，-n 不做域名/服务名解析（更快、更准），-t TCP，-u UDP，-p 显示进程。

如果你发现某个服务"客户端连不上"，先确认服务监听的是 TCP 还是 UDP，再看防火墙是否放行了对应协议——很多"端口开了还是不通"的问题，就是因为只在防火墙里放了 TCP，而客户端用的是 UDP。

在防火墙层面，两种协议要分别放行：

# RHEL/CentOS/Rocky 8/9（firewalld）
sudo firewall-cmd --permanent --add-port=53/udp
sudo firewall-cmd --permanent --add-port=53/tcp
sudo firewall-cmd --reload

# Debian/Ubuntu（ufw）
sudo ufw allow 53/udp
sudo ufw allow 53/tcp
sudo ufw reload

风险提示：开放端口前务必确认业务确实需要，生产环境建议只放行必要来源 IP。误加规则可用 firewall-cmd --permanent --remove-port=53/udp && firewall-cmd --reload 回滚；ufw 用 ufw delete allow 53/udp 删除。

七、常见误区

误区一：UDP 就是"不安全的协议"。安全性是 TLS、IPsec 这些上层机制负责的，和 TCP/UDP 无关。QUIC 跑在 UDP 上，照样是加密的。

误区二：UDP 一定比 TCP 快。在丢包严重的网络里，UDP 因为不做重传反而会出现大量空洞，应用层补救的成本可能更高。UDP 的优势在于"可控和低延迟"，不在于绝对速度。

误区三：TCP 保证送达，所以应用层不用管。TCP 只保证"我发出去的字节最终会到达并且有序"，不保证对方应用正确处理。业务层的幂等、超时、重试依然要自己做。

常见问题

Q：为什么 DNS 用 UDP，但有时候又用 TCP？
A：常规查询用 UDP 53 追求速度；当响应数据超过 512 字节（老限制），或启用 EDNS0 后仍超出，以及区域传送（AXFR）必须用 TCP，保证大数据块可靠传输。

Q：同一个端口能同时监听 TCP 和 UDP 吗？
A：可以。TCP 和 UDP 是两个独立的协议空间，53/tcp 和 53/udp 互不冲突，DNS 服务通常两者都监听。

Q：怎么快速判断某个连接用的是哪种协议？
A：用 ss -antp 看 TCP 连接，ss -anup 看 UDP 连接。抓包时 tcpdump -nn tcp 只抓 TCP，tcpdump -nn udp 只抓 UDP。

Q：TCP 三次握手会不会拖慢访问速度？
A：会有一次往返延迟（RTT），但现代内核普遍启用 TCP Fast Open、连接复用等技术来缓解。UDP 无握手，首包延迟更低，这是 QUIC 选 UDP 的原因之一。

Q：视频直播到底用 TCP 还是 UDP？
A：取决于延迟要求。低延迟直播（连麦、会议）用 UDP 类方案（如 WebRTC、SRT）；点播和普通推流常用基于 TCP 的 HLS/RTMP，因为可容忍几秒延迟，更看重稳定。

总结

• TCP 面向连接、可靠、有序，有流量控制和拥塞控制，头部 20 字节起，适合 HTTP/HTTPS/SSH/MySQL 这类"不能错"的业务。
• UDP 无连接、不保证可靠、头部仅 8 字节、无拥塞控制，延迟低、开销小，适合 DNS/QUIC/视频/游戏/VoIP 这类"要快"的业务。
• 选型口诀：丢数据能否接受。不能接受用 TCP，能接受且要求低延迟用 UDP。
• 用 ss -lntup 确认服务监听的协议，防火墙必须按协议分别放行，别只放 TCP 漏了 UDP。
• 安全性、可靠性是可以叠加的，UDP 之上也能做加密和可靠传输，别把协议特性和安全混为一谈。