2. FDO协议架构：协议栈、实体角色与工作流程

聊FDO之前，我先说说自己的感受。第一次看FDO规范时，说实话有点懵——协议栈好几层，实体角色好几个，流程还分阶段。但真正动手做项目后才发现，这东西设计得其实挺巧妙。今天我就把FDO的骨架给你拆开讲清楚。

2.1 FDO协议栈：分层解耦的设计哲学

FDO协议栈分四层，从上到下分别是：应用层、传输层、安全层和物理层。我习惯把它理解成「洋葱结构」——每一层只关心自己的事，层与层之间通过标准接口通信。

下面这张图是我自己画的协议栈结构，你看一眼就能明白各层的关系：

每层的作用我简单说一下：

• 应用层：定义设备初始化、所有权转移、状态查询等业务指令。说白了就是「设备该干什么」。
• 传输层：负责消息的可靠投递。你可以选MQTT做长连接，也可以用HTTP做短连接——看场景。
• 安全层：保证通信的机密性和完整性。TLS是标配，但资源受限设备可以用DTLS或OSCORE。
• 物理层：最底层，管数据怎么在线上跑。以太网、Wi-Fi、BLE都行。

2.2 FDO实体角色：三个核心参与者

FDO定义了三个实体角色：设备（Device）、所有者（Owner）和服务商（Service Provider）。我刚开始学的时候总觉得「所有者」和「服务商」分不清，后来用一句话就记住了：设备是谁买的，谁就是所有者；设备连到谁的平台，谁就是服务商。

角色	英文	核心职责	典型代表
设备	Device	出厂时预置凭证，等待被初始化	传感器、网关、智能锁
所有者	Owner	购买设备后，执行所有权转移	企业IT部门、个人用户
服务商	Service Provider	提供设备管理平台和业务服务	阿里云IoT、AWS IoT Core

这三个角色之间的关系，我用一张流程图来展示：

2.3 FDO工作流程：三阶段搞定设备初始化

FDO的工作流程分三个阶段：TO0（所有权预登记）、TO1（所有权转移）和TO2（所有权确认）。我当年第一次看这三个阶段时，觉得名字起得真绕。后来我换了个角度理解：TO0是「打招呼」，TO1是「握手」，TO2是「签字画押」。

2.3.1 TO0阶段：设备先「报到」

设备上电后，第一件事就是找服务商报到。它会发送自己的设备凭证（比如公钥哈希），服务商验证后把设备信息登记到待转移列表里。这个阶段不涉及所有权变更，只是让服务商知道「有个设备来了」。

2.3.2 TO1阶段：所有者「认领」设备

所有者通过服务商平台发起所有权转移请求。服务商验证所有者身份后，把设备的连接信息（比如IP地址、端口）告诉所有者。然后所有者和设备直接建立安全连接，交换所有权凭证。

这个阶段我踩过坑。有一次在TO1阶段，设备返回的凭证格式不对，所有者解析失败。查了半天才发现是设备固件里把凭证的字节序搞反了。所以我的建议是：TO1阶段的凭证交换一定要做格式校验。

2.3.3 TO2阶段：最终确认

TO2是最后一个阶段。所有者和设备互相确认所有权转移完成，设备更新本地状态为「已归属」，所有者保存设备的最终凭证。至此，设备正式归所有者管理。

我把三个阶段的核心差异整理成了一张表：

阶段	参与方	核心动作	安全要求
TO0	设备 → 服务商	设备登记，发送公开凭证	无（公开信息）
TO1	所有者 ↔ 设备	凭证交换，建立信任	必须加密+签名
TO2	所有者 ↔ 设备	最终确认，状态更新	必须加密+签名

下面这张流程图把三个阶段串起来了：