做服务器维护，最怕的就是服务突然抽风，用户连不上，接口超时，日志又没报错。这时候问题很可能出在传输层——TCP 或 UDP 的连接、重传、挥手这些环节一旦卡壳，上层应用再稳也没用。
为啥要用传输层协议调试工具？
比如上周公司官网支付接口偶发性超时，查了一圈后端代码和数据库都没问题。最后用 tcpdump 抓了包才发现，客户端发了 SYN 请求，服务器回了 SYN-ACK，但客户端没发 ACK，三次握手卡在最后一步。原来是前端负载均衡器的连接池配置太激进，导致部分连接状态混乱。这种问题光看日志根本发现不了。
几个实用的调试工具推荐
tcpdump 是最常用的命令行抓包工具，能直接捕获网卡上的原始数据包。比如想看 80 端口的 TCP 流量：
tcpdump -i eth0 -n port 80 and tcp加上 -w capture.pcap 还能保存文件，拿去 Wireshark 里慢慢分析。
Wireshark 是图形化抓包神器，支持上百种协议解析。双击一个数据包就能看到 TCP 头里的序列号、确认号、窗口大小、标志位（SYN、ACK、FIN）等细节。遇到连接频繁重传或延迟确认，靠它一眼就能定位。
还有个轻量级工具 ss，用来查看当前系统的 socket 状态比 netstat 更快更准。比如查所有处于 TIME-WAIT 状态的连接：
ss -t state time-wait如果怀疑是 MTU 或分片问题，可以用 ping 加 -M do -s 参数测试路径最大传输单元：
ping -c 4 -M do -s 1472 example.com这个命令发的是不分片的 ICMP 包，如果通不过，说明中间链路 MTU 小于 1500，可能影响大块数据传输。
真实场景：API 响应慢，其实是 TCP 挥手拖沓
有一次用户反馈后台操作卡顿，查接口平均响应时间才 200ms，不算慢。但用 Wireshark 一抓包发现，每个请求之后都有长达 60 秒的 FIN-WAIT 阶段。原因是服务端没开启 SO_REUSEADDR，大量短连接积压在 TIME-WAIT 状态，端口被占满。调整内核参数 net.ipv4.tcp_tw_reuse = 1 后问题缓解。
这类问题不会报错，监控也未必告警，但用户体验就是差。只有深入传输层，才能看到背后的真相。
小贴士：别忘了 UDP 的坑
UDP 虽然无连接，但调试起来也不轻松。比如直播推流丢包，可能是网络问题，也可能是应用层发太快。用 tcpdump 抓 UDP 流量，配合时间戳分析间隔，能判断是不是发送频率超标。有时候降低帧率比换网络还管用。
工具本身不难学，关键是得有“往下看一层”的意识。应用日志没问题，不代表通信就顺畅。传输层就像水管，水龙头出水慢，未必是龙头坏了，可能是管道堵了。