1. 故障应急总览：协议栈故障分类、应急响应流程、故障排查工具箱概览
网络协议栈出问题，说白了就是数据从应用层到物理层的某一段“卡住了”。我干了十几年网络运维，见过最离谱的一次——整个公司断网两小时，最后发现是网线被老鼠咬了一半。嗯，从那以后我再也不敢小看物理层。
这一章咱们先搭个框架。你得知道故障分几类、出了事先干嘛、手头该备什么工具。别一上来就抓包，先想清楚方向。
1.1 协议栈故障分类
我个人习惯把故障按OSI七层模型分层归类。这样定位快，也方便团队协作。你想想看，应用层报错和链路层丢包，排查思路完全不一样。
| 故障层 | 典型表现 | 常见原因 |
|---|---|---|
| 应用层 (L7) | HTTP 500、DNS解析失败、SSL握手超时 | 配置错误、证书过期、后端服务挂掉 |
| 传输层 (L4) | TCP重传率高、连接超时、端口不可达 | 防火墙拦截、队列溢出、MTU问题 |
| 网络层 (L3) | 路由黑洞、ICMP不可达、TTL超时 | 路由表错误、BGP策略、环路 |
| 链路层 (L2) | MAC地址冲突、STP震荡、CRC错误 | 环路、网卡故障、线缆质量差 |
| 物理层 (L1) | 端口down、光衰过大、信号干扰 | 光模块损坏、线缆断裂、电源问题 |
核心原则：从底层往上查，先确认物理层和链路层通不通，再谈上层协议。我见过太多人一上来就分析应用日志，结果发现网线都没插好。
1.2 应急响应流程
故障来了别慌。我总结了一个“三分钟止血法”，团队里用了好几年，效果不错。
- 确认影响范围——是单点还是全网？用户还能不能访问？
- 快速回滚或隔离——如果是变更导致的，先回滚。别纠结根因，先恢复业务。
- 收集现场信息——抓包、日志、计数器。记住，重启前一定要留证据。
- 分层定位——按1.1节的分类，逐层排除。
- 修复验证——改完配置要验证，别留尾巴。
我曾经踩过的坑：有一次线上故障，我直接重启了核心交换机。结果问题确实消失了，但重启后日志全没了，根本查不到根因。后来发现是某个模块的固件bug，重启只是暂时缓解。所以——重启前，先抓包、存日志、拍下当前状态。
1.3 故障排查工具箱概览
工具不在多，在于精。我平时随身带的就这几样，覆盖了从L1到L7的排查需求。
| 工具 | 适用层 | 常用场景 |
|---|---|---|
| ping / fping | L3 | 快速检测连通性、丢包率 |
| traceroute / mtr | L3 | 定位路径中的跳数和延迟 |
| tcpdump / Wireshark | L4-L7 | 抓包分析重传、握手、应用协议 |
| ss / netstat | L4 | 查看端口监听、连接状态 |
| ip / ifconfig | L2-L3 | 查看接口状态、IP配置、路由表 |
| ethtool | L1-L2 | 查看网卡速率、双工、CRC错误 |
| curl / wget | L7 | 模拟HTTP请求，测试应用层响应 |
我的小习惯：写一个简单的排查脚本，把常用的命令串起来。比如先ping网关、再traceroute目标、然后ss看端口、最后curl测试。一键执行，省时间。
1.4 故障排查逻辑图
下面这张图是我自己画的排查逻辑。每次出问题，我就按这个流程走一遍，基本不会漏。
1.5 避坑指南
- 别信直觉，信数据。 我曾经凭经验判断是DNS问题，折腾了半小时，结果tcpdump一看，是网卡协商成了10M半双工。
- 抓包要抓对方向。 在客户端和服务端同时抓，对比看。单端抓包容易漏信息。
- 别忽略时间戳。 很多故障是间歇性的，没有时间戳你根本对不上号。
- 变更记录要留好。 我见过最坑的一次，运维同事凌晨改了防火墙规则没通知，第二天全组排查了三个小时。
一句话总结：故障排查不是技术活，是逻辑活。按流程走，用工具说话，别拍脑袋。