Linux网络排查：TCP与UDP的差异、观测与调优实战

做 Linux 网络排查这些年，我发现自己最常被问到头大的两类问题，总是绕不开传输层的两个协议——UDP 和 TCP。一个发出去就两手一摊不管了，一个建立连接后要一路确认到对方收妥才肯睡；两者明明都跑在 IP 之上，但在 Linux 里的表现、能看到的观测点、能调整的参数，完完全全是两套逻辑。

这篇文章不会只讲教科书上的定义。我想把“Linux 里怎么观察、怎么调整、怎么避坑”这些实际操作经验一起写出来，适合刚开始做网络运维、被“TCP 为什么慢”“UDP 为什么丢包”这类问题反复拷打的新手，也适合正在调内核参数但怕改崩的老手。读完之后，你至少能回答三个问题：这两个协议本质差异在哪、在 Linux 里分别怎么看、真出问题时先从哪里下手。

1. 先把两个协议的分工看明白

1.1 字节流与数据报，一个像水管，一个像快递

TCP 是面向字节流的。你可以把 TCP 想象成一条自来水管：应用层往 socket 里 write 进去的内容，在内核眼里就是一串没有边界的字节。发送方用序列号维护顺序，接收方按序列号把数据重新拼成原始字节流。至于一次 write 对应几次网络发送、接收方一次 read 能读到多少字节，都由内核的缓冲区、窗口和拥塞控制决定，应用层基本不用也不该关心“消息边界”。

UDP 是面向数据报的。它更像快递柜：每次 sendto 投递的是一个完整的包裹，接收端 recvfrom 也必须按包裹来取。一个 2000 字节的报文，如果接收缓冲只有 1024 字节，recvfrom 即使能读到一部分，Linux 也会把读不完的剩余部分直接丢弃，这一点很多人踩过坑：tcpdump 明明看到完整数据包进来了，应用却好像丢失了后半段，最后查下来才发现是对端 recvfrom 的 buffer 开得太小。

这两个模型直接决定了后续所有排障思路。TCP 出了问题，优先看序列号、重传、乱序和窗口；UDP 出了问题，优先看包边界、缓冲区大小和丢包统计。

1.2 要可靠，到底要付出多少额外成本

TCP 的可靠不是免费的。每个连接建立前要三次握手，传输时每个数据段都带着序列号、确认号、窗口、校验和，还要维护一堆发送/接收状态。乱序到达的段要临时入队重排，丢失的段要等超时或快速重传，网络拥塞时要主动降速。这些状态都存在内核里，每个 socket 都有独立的发送缓冲、接收缓冲和传输控制块。

UDP 的成本低得惊人：一个 UDP socket 基本就是“发出去就不管”，没有连接状态机，没有确认重传，没有拥塞控制。你调用 sendto 时，内核只要确认 socket 发送缓冲还有空位，就把数据包交给 IP 层。从 CPU 开销和系统调用次数上看，UDP 确实比 TCP 轻太多，在 Linux 里还能通过 sendmmsg 一次批量发送多个报文，进一步压减系统调用开销。

但这意味着“可靠”这件事被转移到了别处——要么接受丢包，要么在应用层自己实现确认和重传。很多团队选 UDP 是因为快，最后却不得不在应用层造一套类似 TCP 的可靠机制，结果复杂度一点也不低。

1.3 为什么“连接”二字不能随便用

你听人讲 TCP 一定会听到“面向连接”，听人讲 UDP 一定会听到“无连接”。这里的连接不是玄学，是通信前要先在双方内核里建立一套一致的状态。TCP 的三次握手本质上是同步初始序列号、交换窗口信息、分配缓冲区资源；UDP 则没有这个过程，发送方知道 IP 和端口，直接就把数据报丢出去，不需要对方做任何准备。

理解这一点能帮你判断协议选型。两个服务之间需要传输文件、交易记录、配置同步这类数据，TCP 天然合适，因为你要的是不丢、不乱、不重。DNS 查询、音视频实时流、游戏状态同步这类场景，单个请求体量小，或允许少量丢失后由上层重试，UDP 反而干净利落。不是所有业务都值得背 TCP 的状态包袱，这本身就是协议设计的取舍。

2. 头部格式与字段深度解析

2.1 TCP 头部核心字段：序列号、确认号、窗口、标志位

TCP 头部固定部分是 20 字节，加上选项最多可以到 60 字节。别嫌它臃肿，每一个字段背后都有明确用途：

