2. Matter协议栈与WiFi承载
Matter 并不是一种全新的无线通信技术，它更像是一套“应用层通用语言”加上“基于 IP 的传输约定”。理解 Matter 与 WiFi 的关系，关键要抓住一句话：Matter 负责设备之间“说什么、怎么交互”，WiFi 负责“把 IP 报文送到对端”。两者处在不同协议层次，通过 IPv6 这一共同底座衔接起来。本节从协议分层入手，逐层拆解 Matter 应用层、数据模型、交互模型，以及 WiFi 作为底层承载时的实际数据路径。
一、分层视角：Matter 站在 IP 之上，WiFi 站在 IP 之下
把 Matter 设备想象成一栋楼：WiFi 是楼外的道路和运输系统，IPv6 是统一的门牌地址体系，Matter 则是楼内各房间约定的沟通规则。Matter 规范明确定义自己运行在 IPv6 之上，因此它并不关心底层是 WiFi、以太网还是 Thread——只要该链路能承载 IPv6，Matter 就能工作。WiFi 承载时，典型的分层自下而上是：
- 物理层/数据链路层：WiFi（IEEE 802.11，常见 2.4GHz，也支持 5GHz），负责无线帧的调制、信道接入与 MAC 寻址。
- 网络层：IPv6，为每个节点分配地址，负责跨网段路由；Matter 依赖 IPv6 的链路本地地址与全局地址。
- 传输层：UDP 与 TCP。Matter 的操作交互主要走 UDP（配合消息可靠重传机制），部分场景使用 TCP。
- Matter 会话层/安全层：负责会话建立、消息加密（AES-CCM）、重传与去重、消息计数器。
- Matter 交互模型层：定义 Read/Write/Invoke/Subscribe 等交互动作。
- Matter 数据模型层：用 Cluster、Attribute、Command、Event 描述设备能力。
- 应用层：具体业务逻辑，如开关灯、调亮度、读温度。
下面这张图把上述分层与 WiFi 承载时的实际数据路径画在一起，注意观察“应用数据如何一路封装到 WiFi 帧，再在对端逐层解封”。
二、数据模型：设备能力的“结构化描述”
Matter 数据模型是设备对外暴露能力的标准结构。最上层是 Node（节点），一个节点可以包含多个 Endpoint（端点），每个端点下挂若干 Cluster（簇），簇内再包含 Attribute（属性）、Command（命令） 和 Event（事件）。以一盏可调光智能灯为例：
- Endpoint 1 表示“灯”这个功能单元；
- OnOff Cluster（0x0006）提供 OnOff 属性与 On/Off/Toggle 命令；
- LevelControl Cluster（0x0008）提供 CurrentLevel 属性与 MoveToLevel 命令；
- Descriptor Cluster 描述该端点支持哪些簇，供控制器发现能力。
这种模型的价值在于：控制器不需要厂商私有协议，只要按标准簇定义读写属性、调用命令，就能控制不同品牌的设备。属性有明确的数据类型（布尔、8 位无符号整数、枚举等）和取值范围，例如 CurrentLevel 通常为 0～254，0 表示最暗、254 表示最亮。
三、交互模型：控制器与设备之间的四种基本动作
Matter 交互模型定义了应用层如何交换数据，核心有四类：
| 交互 | 方向 | 典型用途 |
|---|---|---|
| Read | 控制器 → 设备 | 读取属性当前值，如查询灯是否开启 |
| Write | 控制器 → 设备 | 写入属性，如设置默认亮度 |
| Invoke | 控制器 → 设备 | 调用命令，如执行开灯、调亮度 |
| Subscribe | 控制器 → 设备 | 订阅属性/事件变化，设备在变化时主动上报 |
其中 Subscribe 是 Matter 体验流畅的关键。控制器订阅 OnOff 属性后，设备状态一旦变化（例如被物理开关改变），会主动推送报告，而不是让控制器轮询。这减少了网络流量，也让 App 界面能实时刷新。交互消息通过会话层加密传输，并带有消息计数器防止重放。
四、WiFi 承载：从 Matter 消息到 802.11 帧
当底层是 WiFi 时，Matter 消息的旅程大致如下：应用层生成命令 → 数据模型编码为 TLV → 交互模型封装为 Matter 消息 → 会话层加密并附加消息头 → 交给 UDP → 加上 IPv6 头 → 由 WiFi 驱动封装成 802.11 数据帧 → 经无线信道发送。接收端反向解封，最终由应用层执行动作。
这里有两个实践要点。第一，IPv6 地址：WiFi 节点通常同时拥有链路本地地址（fe80::/10）和由路由器分配的全局地址。Matter 设备入网后通过 mDNS/DNS-SD 广播自己的服务信息，控制器据此发现设备并建立会话。第二，UDP 端口：Matter 使用固定端口进行通信（操作端口 5540），防火墙或 AP 的客户端隔离功能若阻断该端口或禁止组播，会导致设备无法被发现或控制。
五、一个可观察的示例：调亮度命令的完整路径
假设控制器要把灯的亮度设为 128，可以按下面的思路观察整个过程：
- 控制器在已订阅的 LevelControl 簇上调用 MoveToLevel 命令，参数 Level=128、TransitionTime=0。
- 命令被编码进 Matter 消息，经会话层加密后通过 UDP 发往灯的 IPv6 地址 5540 端口。
- 灯收到后解密、校验，执行命令，把 CurrentLevel 更新为 128。
- 由于控制器已订阅该属性，灯主动上报新值 128；App 界面亮度滑块同步到约 50%（128/254）。
- 若在抓包工具中观察，可看到 WiFi 帧内是 IPv6/UDP 报文，UDP 载荷为加密的 Matter 消息，无法直接读出明文命令——这正是安全设计的体现。
理解这条路径后，排查问题就有了层次感：设备发现失败，先看 mDNS 与组播；能发现但控制失败，看 UDP 端口与客户端隔离；控制成功但状态不同步，看订阅是否建立、事件是否上报。把 Matter 的分层与 WiFi 承载关系记牢，后续的配网、调试与性能优化都会顺理成章。