4. BRSKI协议流程
好，我们进入第四章。这一章是整个 BRSKI 协议的核心骨架。说白了，就是一台全新的设备从拆箱到被网络信任，到底经历了什么。
我个人习惯把 BRSKI 的流程拆成三个维度来看：宏观流程（整体长什么样）、微观交互（六步握手具体怎么谈）、内部状态（设备自己怎么记进度）。再加上一个兜底的超时重试，这四个部分吃透了，BRSKI 的运行时你就掌握了。
4.1 整体流程概览：一次安全的“自我介绍”
想象一下，你买了一台新的交换机，插上网线，它连 IP 都没有。它要怎么让网络知道“我是谁，我来自哪个厂商，我想加入网络”？
BRSKI 的整体流程，就是解决这个问题的。它不是一个单次请求，而是一个多阶段、带证书验证的委托注册过程。
核心思想： 设备（Pledge）通过一个叫“代客注册”（Voucher）的机制，让网络中的“代理人”（Registrar）帮它向“所有者”（MASA）要一张“入场券”。这张入场券就是 Voucher，它证明了设备被授权加入网络。
整个流程可以概括为四个阶段：
- 发现与连接： 设备通过 DHCP 或 mDNS 找到网络中的 Registrar。
- 身份证明： 设备出示它的 IDevID 证书（出厂时烧录的），证明自己是合法硬件。
- 委托请求： Registrar 代表设备向 MASA 请求一个 Voucher。
- 安全上线： 设备验证 Voucher 后，接受 Registrar 下发的本地证书（LDevID），正式成为网络成员。
嗯，这里要注意，MASA 是厂商的云服务，它不直接跟设备通信，而是跟 Registrar 通信。这个设计很巧妙，避免了设备直接暴露在公网。
4.2 六步握手协议：EST 信封里的秘密
BRSKI 的交互，本质上是基于 EST（Enrollment over Secure Transport） 协议的扩展。它把整个注册过程封装在 TLS 会话里，保证了通信的机密性和完整性。
我把它拆成六步，你对照着抓包看会非常清晰：
| 步骤 | 方向 | 消息类型 | 核心内容 |
|---|---|---|---|
| 1 | Pledge → Registrar | Discovery | “谁是 Registrar？我在这！” |
| 2 | Registrar → Pledge | Voucher Request | “把你的 IDevID 和 nonce 给我，我去找 MASA 要 Voucher。” |
| 3 | Registrar → MASA | Voucher Request (代理) | “MASA，这台设备（IDevID）想加入我的网络，请签发 Voucher。” |
| 4 | MASA → Registrar | Voucher | “Voucher 给你，里面包含了设备公钥和授权信息，我签名了。” |
| 5 | Registrar → Pledge | Voucher + CA 证书 | “这是你的 Voucher，还有我们网络的 CA 证书，你可以验证了。” |
| 6 | Pledge → Registrar | Enroll (CSR) | “Voucher 验证通过，这是我的 CSR，请给我签发本地证书。” |
我的经验： 我曾经在调试一个跨厂商互通问题时，卡在步骤 2 和步骤 5 之间。Registrar 返回的 Voucher 格式不对，设备解析失败。后来发现是 MASA 返回的 Voucher 里，assertion 字段的值写错了。记住，Voucher 是一个 CMS 签名结构，任何字段不匹配都会导致握手失败。
这六步，其实可以浓缩成三个关键交互：
- Pledge ↔ Registrar： 发现、请求 Voucher、最终注册。
- Registrar ↔ MASA： 代理请求 Voucher。
- Pledge 内部： 验证 Voucher 签名和 nonce。
4.3 协议状态机：设备的大脑
设备不会傻等。它内部有一个清晰的状态机，管理着整个流程的推进。我习惯用三个核心状态来理解它：
- INIT (初始状态)： 设备刚启动，没有网络连接，没有 IP。它在等待触发条件（比如插上网线）。
- CONNECTING (连接中)： 设备获得了 IP，正在尝试发现 Registrar 并建立 TLS 连接。
- ENROLLING (注册中)： TLS 连接建立，正在进行六步握手。这个状态内部又细分了几个子状态，比如
WAIT_VOUCHER、WAIT_CA、WAIT_CERT。 - ENROLLED (已注册)： 成功获取 LDevID，设备可以正常工作了。
- ERROR (错误)： 任何步骤超时或验证失败，都会进入这个状态。设备会尝试重试或回退。
你想想看，如果没有状态机，设备在收到一个错误的 Voucher 后，可能会一直卡在某个步骤，或者无限重试。状态机定义了清晰的边界和转换条件。
避坑指南： 我曾经遇到一个案例，设备在 WAIT_VOUCHER 状态停留了很长时间，最后超时了。排查发现，Registrar 向 MASA 请求 Voucher 时，网络防火墙拦截了 HTTPS 流量。设备的状态机没有及时检测到底层连接断开，导致它一直傻等。所以，状态机设计时，一定要考虑底层传输层的异常通知。
下面这张图，是我根据 RFC 8995 整理的一个简化状态机，你可以对照着理解：
4.4 超时与重试机制：网络不总是可靠的
网络环境千差万别。设备可能遇到 Registrar 没启动、MASA 响应慢、或者中间丢包。所以，BRSKI 必须有一套健壮的超时和重试策略。
我个人习惯把超时分为三个层级：
- 连接超时： 建立 TCP/TLS 连接时，如果 5 秒内没有收到 SYN-ACK 或 ServerHello，设备会认为 Registrar 不可达。
- 请求超时： 发送 Voucher Request 或 CSR 后，等待响应。默认通常是 10 秒。如果超时，设备会重发请求。
- 整体流程超时： 整个注册过程（从 INIT 到 ENROLLED）不能无限等待。我见过的实现里，通常会设置一个 5 分钟的总超时。超时后，设备会进入 ERROR 状态，并尝试重新开始。
重试策略： 不是简单的“失败了就重试”。BRSKI 推荐使用 指数退避（Exponential Backoff）。第一次重试等待 1 秒，第二次 2 秒，第三次 4 秒，以此类推，直到最大间隔（比如 64 秒）。这样可以避免网络风暴。
举个例子，设备在发送 Voucher Request 后，如果 10 秒内没收到响应，它会：
- 记录一次失败。
- 等待 1 秒，重发请求。
- 如果又超时，等待 2 秒，再重发。
- 如果连续失败 5 次，进入 ERROR 状态，并通知管理员。
我的建议： 在实现或调试时，一定要把超时时间打印到日志里。我曾经遇到一个情况，设备总是重试 3 次后失败，但网络其实没问题。后来发现是 Registrar 的处理时间刚好比超时时间多了 0.5 秒。把超时从 10 秒调整到 15 秒后，问题就解决了。有时候，问题不在协议本身，而在参数配置。
嗯，关于超时，还有一个容易被忽略的点：MASA 的响应时间。MASA 是云服务，它可能需要查询数据库、验证签名，响应时间可能从几百毫秒到几秒不等。如果 Registrar 给 MASA 的超时设置得太短，会导致频繁的重试，甚至误判 MASA 不可用。
好了，这一章的内容就到这里。整体流程、六步握手、状态机、超时重试，这四个部分构成了 BRSKI 协议运行的完整画面。你把这些逻辑理清了，后面看具体的报文细节就会轻松很多。