2. 网络基础：OSI模型与TCP/IP协议栈回顾

做网络故障排查，尤其是“Link Up但Ping不通”这种场景，你脑子里得有一张清晰的网络地图。这张地图就是分层模型。我个人习惯，遇到任何连通性问题，第一件事先定层——问题出在第几层？是物理链路、还是网络协议、还是应用配置？模型不乱，排查才有方向。

你想想看，如果没有分层思想，面对一根线缆、一堆IP、一堆端口，你根本不知道从哪下手。我早年刚入行时，就吃过这个亏——对着路由表盯了半天，最后发现是网线插错了端口。嗯，那次之后我就老老实实把OSI模型背下来了。

2.1 为什么我们需要分层模型？

分层本质上是“分而治之”。每一层只关注自己的职责，向上提供标准接口，向下调用邻居服务。这样好处很明显：

• 解耦 – 更换物理介质不影响上层协议（比如从铜缆换光纤，TCP不用改）
• 标准化 – 不同厂商的设备只要遵守层间接口就能互通
• 故障隔离 – 你只需要怀疑某一层，不用全部重查

我在项目中遇到过好几次这种情况：应用层明明报“网络不可达”，结果抓包发现ARP请求根本没发出去——那是数据链路层的问题。如果不懂分层，你可能会去调应用超时参数，白白浪费时间。

2.2 OSI七层模型

OSI七层模型是理论上的完美参考，虽然实际网络没完全按它实现，但它是理解网络通信的“通用语言”。下面的表格帮你快速回顾每一层干了什么：

2.3 TCP/IP四层模型

现实世界跑的是TCP/IP协议栈，它把OSI七层压缩成了四层。说实话，面试时背OSI，干活时用TCP/IP。两者的对应关系一定要记清楚：

注意：ARP虽然工作在IP地址和MAC地址之间，但从分层角度看它属于网络层（3层），因为它封装在以太帧中，但主要功能是地址解析。我见过不少同事把ARP当成二层协议，其实不准确——它同时在二层和三层之间游走。这个细节在故障排查中很关键。

2.4 数据封装与解封装

为什么你Ping通但收不到回复？原因可能藏在封装过程里。数据从应用层一路向下，每经过一层都要加上该层的头部（有些还有尾部）。比如HTTP数据交给TCP加上TCP头，再交给IP加上IP头，最后以太网加上MAC头和FCS尾。对端接收时再从下往上解封装。

我曾经排查过一个诡异问题：链路状态Up，ARP也能解析，但Ping就是不通。后来抓包发现，IP分片后对端重组失败，因为防火墙丢弃了分片包。这就是网络层封装出的问题。你想想看，如果不理解封装，你根本想不到去查分片偏移量吧？

下面的SVG图把OSI七层和TCP/IP四层的对应关系画了出来，还展示了封装与解封装的数据流向。建议你仔细看看，以后排查时脑子里就能自动浮现这张图。

当你面对“Link Up但Ping不通”时，按照这张图从物理层一路查上去：链路状态是否OK？MAC地址表有没有学习到？ARP解析是否成功？IP路由表是否存在？有没有ACL拦截？TCP端口是不是被防火墙封了？每层查完，问题基本就锁定了。