BLE中心与外围设备MTU协商过程详解
一、MTU基础概念
1. MTU定义
最大传输单元（MTU） 指单次数据传输中允许的最大字节数，包含协议头部（3字节）和有效载荷（最多517字节）。BLE默认MTU为23字节（有效载荷20字节），但可通过协商提升至设备支持的最大值（如512字节）。
2. 协商目的
- 效率优化：增大MTU可减少分包次数，提升传输速率（例如MTU=244时理论速度可达63KB/s，而默认仅5KB/s）。
- 保障兼容性：设备能力差异（如旧手机仅支持23字节，新设备支持128+字节）需通过协商确定共同支持的MTU。
二、MTU协商流程
步骤1：连接建立
- BLE设备（中心设备/Central）与外围设备（Peripheral）建立连接后，默认采用23字节MTU。
步骤2：发起MTU请求
- 发起方：通常由中心设备（如手机APP）通过L2CAP层发送 ATT_MTU_Request 命令，包含期望的MTU值（如185字节）。
- 请求格式：
Opcode: Exchange MTU Request (0x02) Client Rx MTU: [请求值] # 例如185
步骤3：设备响应
- 外围设备收到请求后，回复 ATT_MTU_Response ：
- 若支持请求值，返回相同或更大的MTU；
- 若不支持，返回自身支持的最大值（如23字节）。
- 响应格式：
Opcode: Exchange MTU Response (0x03) Server Rx MTU: [响应值] # 例如23
步骤4：协商结果生效
- 最终MTU：取请求值（
Client Rx MTU）与响应值（Server Rx MTU）中的较小值作为新MTU。示例：手机请求185字节，设备响应23字节 → 最终MTU=23字节。
步骤5：数据传输优化
- 应用层根据协商后的MTU调整数据包大小，避免分包传输。
三、关键影响因素
1. 设备能力限制
- 旧款手机/老芯片（如蓝牙4.2）默认支持23字节，2020年后设备普遍支持≥128字节。
- iOS设备通常支持185字节，安卓可支持247字节（需协议栈支持）。
2. 协议栈实现差异
- 自动协商：iOS/Android系统层可能自动触发MTU请求（如iOS的
peripheral:didUpdateValueForCharacteristic:回调）。 - 手动触发：开发者可通过API（如Android的
requestMtu()）主动请求。
3. 传输参数联动
MTU需与连接间隔（Connection Interval）协同优化：
- 短间隔（如7.5ms） + 大MTU → 高吞吐量；
- 长间隔（如100ms） + 小MTU → 低功耗。
四、注意事项
1. 兼容性处理
- 在APP端检测设备蓝牙版本（4.2以下需保持默认MTU）。
- 协商失败时降级至23字节，避免连接中断。
2. 性能权衡
过大的MTU可能因数据包重传增加延迟，建议根据场景平衡：
- 实时控制（如键盘鼠标）：小MTU（23-64字节）；
- 固件升级：大MTU（128-247字节）。
3. 调试工具
- 使用BLE嗅探器（BLE Sniffer）抓包分析
ATT_MTU_Request/Response字段。
五、MTU协商与传输效率关系
| MTU大小 | 有效载荷 | 理论速率（15ms间隔） |
|---|---|---|
| 23字节 | 20字节 | ≈5 KB/s |
| 128字节 | 125字节 | ≈33 KB/s |
| 247字节 | 244字节 | ≈65 KB/s |
注：速率计算假设每连接事件传输4个数据包。
总结：MTU协商是BLE连接后动态优化传输效率的核心机制，需结合设备能力、协议栈特性及应用场景综合设计。实际开发中，建议优先通过系统API自动协商，并在关键业务（如OTA升级）前手动请求最大支持值以提升性能。