1. 课程导入与诊断工程定位

各位同行，咱们开始第一课。说实话，我见过太多刚入行的兄弟，一遇到网络不通就慌了神，上来就抓包、ping网关、重启设备，折腾半天找不到根因。为什么？因为脑子里没有一张「地图」。

排错这件事，说白了就是「定位」。你连数据包在哪个环节出了问题都不知道，怎么修？所以今天咱们先把地基打牢——OSI模型、TCP/IP模型、数据封装过程，以及我最常用的一套分层排查思路。

1.1 两个模型，一张底牌

OSI七层模型是理论上的「完美世界」，TCP/IP四层模型是现实中的「实战利器」。我个人的习惯是：面试时聊OSI，干活时用TCP/IP。你想想看，真到机房排障，谁会一层层从物理层问到应用层？但脑子里必须有两套模型的对应关系，否则你连报错日志都看不懂。

1.2 数据封装与解封装：数据包的「变形记」

数据从应用层一路往下走，每经过一层就加一个头部，这叫封装。到了对端，从下往上每层剥掉一个头部，这叫解封装。嗯，听起来很简单，但排错时你必须在脑子里把这个过程「可视化」。

举个例子：你在浏览器输入 https://example.com，数据包经历了什么？

1. 应用层： HTTP请求报文生成，交给传输层。
2. 传输层： 加上TCP头部（源端口、目的端口、序列号），形成Segment。
3. 网络层： 加上IP头部（源IP、目的IP、TTL），形成Packet。
4. 数据链路层： 加上以太网头部（源MAC、目的MAC、类型），尾部加上FCS校验，形成Frame。
5. 物理层： 变成比特流，从网线或光纤发出去。

我曾经在排一个跨机房丢包问题时，抓包发现IP头部TTL值只有1。查了一圈，原来是中间某台路由器配置了ip ttl-expired策略，把正常包当TTL超时给丢了。你看，不懂封装结构，你连抓包里的TTL字段都看不懂。

1.3 排错方法论：分层排查思路

我总结了一套「三层定位法」，这些年帮我解决了不少疑难杂症。说白了就是：先看物理，再看逻辑，最后看应用。

第一步：物理层与数据链路层排查

• 网口指示灯是否正常？光模块收发光功率是否在阈值内？
• 交换机端口有没有err-disable？STP状态是不是Blocking？
• MAC地址表有没有学到对端MAC？

我记得有一次，某数据中心业务中断，监控显示交换机端口up，但流量为0。我过去一看，光模块的发送功率正常，接收功率为-30dBm——明显是光纤断了。但交换机端口为什么还是up？因为某些厂商的光模块在只收不发的情况下，端口状态依然显示up。这就是典型的物理层陷阱。

第二步：网络层排查

• 本地IP配置是否正确？子网掩码、网关有没有配错？
• 路由表里有没有去往目标的路由？下一跳是否可达？
• ping测试：先ping网关，再ping远端IP，注意TTL变化。

第三步：传输层与应用层排查

• 端口是否监听？用netstat -an | grep 端口号确认。
• 防火墙或安全组有没有放行对应端口？
• 应用日志有没有报错？比如SSL证书过期、数据库连接池满。

你想想看，很多新手排错时，一上来就怀疑网络，结果折腾半天发现是应用层的问题——Tomcat挂了、Nginx配置错了、数据库连不上了。所以我的习惯是：先快速确认网络层通不通，如果通，立刻转向应用层排查。

1.4 一张图看懂排错体系

下面这张SVG图，是我自己画的分层排错框架。每次带新人时，我都会让他们先记住这张图。说白了，排错就是沿着这个框架，从上到下或从下到上，逐层排除。

1.5 实战排错口诀与工具清单

最后，分享一个我自编的排错口诀，带新人时屡试不爽：

常用的排错工具，我列了个清单，建议你收藏：