抓包分析时，我最常盯的是“序列号 + 确认号 + 窗口”这组组合。一个数据段的序列号加上它的载荷长度，就是接收方接下来期望收到的序列号；确认号则是告诉对端“你发到 seq + len 为止的数据我都收到了”。窗口字段直接决定对端一次能连续发多少字节，不用等一个 ACK 再发一段。如果窗口越来越小，通常意味着接收端应用读数据太慢，socket 接收缓冲快满了。

2.2 UDP 头部只有 8 字节，却总有人在这里翻车

UDP 头部确实简单：源端口、目的端口、长度、校验和，各 2 字节。其中长度字段表示整个 UDP 报文（头部 + 数据）的字节数，最小值是 8。校验和基于伪 IP 头、UDP 头和载荷计算，IPv4 下允许设置为 0 表示未做校验，IPv6 下则强制启用。

简单不代表没有坑。UDP 报文一旦超过路径 MTU，IP 层会分片。比如你发一个 8000 字节的 UDP 数据报，中间网络设备可能把它拆成多个 IP 分片。分片只要有一个丢失，接收端就无法重组完整 UDP 报文，表现就是上层收到的是“丢包”，而不是“损坏包”。你在抓包里能看到一片齐整的分片序列，但应用永远是缺了某一块。

我之前在某个模拟项目中遇到过类似问题：发端一次性发送大 payload，接收端偶发丢包。排查到最后发现是 IP 分片在中间某台设备上被策略丢弃。TCP 通过 MSS 协商天然避开分片，UDP 没有这个机制，所以设计 UDP 传输时一定要考虑 MTU。简单测试可以这样：

# 用 ping 测试带 DF 标志的包，逐级试探可用 MTU ping -M do -s 1400 192.168.1.10 ping -M do -s 1472 192.168.1.10

如果 ping 不通，就继续调小包体，找到临界值，再回头调整应用的发送缓冲或分块策略。

2.3 抓包里的校验和“0x0000”，不一定是错误

新手最容易误判的一个现象：在发送端 tcpdump 抓包，明明一切正常，却看到 TCP 或 UDP 校验和是 0x0000，于是怀疑网卡坏了或内核有 bug。实际上，这大概率是网卡硬件校验和卸载（checksum offload）在工作。

现在的网卡普遍支持对 TCP/UDP 报文做校验和计算和校验，内核在把包交到驱动时，有时会把校验和字段留空（也就是 0），等网卡在发送时填入。tcpdump 抓到的只是发送路径上的“半成品”，并不是最终上线缆的包；同样，接收方向网卡可能已经校验过，并且把结果放到了内核的元数据里，tcpdump 抓到的包不一定反映真实链路错误。

遇到这种情况，先看网卡当前卸载能力：

ethtool -k eth0 | grep checksum

如果看到 tx-checksum-ip-generic、tx-checksum-tcp-generic 等处于 on 状态，基本可以安心。真正需要警惕的是接收侧统计里的 checksum error 计数暴涨，那才说明链路或者网卡有问题。

3. 在 Linux 上观察两个协议的运行状态

3.1 ss 命令快速看 TCP 连接状态

Linux 上观察 TCP 最顺手的命令就是 ss，可以直接看到内核维护的连接状态表：

ss -s # 汇总统计 ss -tan # 查看所有 TCP 连接状态

状态名里，LISTEN 是正在等待新连接的服务端；SYN-SENT 是客户端发出 SYN 还没收到回应；ESTABLISHED 是正常通信中；FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、TIME-WAIT 则是连接关闭过程中的中间状态。很多人一看到大量 TIME-WAIT 就紧张，其实这是正常现象：主动关闭连接的一方要等足够长的时间，确保最后那个 ACK 不会被网络里的旧包干扰，Linux 默认 TIME_WAIT 约 60 秒。真正要警惕的是 CLOSE-WAIT 持续堆积，那多半是应用收到对端关闭信号后，自己的 close 一直没调，也就是用户态代码堵住了。

ss 输出里的 Recv-Q 和 Send-Q 在不同阶段含义不一样，这点必须分清。对 LISTEN 状态的 socket，Recv-Q 表示 accept 队列中等待应用处理的连接数，Send-Q 表示队列最大长度；对 ESTABLISHED 状态的 socket，Recv-Q 是接收缓冲区里还没被应用读走的字节数，Send-Q 是已写入 socket 发送缓冲但还没被对端确认的字节数。这个区别在排查“表面看起来一堆连接，实际服务却响应很慢”时特别有用。

3.2 UDP 没有连接状态，但队列一眼看穿

