2、算法协商基础概念：什么是算法协商、为什么需要协商、协商的层次模型

好，咱们正式开始聊算法协商。说实话，这个概念在 IoT 领域里经常被误解。有人觉得它就是「两个设备握手时选个加密算法」，也有人觉得它跟协议协商是一回事。其实都不完全对。

我个人的理解是：算法协商，是异构设备在通信建立阶段，通过一套预定义的规则，共同确定后续通信所使用的算法集合的过程。说白了，就是让两个「语言不通」的设备，先商量好接下来用什么「方言」聊天。

2.1 什么是算法协商

咱们先拆开看。「算法」在这里不单指加密算法，它涵盖了三类：

• 加密算法：AES、SM4、ChaCha20 等
• 认证算法：HMAC、CMAC、Poly1305 等
• 压缩/编码算法：LZ4、Zstandard、CBOR 等

「协商」也不是简单的「你选一个，我同意」。它是一套完整的交互流程：

1. 能力声明：双方各自列出自己支持的算法列表
2. 交集计算：找到双方都支持的算法集合
3. 策略选择：根据优先级、安全等级、性能需求，从交集中选出最终使用的算法
4. 确认生效：双方确认选定的算法，开始正式通信

我记得在做一个智能家居网关项目时，遇到过一个问题：Zigbee 节点和 Wi-Fi 网关之间要建立安全通道。Zigbee 那边只支持 AES-CCM，而网关这边默认配置的是 AES-GCM。如果没有协商机制，两边根本对不上。后来我们加了一层轻量级的算法协商，才把这个问题解决掉。

2.2 为什么需要协商

你可能会问：为什么不直接定死一套算法？大家都用 AES-256-GCM 不就完了？

嗯，理想很丰满，现实很骨感。我给你列几个真实场景：

场景	问题	不协商的后果
传感器节点（MCU）	算力有限，跑不动 AES-256	要么拒绝连接，要么死机
边缘网关	需要同时对接 5 种不同厂商的设备	每种设备写一套硬编码，维护成本爆炸
固件升级后	新设备支持了更快的 ChaCha20	旧设备无法利用新算法优势
跨国部署	某些国家要求使用国密 SM 系列	无法满足合规要求

说白了，算法协商解决的是「多样性」和「演进性」两个核心矛盾。

我曾经踩过一个坑：一个工业 IoT 项目，所有设备出厂时硬编码了 AES-128-CBC。结果两年后，客户要求升级到 AES-256-GCM 以通过安全审计。我们不得不给上千台设备做 OTA 升级，还要保证升级期间老设备能正常工作。如果当初设计了协商机制，只需要在协商阶段增加对新算法的支持，老设备自然降级使用旧算法，根本不用这么折腾。

2.3 协商的层次模型

算法协商不是孤立的，它发生在 IoT 通信协议栈的不同层次。我习惯把它分成三个层次来看：

2.3.1 传输层协商

这一层最典型的就是 TLS 握手。客户端和服务端通过 ClientHello / ServerHello 交换支持的密码套件（Cipher Suite），然后协商出共同使用的加密、认证和密钥交换算法。

特点：

• 协商发生在连接建立阶段
• 通常由底层协议栈自动完成
• 对上层应用透明

但问题在于：传输层协商只解决了「通道安全」，不解决「数据语义」。比如两个设备虽然用 TLS 建立了安全连接，但传输的数据是 CBOR 还是 JSON？压缩不压缩？这些传输层管不了。

2.3.2 应用层协商

这一层才是异构 IoT 网络中最关键的部分。应用层协商负责确定：

• 数据序列化格式（Protobuf / CBOR / MessagePack）
• 压缩算法（LZ4 / Zstd / 不压缩）
• 应用层加密（端到端加密 vs 传输层加密）
• 数据分片和重组策略

我建议在设计应用层协商时，一定要把「能力描述」和「策略选择」分开。能力描述是客观的「我支持什么」，策略选择是主观的「在当前场景下我用什么」。这两者混在一起，后期扩展会非常痛苦。

2.3.3 跨层协商

这是最容易被忽视的一层。跨层协商指的是：传输层和应用层的算法选择会相互影响。

举个例子：

• 如果传输层选择了 AES-256-GCM，应用层就不需要再做加密，否则性能浪费
• 如果传输层使用了 TCP（有重传机制），应用层的压缩算法可以更激进
• 如果传输层是 UDP（可能丢包），应用层需要选择支持流式解压的算法

下面这张图展示了三层协商模型的关系：

你看，这三层不是孤立的。传输层协商搞定了，应用层还得再谈一次。跨层协商更像是一个「优化层」，告诉你哪些组合是合理的，哪些是浪费的。

2.4 小结

这一章我们聊了三个核心问题：

• 算法协商是什么：能力声明 → 交集计算 → 策略选择 → 确认生效
• 为什么需要协商：解决设备多样性、协议演进、合规要求
• 协商的层次模型：传输层、应用层、跨层，各有各的职责和挑战