3. 蓝牙协议栈与多连接模型：HCI层、L2CAP、GATT与多链路管理
3.1 分层边界与职责定义
蓝牙多连接依赖隔离设计必须从协议栈分层开始。每一层提供的抽象粒度决定了多连接管理的复杂度与隔离能力。本节给出经典蓝牙双模（BR/EDR + LE）协议栈的核心分层，并标注每层在多连接场景下的关键职责。
| 协议栈层 | 多连接场景核心职责 | 隔离边界 |
|---|---|---|
| HCI（Host Controller Interface） | Host与Controller之间的命令/事件传送；多连接时通过Connection Handle区分链路 | 硬件抽象边界，防止Host直接操作射频时序 |
| L2CAP（Logical Link Control and Adaptation Protocol） | 复用/分用多个上层通道；支持LE固定通道与BR/EDR面向连接通道 | 通道标识符（CID）隔离不同Profile的数据流 |
| GATT（Generic Attribute Profile） | 定义Server/Client模型，通过Service和Characteristic暴露数据 | ATT Bearer绑定到具体连接，实现连接级数据隔离 |
| SM（Security Manager） | 配对、绑定、加密密钥管理；多连接时需独立存储每链路的信任上下文 | 安全域隔离：不同连接使用不同LTK/IRK |
关键认知： 多连接依赖隔离的起点是保证每一层都能通过唯一的链路标识（Connection Handle / CID / ATT Bearer）正确路由数据包，任何跨连接污染都会导致协议栈崩溃或安全漏洞。
3.2 控制流与数据流在多连接下的路径
为了理解隔离风险点，需要追踪一个典型的GATT读写操作在多连接环境中的完整流经路径。
- 控制流（HCI命令 → 事件）：Host通过HCI Command发送LE Create Connection或ACL数据包；Controller返回LE Connection Complete事件（含Handle）；Host缓存该Handle与连接映射。
- 数据流（应用 → GATT → L2CAP → HCI → Controller）：应用发起GATT Read By Type Request，GATT层封装为ATT PDU，L2CAP加L2CAP头（含CID），HCI将L2CAP数据打包成ACL Data Packet（含Handle），Controller完成物理传输。
- 信任链路（加密密钥管理）：每个连接独立执行配对流程，SM层生成LTK用于加密连接。LL层（Link Layer）在LE连接建立后可通过LL_ENC_REQ开启加密。加密上下文关联Connection Handle，不共享。
3.3 选型权衡：单实例 vs 多实例分层方案
在多连接系统中，协议栈实现可以选择为每个连接分配独立的协议实例（多实例方案），或使用全局实例配合连接状态表（单实例+状态隔离方案）。两种方案的权衡如下：
| 维度 | 单实例 + 连接状态表 | 每个连接独立实例 |
|---|---|---|
| 内存占用 | 低（共享代码段，只存储连接级数据） | 高（每个实例完整的状态机与缓冲区） |
| 耦合风险 | 较高（共享锁、定时器、事件队列可能被一个连接阻塞） | 低（完全隔离，一个连接崩溃不影响其他） |
| 上下文切换开销 | 低（全局调度） | 高（实例间切换成本） |
| 实时性保障 | 需精细优先级管理，否则长包连接会拖慢短包 | 天然独立，可单独设置优先级 |
| 验收复杂度 | 需要覆盖连接间的时序干扰场景 | 每个连接独立测试，组合线性增长 |
推荐场景： IoT网关类设备（低配MCU，连接数8~32）优先采用单实例 + 状态表方案；汽车/工业多连接高可靠场景（连接数2~8，需要故障隔离）建议使用多实例方案，且实例间使用消息队列而非直接函数调用。
3.4 风险点与落地步骤
3.4.1 常见风险点
- HCI ACL数据包交叉路由：Host发送ACL Data包时未正确设置Connection Handle，导致数据发错连接。需在HCI驱动层增加Handle有效性校验。
- L2CAP CID冲突：不同连接分配了重复的本地CID（通常不会，但动态CID分配需全局唯一）。
- GATT操作未绑定Bearer：GATT Server在处理Read/Write时，若丢失ATT Bearer（即所属连接），可能将数据应答到错误的连接。
- 加密上下文混淆：加密变化事件（Encryption Change）未正确关联到对应的Connection Handle，导致某个连接被意外解密。
3.4.2 落地步骤
- 定义连接标识结构：建立全局连接表（conn_table），每个条目包含Connection Handle、Peer MAC、L2CAP CID池、ATT Bearer指针、加密状态。
- HCI事件路由改造：在HCI事件处理入口，根据事件Parameter中的Connection Handle索引到连接表，分发到对应连接的协议实例或回调。
- L2CAP复用层实现：封装L2CAP Send函数，参数必须包含连接ID，内部根据ID匹配到L2CAP通道实例，若CID已占用则返回错误。
- GATT Bearer绑定：在GATT API初始化时，为每个连接创建独立的ATT Bearer（包括MTU、Pending请求队列）。
- 安全上下文隔离：每个连接执行SM配对时，将生成的LTK/IRK等写入连接表对应的安全字段；加密后不可被其他连接访问。
- 集成测试与压力测试：编写多连接并发读写脚本，每个连接独立执行读、写、通知，验证数据不交叉、不丢失、不同步。
3.5 验收标准
多连接协议栈验收项（至少覆盖以下）：
| 验收项 | 方法 | 通过准则 |
|---|---|---|
| HCI Handle唯一性 | 抓取HCI日志，检查所有ACL Data Packet及事件的Handle值在连接生命周期内不重复 | 100%连接Handle全局唯一 |
| L2CAP通道隔离 | 连接A和B同时建立L2CAP LEPSM 0x0080，互发数据，检查数据是否串线 | 无数据交叉 |
| GATT响应归属 | 连接A发出Read By Type，连接B同时发出Write，验证Response仅发回请求方 | 响应100%匹配请求连接 |
| 加密状态独立 | 连接A配对并加密，连接B未配对；验证连接A数据传输密文，连接B明文 | 加密状态不混淆 |
| 断开不影响其他 | 同时维持3个连接，主动断开其中1个，另2个的GATT操作正常完成 | 无异常掉线或数据错乱 |
警惕陷阱： 协议栈供应商（如TI、Nordic、Realtek）通常提供多连接示例，但大多只测试固定数量连接（如2~4个）。量产时请务必使用测试设备数量接近上限（如8连接），并执行长时间稳定性测试（≥72小时），否则容易出现HCI事件队列溢出或GATT通知竞争导致系统复位。