常见的传输层协议调试场景
你在排查网络连接超时、数据丢包或服务无法访问的问题时，往往问题并不出在应用层，而是藏在传输层。比如公司内部部署的服务突然连不上，ping 又通，这时候就得怀疑 TCP 或 UDP 协议交互出了问题。普通 ping 和 telnet 只能判断端口通不通，没法看到三次握手是否完成、有没有重传、窗口大小如何变化。这时候就需要专业的传输层协议调试工具。
抓包工具：看得见的数据流动
wireshark 是最常用的图形化抓包工具，适合新手上手。打开后选择网卡，设置过滤条件，比如只看 TCP 端口 80 的流量：
tcp port 80你可以清楚地看到 SYN、SYN-ACK、ACK 的完整握手过程。如果客户端发了 SYN 但没收到回应，可能是防火墙拦截；如果服务器回了 SYN-ACK 但客户端没继续 ACK，那可能是客户端网络策略问题。
在服务器环境下更常用的是命令行工具 tcpdump，比如抓取某台 IP 的所有 TCP 流量：
tcpdump -i any host 192.168.1.100 and tcp保存成 pcap 文件后还能用 wireshark 打开分析，适合远程调试。
查看连接状态：netstat 和 ss
有时候不需要抓包，只想快速看看本机的连接情况。Linux 下 netstat 曾经是主力，现在推荐用更高效的 ss：
ss -tuln这条命令列出所有监听中的 TCP/UDP 端口。如果你发现某个服务应该监听 5000 端口却没出现，那根本不是传输层问题，而是服务没启动。
连接处于 TIME-WAIT 或 CLOSE-WAIT 太多？用下面命令看看：
ss -tan | grep CLOSE-WAIT | wc -l数量过大可能意味着客户端没正确关闭连接，或者是服务端处理太慢。
模拟异常：故意制造问题来验证
有时候需要测试系统在丢包或延迟下的表现。Linux 下可以用 tc（Traffic Control）模拟网络异常：
tc qdisc add dev eth0 root netem loss 10%这条命令让 eth0 网卡发出的包有 10% 丢失概率。你就能观察应用是否重试、TCP 是否自动调整窗口。测试完记得清除规则：
tc qdisc del dev eth0 root小工具大用途：nc 和 socat
nc（netcat）被称为“网络瑞士军刀”，可以快速测试端口连通性：
nc -zv 192.168.1.100 443它会告诉你能不能建立 TCP 连接，耗时多少。而 socat 功能更强，支持双向数据流转发，甚至能模拟 TLS 握手：
socat TCP-LISTEN:8080,fork EXEC:/bin/cat这条命令启动一个监听 8080 的服务，把收到的数据原样返回，适合测试客户端行为。
实际案例：API 调用偶尔失败
某次线上接口调用失败率约 5%，日志只显示“连接超时”。先用 tcpdump 抓包，发现客户端发出 SYN 后长时间没收到响应。进一步查服务器 ss 命令输出，发现 80 端口监听正常，但连接数接近上限。原来是连接池配置过小，高峰时新连接进不来。换成 ss 查连接状态后迅速定位，扩容连接池解决。
这类问题靠打日志很难发现，必须深入传输层看真实交互过程。工具不在多，关键是要懂每个字段背后的含义，比如 TCP flags、window size、RTT 变化趋势。