1. 网络协议栈概述：OSI七层模型与TCP/IP四层模型对比，协议栈核心组件介绍，故障排查的通用方法论
做网络故障排查这么多年，我最大的体会是——不懂协议栈，你连问题出在哪一层都说不清。很多刚入行的兄弟，一上来就抓包、ping、traceroute，折腾半天发现方向都错了。说白了，你得先有一张地图，才知道自己站在哪。
这一章，我们就先把这张地图画清楚。
1.1 为什么需要分层？
你想想看，一次网络通信，从你敲下回车到数据到达服务器，中间经历了多少环节？
- 应用程序把数据准备好
- 操作系统把数据打包
- 网卡把数据转成电信号
- 交换机、路由器一层层转发
- 对端再一层层拆包
如果所有逻辑都写在一个模块里，改一个地方就得动全局。分层的好处就是各层只管自己的事，层与层之间通过标准接口通信。哪一层出问题，就只修哪一层。
核心原则：每一层都为上层提供服务，并屏蔽下层的实现细节。这就是协议栈分层的本质。
1.2 OSI七层模型 vs TCP/IP四层模型
教科书上都会讲这两个模型。我直接说人话：OSI是理论上的完美模型，TCP/IP是实际在用的模型。
OSI七层模型，从上到下分别是：
- 应用层 —— HTTP、FTP、SMTP，用户直接打交道
- 表示层 —— 数据加密、压缩、格式转换
- 会话层 —— 建立、管理、终止会话
- 传输层 —— TCP/UDP，端到端可靠传输
- 网络层 —— IP路由，寻址和转发
- 数据链路层 —— MAC地址，帧封装，差错检测
- 物理层 —— 比特流，电信号，光信号
而TCP/IP四层模型，把上面三层合并成应用层，下面两层合并成网络接口层，中间保留传输层和网络层。
| OSI七层 | TCP/IP四层 | 典型协议/设备 | 故障排查关注点 |
|---|---|---|---|
| 应用层 | 应用层 | HTTP, DNS, FTP, SMTP | 服务是否启动？配置是否正确？ |
| 表示层 | SSL/TLS, JPEG, ASCII | 加密证书是否过期？编码是否一致？ | |
| 会话层 | NetBIOS, RPC | 会话是否超时？认证是否通过？ | |
| 传输层 | 传输层 | TCP, UDP | 端口是否可达？连接是否建立？重传率高不高？ |
| 网络层 | 网络层 | IP, ICMP, ARP | 路由是否可达？TTL是否耗尽？ |
| 数据链路层 | 网络接口层 | 以太网, PPP, MAC | MAC地址是否冲突？交换机端口是否up？ |
| 物理层 | 网线, 光纤, 信号 | 网线是否松动？光模块是否正常？ |
我的习惯：排查问题时，我一般先用TCP/IP四层模型快速定位，再用OSI七层模型细化。比如应用层出问题，我会去检查表示层的证书、会话层的超时设置——这些在四层模型里被合并了，但实际排查时不能忽略。
1.3 协议栈核心组件
光知道分层还不够，你得知道每一层里到底有哪些关键组件在干活。我挑几个最常打交道的说说。
1.3.1 应用层核心组件
- HTTP/HTTPS —— Web服务的基石。我遇到过最坑的一次，是证书链不完整导致客户端一直报SSL错误，抓包看了半天才发现中间证书没配。
- DNS —— 域名解析。很多“网络不通”的问题，其实是DNS解析失败。先ping IP，再ping域名，这是基本功。
- Socket —— 应用与传输层的接口。说白了就是IP+端口，应用程序通过它收发数据。
1.3.2 传输层核心组件
- TCP —— 面向连接、可靠传输。三次握手、四次挥手、滑动窗口、拥塞控制。排查TCP问题，我最常用的命令是
ss -tpan和tcpdump。 - UDP —— 无连接、尽力交付。视频流、DNS查询常用。UDP出问题很难排查，因为对端不会告诉你丢包了。
- 端口 —— 0-65535。0-1023是知名端口，1024-49151是注册端口，49152-65535是动态/私有端口。
1.3.3 网络层核心组件
- IP —— 寻址和路由。IPv4地址耗尽，IPv6正在普及。我记得有一次客户说跨网段访问慢，查了半天是路由表里有一条错误的路由，导致流量绕路了。
- ICMP —— 网络诊断。ping和traceroute就是基于ICMP的。但要注意，很多防火墙会屏蔽ICMP，这时候ping不通不代表网络不通。
- ARP —— IP到MAC的映射。ARP欺骗是局域网攻击的常见手段。
1.3.4 数据链路层与物理层核心组件
- MAC地址 —— 硬件地址，48位。交换机靠MAC地址表转发帧。
- 以太网帧 —— 前导码、目标MAC、源MAC、类型、数据、FCS。FCS校验失败说明链路层有比特错误。
- 网卡/光模块/网线 —— 物理层的东西。我曾经被一根劣质网线坑了三天，丢包率忽高忽低，换了根线就好了。
避坑指南：我曾经遇到一个案例，服务器之间ping延迟正常，但TCP传输速度极慢。抓包发现TCP窗口一直在0附近徘徊，是接收端应用程序处理不过来导致的。如果只看ICMP的ping，你永远找不到问题。
1.4 故障排查的通用方法论
方法比工具重要。我总结了一套通用的排查思路，不管你是新手还是老手，照着这个流程走，至少不会跑偏。
1.4.1 七步排查法
- 明确现象 —— 用户说“上不了网”，你得问清楚：是上不了所有网站，还是某个网站？是WiFi不行还是有线也不行？
- 确定范围 —— 是个别用户还是全网？是某个时间段还是持续？范围越小，问题越容易定位。
- 从底层开始 —— 物理层→链路层→网络层→传输层→应用层。先确认网线插好了，再查IP配置，再查路由，再查端口，最后查应用。
- 使用工具验证 —— ping、traceroute、telnet、curl、tcpdump、Wireshark。每个工具都有它的适用层。
- 对比正常与异常 —— 找一台正常的设备做对比，配置、日志、抓包，差异就是线索。
- 假设验证 —— 提出一个假设，做一次测试。比如“我怀疑是DNS问题”，那就直接ping IP试试。
- 记录与复盘 —— 把排查过程、结论、解决方案记下来。下次遇到类似问题，直接翻笔记。
1.4.2 分层排查的典型思路
举个例子，用户反馈“网页打不开”。我会这样排查：
- 物理层： 网线灯亮不亮？WiFi信号强不强？
- 链路层： 能不能获取到IP地址？ARP表有没有记录？
- 网络层： ping网关通不通？ping DNS服务器通不通？traceroute到目标IP，看在哪一跳断了。
- 传输层： telnet目标IP 80端口通不通？TCP三次握手有没有完成？
- 应用层： curl -v 看看HTTP响应码是多少？是404、500还是连接超时？
我的习惯：我一般会先ping网关，再ping一个公网IP（比如8.8.8.8），再ping域名。三步下来，基本能判断是网络层的问题还是DNS的问题。整个过程不超过30秒。
1.5 本章知识体系总览
下面这张图，把本章的核心内容串起来了。你可以把它当作一张地图，以后排查问题时，随时回来对照。
嗯，这张图把OSI七层、TCP/IP四层和排查方法论放在一起对比。你排查问题时，先看现象属于哪一层，然后从那一层开始往下查。记住：不要跳层，不要猜，用工具说话。
这一章的内容就到这里。协议栈是网络世界的骨架，后面的每一章都会围绕这个骨架展开。你先把这张图记在脑子里，后面遇到具体问题，就知道该从哪里下手了。