从一次网页打不开说起
前两天邻居老李找我，说家里Wi-Fi能连上，手机也能刷短视频，但就是打不开某个购物网站。我拿电脑一试，发现浏览器卡在“正在连接”不动。这种情况，表面看是网络问题，实际得往深了查——问题很可能出在网络协议栈上。
很多人觉得协议栈是底层技术，只有程序员才需要懂。其实不然，只要你会用电脑、会连Wi-Fi，掌握一些基础的调试方法，就能自己排查不少问题。
第一步：用 ping 测通路
最简单的检查方式是 ping。打开命令行，输入：
ping www.baidu.com如果返回超时，说明IP层通信有问题。可能是路由不通，也可能是目标主机屏蔽了ICMP。再试试本地网关，比如：
ping 192.168.1.1如果网关能通，外网不通，那问题大概率出在路由器或外网链路；如果网关都ping不通，那得看看本机网卡配置有没有问题。
第二步：抓个包看看真实情况
ping只能告诉你通不通，但看不到细节。这时候就得上抓包工具。Wireshark 是最常用的，安装后选中当前网卡开始捕获。
比如刚才老李的问题，抓包发现TCP三次握手卡在第二次——客户端发了SYN，服务器回了SYN-ACK，但本机没发ACK。这说明协议栈在接收响应后出了问题，可能是因为防火墙拦截，或者系统TCP缓冲区异常。
如果你不想装软件，Linux下可以用 tcpdump：
tcpdump -i wlan0 host www.example.com -w capture.pcap抓下来的包可以拖进Wireshark分析，方便又直观。
第三步：查看系统协议栈状态
Linux用户可以看看 /proc/net/ 下的信息。比如：
cat /proc/net/tcp这里列出所有TCP连接，State字段用十六进制表示状态。06 是 ESTABLISHED，01 是 SYN_SENT，对照着看就能知道连接卡在哪一步。
Windows 用户可以用命令：
netstat -an | find "80"查看是否有大量 TIME_WAIT 或 CLOSE_WAIT，这些堆积可能意味着应用没及时释放连接。
第四步：调整内核参数辅助调试
有时候问题藏得更深。比如频繁断连，可能是系统默认的TCP重传次数太低。Linux下可以临时调高：
sysctl -w net.ipv4.tcp_retries1=6
sysctl -w net.ipv4.tcp_retries2=15或者开启TCP时间戳来更好分析丢包：
sysctl -w net.ipv4.tcp_timestamps=1改完后重现问题，再抓包，能看到更多重传和RTT信息。
别忘了应用层的日志
协议栈跑得好好的，应用也可能自己出错。浏览器F12开发者工具里的“Network”标签，能看到每个请求的DNS解析、TCP连接、TLS握手耗时。如果某一步特别慢，就知道该往哪查了。
比如有个公司内部系统一直加载慢，结果一看是DNS解析花了3秒，回头一查，果然是本地DNS缓存服务挂了。
小技巧：模拟异常环境测试
想验证协议栈行为？可以用 tc 工具人为制造网络问题。比如加延迟：
tc qdisc add dev eth0 root netem delay 300ms或者丢包：
tc qdisc add dev wlan0 root netem loss 10%这样能观察程序在弱网下的表现，是不是会频繁重连，或者直接崩溃。
调试网络协议栈，不一定要懂所有RFC文档。关键是会用工具，看得懂基本流程。遇到问题，从ping开始，一步步往上查，结合抓包和系统状态，大多数异常都能定位到根子上。