UDP 没有连接状态表，但内核同样会给每个 UDP socket 分配收发队列。用下面的命令能看到本机监听的 UDP 端口：

ss -lunp

这里的 Recv-Q 表示接收队列中还没被应用读走的字节数，Send-Q 则是发送队列待处理数据。如果某个 UDP 端口的 Recv-Q 持续增长，说明应用读取速度跟不上到达速度，丢包随时可能发生。很多人只盯 tcpdump 看包有没有进来，却忘了看应用层的读路径。

更底层的数据在 /proc/net/snmp 里，查看 UDP 的统计项：

cat /proc/net/snmp | grep Udp

重点关注 UdpRcvbufErrors 和 UdpSndbufErrors。前者表示因接收缓冲满而丢弃的报文数，后者表示因发送缓冲满而发送失败/丢弃的报文数。只要 UdpRcvbufErrors 在快速上涨，基本可以断定瓶颈在 socket 接收队列。这种场景下可以适当调大系统 UDP 缓冲区：

sysctl -w net.core.rmem_default=8388608 sysctl -w net.core.rmem_max=8388608

注意，这只是让 socket 有更大接收空间，真正能不能消解丢包，还要看应用是不是能及时读。

3.3 监听队列与半连接队列：一个 backlog 引发的“血案”

TCP 服务端 listen(fd, backlog) 背后其实有两层队列：半连接队列（SYN 队列）和全连接队列（accept 队列）。三次握手中，SYN 进来先进入 SYN 队列，对方 ACK 后连接移动到 accept 队列，等待应用 accept。如果应用 accept 太慢，accept 队列满了，新连接就可能被内核丢弃或者直接 RST，svc 端表现为“连接超时”或“连接被拒绝”。

这两个队列的上限受到内核参数影响：accept 队列上限由 nocort listen backlog 和 net.core.somaxconn 中较小的值决定；syn 队列则有 net.ipv4.tcp_max_syn_backlog。排查时最简单的方式还是 ss：

ss -lnt

对 LISTEN 状态的 socket，Recv-Q 达到 Send-Q 的上限时，就说明 accept 队列已经堆积。很多服务刚开始调优时只加大进程里的 backlog，忘了同步调大 net.core.somaxconn，结果队列始终卡在默认值。内核参数一般不建议一上来就猛调，但这两项是安全且常见的：

sysctl -w net.core.somaxconn=1024 sysctl -w net.ipv4.tcp_max_syn_backlog=4096

如果系统开启了 SYN cookies（net.ipv4.tcp_syncookies 为 1），SYN 队列满时还能靠 cookie 机制保住大部分新连接，但代价是每一条连接都要多算 hash，CPU 在攻击高峰会被额外拖累。所以不要觉得有 syncookies 就万事大吉，还是得看队列溢出计数。

4. 传输性能与可靠性的工程取舍

4.1 TCP 的四大机制怎么配合：窗口、重传、拥塞控制

TCP 能稳定扛住各种网络条件，靠的是四个机制互相配合。第一个是序列号与排序：接收端收到乱序段，先放到乱序队列，等前面的段补齐后再向应用交付。第二个是确认与重传：每个段收到后会回 ACK，发送端超时收不到 ACK，或者收到三个相同 ACK 时触快速重传；如果什么都不回，就按 RTO 超时重传。第三个是滑动窗口：让发送端可以在一个窗口内连续发多个段，不用傻等一个 ACK 才发一个，这决定了传输吞吐上限。第四个是拥塞控制：从慢启动逐步增加发送量，发生丢包或延迟涨高时主动降低速率。

Linux 的拥塞控制算法默认是 cubic，适合多数网络。高带宽高延迟的长链路可以选择 BBR，它更看重实测带宽和最小 RTT，而不是靠丢包判断拥塞。切换时需要确认内核支持：

sysctl net.ipv4.tcp_congestion_control=bbr sysctl net.ipv4.tcp_congestion_control

但 BBR 在部分旧设备或窄带宽场景下并不总是最优，改完必须做对比测试后再上线，不能只看原理“看起来很先进”。

4.2 真正的取舍：UDP 不一定是 TCP 的对立面

很多人把 TCP 和 UDP 当成“可靠”与“不可靠”的二元对立，其实更准确的说法是：TCP 把可靠性放进了内核，UDP 把可靠性留给了应用。UDP 之上完全可以自己实现可靠传输，只是你要自己做包序编号、ACK 确认、超时重传、去重、流量控制，相当于重新造一个简化版 TCP。

