硬件环境

主控测：RK3568
被控测 ：HI3863
coap报文见附件。

一、交互总览

从 Wireshark 抓包可见，192.168.43.3（客户端） 与 192.168.43.1（服务端） 之间存在三类核心交互：

• SPEKE 密钥协商流程：基于 CoAP 协议完成身份认证与密钥交换
• e2eCtrl 端到端控制流程：协商完成后执行设备控制指令
• e2eDataChange 数据变更通知流程：服务端向客户端推送状态变更

二、SPEKE 密钥协商流程

1. 协商时序表

包序号	时间戳	源 IP	目标 IP	协议	报文类型	关键信息
27	0.703054	192.168.43.3	192.168.43.1	CoAP	CON (Confirmable)	POST /SPEKE，JSON，TKN: b2 82 17 73 7b ca 68 56
35	1.419753	192.168.43.1	192.168.43.3	CoAP	ACK	2.05 Content，MID:12911，同 Token
40	1.882282	192.168.43.3	192.168.43.1	CoAP	CON	POST /SPEKE，JSON，TKN: 9e 19 33 6a e1 51 72 c9
45	2.473499	192.168.43.1	192.168.43.3	CoAP	ACK	2.05 Content，MID:9234，同 Token

2. 流程说明

1. 第一轮协商（CON → ACK）
   • 客户端向服务端发送 Confirmable (CON) 类型 POST 请求，路径 /SPEKE，携带 SPEKE 协议第一步协商参数（Token 用于标识会话）。
   • 服务端回复 ACK 2.05 Content，确认收到并返回协商响应数据，完成第一轮密钥交换。
2. 第二轮协商（CON → ACK）
   • 客户端发送第二轮 CON POST 请求，使用新 Token，完成 SPEKE 后续协商步骤。
   • 服务端再次回复 ACK 2.05 Content，确认协商完成。
3. 协议特性
   • 使用 CON 报文 保证可靠性，必须等待对端 ACK 确认。
   • 响应码 2.05 Content 表示请求成功处理并返回数据。
   • Token（8字节） 用于匹配请求与响应，确保会话唯一性与隔离性。

三、e2eCtrl 端到端控制流程

1. 控制时序表

包序号	时间戳	源 IP	目标 IP	协议	报文类型	关键信息
85	5.410056	192.168.43.3	192.168.43.1	CoAP	CON	POST /e2eCtrl，JSON，TKN: 74 3e 59 95 d5 be 27 69
86	5.415060	192.168.43.3	192.168.43.1	CoAP	CON	POST /e2eCtrl，JSON，TKN: 1c 62 ab b1 0b de d8 af
96	5.823732	192.168.43.1	192.168.43.3	CoAP	ACK	2.05 Content，MID:31527，同 Token
97	6.232154	192.168.43.1	192.168.43.3	CoAP	ACK	2.05 Content，MID:3923，同 Token
102	6.951051	192.168.43.3	192.168.43.1	CoAP	CON	POST /e2eCtrl，JSON，TKN: 86 e9 31 63 8b 15 2d 76

2. 流程说明

1. 控制请求发送
   • 客户端向服务端发送 CON POST 请求，路径 /e2eCtrl，携带 JSON 格式的端到端控制指令。
   • 可同时发送多个控制请求，通过不同 Token 区分不同控制会话。
2. 服务端确认响应
   • 服务端返回 ACK 2.05 Content，确认控制指令已接收并处理。
   • 响应 MID 与请求 MID 严格匹配，Token 保持一致，保证请求-响应一一对应。
3. 持续控制
   • 客户端可继续发送新的 CON 请求，执行持续设备控制操作。

四、e2eDataChange 数据变更通知流程

1. 数据变更时序表

包序号	时间戳	源 IP	目标 IP	协议	报文类型	关键信息
98	6.271830	192.168.43.1	192.168.43.3	CoAP	NON (Non-Confirmable)	POST /e2eDataChange，text/plain，TKN: cc ca 01 10 01 16 a0 ba
99	6.276106	192.168.43.1	192.168.43.3	CoAP	NON	POST /e2eDataChange，text/plain，同 Token
100	6.640454	192.168.43.1	192.168.43.3	CoAP	NON	POST /e2eDataChange，text/plain，TKN: a6 7e e0 22 6d 2b a6 46
101	6.645024	192.168.43.1	192.168.43.3	CoAP	NON	POST /e2eDataChange，text/plain，同 Token

2. 流程说明

1. 数据变更推送
   • 服务端向客户端发送 Non-Confirmable (NON) 类型 POST 请求，路径 /e2eDataChange。
   • 报文格式为 text/plain，携带设备状态变更或数据更新内容。
   • 使用 NON 类型，无需客户端 ACK 确认，适合轻量、高频的状态通知场景。
2. 可靠性增强
   • 同一 Token 重复发送，用于弥补 NON 报文无确认机制的可靠性缺陷，提升通知到达率。
   • 不同 Token 对应不同数据变更事件，实现多事件并行通知。

五、协议与技术总结

1. 核心协议栈

层级	协议	说明
传输层	UDP	CoAP 基于 UDP 实现，轻量化、低开销
应用层	CoAP	约束应用协议，适配 IoT 设备
业务层	SPEKE	安全密码认证密钥交换协议
业务层	e2eCtrl/e2eDataChange	端到端控制与数据通知接口

2. CoAP 报文类型选型

业务场景	报文类型	选型原因
SPEKE 协商	CON + ACK	密钥协商需高可靠性，必须确认
e2eCtrl 控制	CON + ACK	控制指令不可丢失，需可靠传输
e2eDataChange 通知	NON	轻量通知，允许少量丢失，降低开销

3. 接口与会话设计

• 资源路径：
  • /SPEKE：密钥协商接口
  • /e2eCtrl：端到端控制接口
  • /e2eDataChange：数据变更通知接口
• 会话标识：8字节 Token，用于唯一标识请求-响应对，实现多会话并行与隔离。

六、Wireshark 过滤规则

1. 全业务过滤

ip.addr == 192.168.43.1 and ip.addr == 192.168.43.3 and coap

2.仅 SPEKE 协商：

ip.addr == 192.168.43.1 and ip.addr == 192.168.43.3 and coap and (coap.uri.path == "SPEKE")

3.仅 e2eCtrl 控制：

ip.addr == 192.168.43.1 and ip.addr == 192.168.43.3 and coap and (coap.uri.path == "e2eCtrl")

4.仅 e2eDataChange 通知：

ip.addr == 192.168.43.1 and ip.addr == 192.168.43.3 and coap and (coap.uri.path == "e2eDataChange")

七、业务流程总结

1. 密钥协商阶段：客户端与服务端通过两轮 CON-ACK 完成 SPEKE 身份认证与密钥交换，建立安全通信通道。
2. 设备控制阶段：协商完成后，客户端通过 CON 报文向服务端发送控制指令，服务端 ACK 确认执行。
3. 状态同步阶段：服务端通过 NON 报文向客户端推送设备状态变更，实现端到端状态同步。