第1章：网络基础回顾——OSI七层模型与TCP/IP四层模型详解
各位好，我是老张。做网络这行十几年了，每次带新人，我第一件事就是让他们把OSI模型背下来。为什么？因为这是网络世界的「宪法」。你连宪法都不懂，怎么排查故障？
今天咱们就聊聊这两个模型，还有数据封装与解封装的过程。嗯，内容有点干，但都是硬货。
1.1 OSI七层模型：理想化的网络蓝图
OSI模型是国际标准化组织（ISO）在1984年提出的。说白了，它就是个参考框架，告诉你网络通信应该怎么分层。
七层从下到上分别是：
| 层数 | 名称 | 核心功能 | 常见协议/设备 |
|---|---|---|---|
| 7 | 应用层 | 为用户提供网络服务接口 | HTTP、FTP、SMTP |
| 6 | 表示层 | 数据格式转换、加密、压缩 | SSL/TLS、JPEG、ASCII |
| 5 | 会话层 | 建立、管理、终止会话 | NetBIOS、RPC |
| 4 | 传输层 | 端到端可靠传输、流量控制 | TCP、UDP |
| 3 | 网络层 | 路由选择、逻辑寻址 | IP、ICMP、路由器 |
| 2 | 数据链路层 | 帧封装、MAC寻址、差错检测 | 以太网、交换机、PPP |
| 1 | 物理层 | 比特流传输、电气特性 | 网线、光纤、集线器 |
我的小技巧： 记不住七层顺序？试试这句口诀——「物、数、网、传、会、表、应」。我当年考CCNA时，就靠这个口诀拿下的。
你可能会问：为什么非要分七层？其实每层各司其职，下层为上层服务。比如你打开网页，应用层处理HTTP请求，传输层保证数据不丢包，网络层找到服务器在哪，链路层和物理层负责把比特流发出去。哪一层出问题，故障现象都不一样。
1.2 TCP/IP四层模型：实战中的王者
OSI模型虽然完美，但太复杂了。实际互联网用的是TCP/IP模型，只有四层。说白了，就是把OSI的上三层合并成「应用层」，下面两层合并成「网络接口层」。
| TCP/IP层 | 对应OSI层 | 核心协议 |
|---|---|---|
| 应用层 | 5、6、7层 | HTTP、DNS、DHCP |
| 传输层 | 4层 | TCP、UDP |
| 网络层 | 3层 | IP、ICMP、ARP |
| 网络接口层 | 1、2层 | 以太网、Wi-Fi |
重点： 实际工作中，我们99%的故障排查都集中在TCP/IP模型的传输层和网络层。OSI模型更多是用来做理论分析和面试用的。
1.3 数据封装与解封装：数据包的「俄罗斯套娃」
数据封装，说白了就是给数据一层层「穿衣服」。发送数据时，从上往下走，每层加上自己的头部信息。接收数据时，从下往上走，每层脱掉一层衣服。
我举个例子，你访问百度首页：
- 应用层： 浏览器生成HTTP请求数据（比如GET /index.html）。
- 传输层： TCP把HTTP数据包切成段，加上源端口和目标端口（比如80端口）。
- 网络层： IP加上源IP和目标IP地址（比如你的电脑IP和百度服务器IP）。
- 数据链路层： 加上源MAC和目标MAC地址（下一跳路由器的MAC）。
- 物理层： 把帧变成比特流，通过网线发出去。
避坑指南： 我曾经遇到一个故障，用户说网页打不开。我查了半天，发现是MTU设置问题——数据包太大，被中间路由器丢弃了。这就是典型的网络层封装问题。所以，封装时一定要考虑MTU值，一般以太网是1500字节。
解封装就是反着来。接收端从物理层拿到比特流，链路层检查MAC地址对不对，网络层看IP地址是不是自己的，传输层把数据段重组，最后应用层拿到HTTP响应。
1.4 两个模型的实际应用对比
| 场景 | 用OSI模型分析 | 用TCP/IP模型排查 |
|---|---|---|
| 网页打不开 | 可能应用层（HTTP）、传输层（TCP连接）、网络层（路由） | 直接ping测试网络层，telnet测试传输层 |
| 视频卡顿 | 表示层（编码）、传输层（丢包） | 检查UDP丢包率、带宽占用 |
| 无法上网 | 物理层（网线）、数据链路层（MAC）、网络层（IP） | 先看网卡灯亮不亮，再ping网关 |
我的经验： 排查故障时，我习惯从下往上查。先看物理层（网线、光模块），再看链路层（MAC地址、VLAN），然后网络层（IP、路由），最后应用层。这样效率最高，因为底层问题往往更常见。
好了，这一章就到这里。OSI模型和TCP/IP模型是网络工程师的「内功心法」，你理解得越深，排查故障时就越有底气。下一章咱们聊聊物理层和链路层的实战问题，到时候我会分享几个我踩过的坑。
记住：理论是死的，网络是活的。多动手抓包分析，比死记硬背强一百倍。