实际工程里我见过两种典型选择。一种是实时音视频、屏幕共享：数据要求低延迟，丢几帧画面用户不一定感知得到，直接 UDP 或 UDP+FEC 前向纠错，成本低见效快。另一种是协议本身有重试机制的业务，比如很多轻量控制协议，单次请求包很小，丢了就让应用层重新发一次，根本不需要 TCP 那么重的连接维护。可以说，UDP 的真正优势不在“快”，而在“没有连接包袱”。值得留意的是，近年来越来越多新协议选择在 UDP 之上做可靠传输，就是看中 UDP 作为基础通道足够灵活，能让上层重新定义连接、迁移、加密、重传策略，而不受传统 TCP 状态机束缚。这不是否定 TCP，恰恰说明传输层的选择是工程问题，不是站队问题。

4.3 一轮实测后的踩坑结论

某个模拟项目 X 里，我对比过同一台机器、同一张虚拟网卡上 TCP 与 UDP 的吞吐表现，结论很有代表性。TCP 在 0.1% 丢包率的环境下，吞吐掉得非常明显，因为拥塞控制会把 cwnd 收敛，慢启动又从低点爬升；UDP 看起来能打满带宽，但发送端完全不管链路状态，接收端淡淡一句话“丢了不少包”，应用上层没有任何机制发现。

当时我们以为是协议不行，后来抓包才发现，瓶颈其实不在传输层，而是接收端应用一次只读 8KB，UDP 64KB 的接收缓冲被秒满，大量报文在 socket 队列里被内核丢弃。给应用加大读缓冲、调整 GRO 合包策略之后，数据就顺畅了。这件事提醒我：先确认瓶颈在用户态还是内核态，再决定是不是传话给协议背锅。

5. 常见问题与排查经验实录

5.1 先按这张表排查，能省掉一半时间

我在排障的时候习惯先跑一张“自查表”，用几个核心指标快速圈定问题的层面，再深入下去。按下面这张表走完，大部分网络问题至少能定位到方向：

5.2 一次真实的 UDP 丢包排查

有一次某内部测试场景反馈“UDP 监控数据高峰时段总是间歇丢失”，第一反应是链路丢包，但拿流量统计和误码率一比，链路完全正常。随后我在接收端执行 ss -lun，看到问题端口 Recv-Q 在不断增大；再查看 /proc/net/snmp 的 UdpRcvbufErrors，计数的增长节奏和业务高峰完全吻合，马上确认是 socket 接收缓冲不足。

接着用 strace 跟了一下应用进程，发现读取线程在单次循环里做了很多无关处理，导致 recvfrom 调用频率上不去；内核缓冲区一再加大也只是“推迟丢包”，不能根治。后来我们减小每次读取块大小、增加读取线程数量，同时把 net.core.rmem_max 从默认值提升到合适水位，再用 ss 观察队列曲线，Recv-Q 才真正稳定下来。这次经验让我养成一个习惯：凡是排查丢包，永远先分清“链路丢包、内核丢包、用户态丢包”三个层面，再决定改参数还是改代码。

5.3 几个必须记住的注意项

第一，不要为了提升 UDP 接收能力无脑调大缓冲区。缓冲越大，积压的数据越多，应用读到的数据越陈旧，延迟越高；如果应用不改进读数频率，内存加得再多也只是把突发丢包抹平成持续延迟。一般建议先把 rmem_max 调到应用突发流量的合理倍数，再配合读取线程优化一起做。

第二，不要为了“提升性能”关闭 UDP 校验和。IPv4 下虽然允许关闭，但一旦链路误码率上升，接收端没有任何感知，坏数据会被当作正常数据交给应用。某些极端场景（比如同网段监控抓包、可接受重发、链路质量极稳定）可以考虑，生产环境不要赌这个。

第三，TCP 调参不要只改一个数。把 socket 发送缓冲调大，却不调大接收缓冲，只会让两个方向能力不对称；把拥塞控制切到 BBR，却完全不看当前带宽和 RTT 特征，可能适得其反。任何改动都应该是“参数组合 + 回归测试”的形式，并且保留回滚预案。

最后说一个我自己的排查习惯：到了现场先看时间线，再看内核统计，最后才碰协议栈。网络问题先用“目标 IP、目标端口、协议、包大小”四个维度把范围缩小，再在收发两端同时抓包，避免单边抓包带来的误判。UDP 和 TCP 没有谁绝对比谁好，它们只是站在可靠性和实时性这两个不同的坐标上，各管一头。