从一次网页打不开说起
前几天同事小李急匆匆跑来问：公司内网的管理后台突然打不开了，但其他网站都正常。他试了重启浏览器、换设备、清缓存，都没用。我让他 ping 了一下地址，发现能通，但 telnet 对应端口却连不上。问题立马指向了协议栈层面。
抓包看真相：tcpdump 上手就用
遇到这种问题，第一反应就是抓包。Linux 下最趁手的工具就是 tcpdump。比如想看本机和某个 IP 的通信情况，直接来一句：
tcpdump -i any host 192.168.1.100 -n如果要盯特定端口，比如 8080，加上 port 条件就行：
tcpdump -i any host 192.168.1.100 and port 8080 -n -s 0 -w capture.pcap这里的 -w 能把原始数据存下来，回头用 Wireshark 打开分析更方便，尤其适合在服务器上抓完带回本地看。
看看连接状态：别忘了 netstat 和 ss
有时候连接卡在半路，就得查本地协议栈的状态。老工具 netstat 还能用，但更推荐 ss，更快更准。比如查所有 TCP 连接：
ss -tuln要是发现某个连接一直处在 SYN-SENT 状态，基本就是出不去；如果是 ESTABLISHED 但没数据流动，可能是应用层卡住了，或者中间设备拦截了数据包。
模拟异常：用 tc 做点“坏事”
开发联调时经常遇到“线上才出问题”的尴尬。这时候可以用 tc 模拟网络延迟或丢包，提前暴露协议栈行为是否健壮。比如给 eth0 加 10% 丢包：
tc qdisc add dev eth0 root netem loss 10%测试完记得清理：
tc qdisc del dev eth0 root这个操作能让应用在弱网下暴露重试逻辑、超时设置等问题，比等线上反馈强多了。
内核参数调一调
有些问题出在协议栈默认配置太保守。比如大量短连接导致 TIME_WAIT 占满端口，可以打开快速回收（注意 NAT 场景慎用）：
sysctl -w net.ipv4.tcp_tw_reuse=1或者调整最大连接数：
sysctl -w net.core.somaxconn=65535改完后用 sysctl -a | grep 相关关键字确认是否生效。
用 eBPF 看更深层的调用
现在越来越多人用 bpftrace 或 BCC 工具集直接挂到内核函数上。比如想看 TCP 连接建立的过程，可以跟踪 tcp_connect：
bpftrace -e 'tracepoint:sock:inet_sock_set_state /\\$args->newstate == 1/ { printf(\"TCP 连接发起: %s \\n\", comm); }'这类工具能帮你看到协议栈内部状态迁移，适合排查一些诡异的连接失败或性能下降问题。
调试协议栈不像修 UI 那样直观，但掌握几个核心工具，很多“玄学”问题都能变得有迹可循。关键不是工具多高级，而是思路要从底层一步步往上捋：物理通不通 → 包有没有发 → 状态对不对 → 应用接不接。”,"seo_title":"网络协议栈调试方法实战指南","seo_description":"分享几种实用的网络协议栈调试方法，涵盖tcpdump抓包、ss查看连接、tc模拟丢包、内核参数调整及eBPF深度追踪技巧，适合系统运维和开发人员参考。","keywords":"网络协议栈,调试方法,tcpdump,ss,netstat,tc,丢包模拟,内核参数,eBPF,bpftrace"}