2. 通信基础回顾：OSI七层模型、TCP/IP四层模型、数据封装与解封装过程
各位同学，咱们今天聊点基础，但也是最重要的基础。
做轨道交通售货机通信，说白了就是让机器跟后台服务器“说话”。但这两边怎么保证能听懂？数据怎么打包、怎么拆包？这就绕不开两个经典模型：OSI七层模型和TCP/IP四层模型。
我个人习惯，不管做多复杂的协议，先把这两个模型刻在脑子里。为什么？因为它们是通信的“交通规则”。
2.1 OSI七层模型：理论上的完美蓝图
OSI模型，全称开放系统互连参考模型。它是国际标准化组织（ISO）在1984年提出的。说实话，这个模型在实际工程中很少被完整实现，但它提供了一个绝佳的“思维框架”。
七层，从下往上分别是：
| 层号 | 名称 | 核心功能 | 我眼中的角色 |
|---|---|---|---|
| 7 | 应用层 | 为用户提供网络服务接口 | 售货机的“业务员” |
| 6 | 表示层 | 数据格式转换、加密、压缩 | “翻译官” |
| 5 | 会话层 | 建立、管理、终止会话 | “会议主持人” |
| 4 | 传输层 | 端到端可靠传输（TCP/UDP） | “快递公司” |
| 3 | 网络层 | 路由选择、逻辑寻址（IP） | “导航员” |
| 2 | 数据链路层 | 帧封装、MAC寻址、差错检测 | “送货员” |
| 1 | 物理层 | 比特流传输、电气特性 | “马路” |
你想想看，这七层每一层都只关心自己的事。下层为上层服务，上层调用下层接口。这种分层思想，在我们定制售货机协议时特别有用——你可以只改应用层，底层网络不用动。
核心要点：OSI模型是“理论模型”，它定义了通信应该怎么做。但在实际工程中，我们很少严格按七层来开发。不过，理解它有助于你理解“封装”和“解封装”的本质。
2.2 TCP/IP四层模型：工业界的实战标准
好了，理论说完了，咱们聊聊实战用的。
TCP/IP模型，也叫互联网协议套件。它把OSI七层压缩成了四层：
- 应用层（对应OSI的5、6、7层）
- 传输层（对应OSI的第4层）
- 网络层（对应OSI的第3层）
- 网络接口层（对应OSI的1、2层）
为什么TCP/IP更常用？因为它更“务实”。
我记得在做一个地铁售货机项目时，现场网络环境特别复杂——有4G、有Wi-Fi、还有有线以太网。如果用OSI模型去套，你得考虑每一层的实现，太繁琐了。而TCP/IP模型直接帮你把物理层和数据链路层合并了，你只需要关心IP和端口就行。
我的建议：做轨道交通售货机通信，重点掌握TCP/IP模型。OSI模型用来“理解”，TCP/IP模型用来“干活”。
2.3 数据封装过程：从应用数据到比特流
数据封装，说白了就是“打包发货”的过程。
假设你的售货机要发送一条指令：“查询库存”。这条指令在应用层只是一个字符串。但到了网络上，它必须被层层打包。
封装过程如下（从上往下）：
- 应用层：原始数据（比如“查询库存”的JSON字符串）
- 传输层：加上TCP头部（源端口、目的端口、序列号等），形成数据段
- 网络层：加上IP头部（源IP、目的IP），形成数据包
- 数据链路层：加上MAC头部（源MAC、目的MAC）和尾部FCS校验，形成数据帧
- 物理层：将帧转换成比特流，通过网线或无线发送出去
我画个简单的示意图（文字版）：
应用层数据: [查询库存]
↓ 添加TCP头
传输层数据段: [TCP头][查询库存]
↓ 添加IP头
网络层数据包: [IP头][TCP头][查询库存]
↓ 添加MAC头 + FCS尾
数据链路层帧: [MAC头][IP头][TCP头][查询库存][FCS]
↓ 转换成比特流
物理层: 101010101010...嗯，这里要注意：每一层都会给数据“加个壳”。这个壳就是协议头部。接收方收到后，再一层层“脱壳”，这就是解封装。
避坑指南：我曾经在调试售货机时，发现数据总是丢包。查了半天，原来是MTU（最大传输单元）设置不对。数据链路层对帧大小有限制，如果应用层数据太大，IP层会分片。分片多了，丢包率就上去了。所以，设计应用层协议时，尽量控制单条指令在1KB以内。
2.4 数据解封装过程：从比特流到应用数据
解封装就是封装的逆过程。接收方从物理层拿到比特流，然后一层层往上“脱衣服”。
- 物理层：收到比特流，交给数据链路层
- 数据链路层：检查MAC地址是否匹配，校验FCS。如果没问题，去掉MAC头和尾，把数据包交给网络层
- 网络层：检查IP地址，去掉IP头，把数据段交给传输层
- 传输层：检查端口号，去掉TCP头，把原始数据交给应用层
- 应用层：拿到“查询库存”指令，执行相应逻辑
你想想看，这个过程就像快递包裹。你收到一个箱子，先撕掉外面的快递单（MAC头），再打开箱子看到里面的产品包装（IP头），再打开包装看到说明书（TCP头），最后才看到产品本身（应用数据）。
关键点：每一层只处理自己关心的头部信息。数据链路层不看IP，网络层不看TCP，传输层不看应用数据。这种“各司其职”的设计，让通信系统变得非常灵活。
2.5 在售货机协议定制中的应用
好了，理论讲完了，咱们说说怎么用。
做轨道交通售货机，我建议你重点关注三层：
- 应用层：这是你定制协议的主战场。定义指令格式、数据编码、心跳机制等。比如我习惯用JSON格式，简单明了，调试方便。
- 传输层：选TCP还是UDP？售货机交易类指令（扣款、出货）必须用TCP，保证可靠。状态上报可以用UDP，减少网络开销。
- 网络层：IP地址规划。地铁站内售货机数量多，建议用私有IP段，配合NAT转换。
举个例子，我设计的一个售货机心跳包，应用层数据只有20字节：
{
"cmd": "heartbeat",
"dev_id": "VM-001",
"ts": 1700000000
}这个数据经过TCP封装后，变成40字节左右的TCP段。再加上IP头20字节，MAC头14字节，总共不到100字节。这样的设计，既保证了实时性，又节省了带宽。
个人经验：刚开始做售货机通信时，我总想把所有信息都塞到一个包里。结果数据包动不动就几KB，网络稍微波动就超时重传。后来我学乖了——小包、高频、轻量，这才是嵌入式通信的黄金法则。
最后总结一句：OSI七层模型是“教科书”，TCP/IP四层模型是“工具箱”。数据封装和解封装，就是数据在模型中的“旅行”。理解了这些，你就能设计出既符合标准、又贴合实际场景的售货机通信协议。
下一章，咱们聊聊具体的协议设计方法。到时候我会拿一个真实的售货机项目案例来拆解，敬请期待。