为什么 iOS MTU=517,但 BLE 吞吐量通常只有 6~8KB/s?
在做 BLE 高速数据传输例如 OTA、日志传输、大数据同步时很多开发者都会发现一个现象iOS 与设备协商MTU 517理论上 ATT payload 可以达到514 bytes但实际测试吞吐量时却只有6 KB/s ~ 8 KB/s这个结果往往让人困惑MTU 已经这么大了为什么速度还是这么慢要理解这个问题需要从 BLE 的三个关键因素来看MTUATT 层Link Layer Packet Size空口包大小Connection Interval 与 Connection Event一、BLE 数据从 App 到空口的路径BLE 数据从应用层发送到无线空口会经过多个协议层App↓CoreBluetooth↓ATT↓L2CAP↓Link Layer↓AirMTU 只影响ATT 层但吞吐量真正取决于 Link Layer 和连接参数。二、MTU517 的真实含义BLE 中的 MTU 指的是ATT PDU 最大长度。例如 iOS 连接 BLE 设备时常见Exchange MTU Request: 527Exchange MTU Response: 517最终ATT MTU 517ATT Write PDU 结构Opcode (1 byte)Handle (2 bytes)Value (N bytes)因此最大 payload517 - 3 514 bytes也就是说ATT 层一次最多可以写 514 bytes但这并不意味着空口包也是 517 bytes。三、ATT 数据会封装到 L2CAPATT 数据会被封装到 L2CAPLength (2)CID (2)Payload (ATT)因此ATT 517→ L2CAP 521四、真正发到空口的是 Link Layer PacketBLE 无线包结构PreambleAccess AddressLL HeaderLL PayloadCRC关键限制是LL Payload五、BLE 有两个时代BLE 4.0 / 4.1最大LL payload 27 bytes如果 ATT payload 514514 / 27 ≈ 20 packets吞吐量非常低。BLE 4.2 以后Data Length ExtensionBLE 4.2 引入Data Length Extension (DLE)。最大LL payload 251 bytes因此ATT 517→ L2CAP 521→ 分片可能变为251 251 19六、Data Length Extension 协商连接建立后BLE 设备还会协商数据长度LL_LENGTH_REQLL_LENGTH_RSP协商内容MaxTxOctetsMaxRxOctetsMaxTxTimeMaxRxTime如果双方都支持MaxTxOctets 251否则MaxTxOctets 27七、真正限制吞吐量的是 Connection EventBLE 数据发送不是连续的而是在connection event中发送。连接参数通常类似Connection Interval 30 ms也就是说每 30ms 才能发送一次数据八、每个 Connection Event 能发多少包iOS 控制器通常允许4 ~ 6 packets / event假设6 packets每个 packet payload≈ 247 bytes251 - L2CAP header九、吞吐量计算假设247 bytes × 6 packets 1482 bytesConnection interval30 ms吞吐量1482 / 0.03≈ 49 KB/s这是理论最大值。十、为什么实际只有 6~8 KB/s因为实际情况通常更差。常见情况Connection Interval 30 msPackets per event 2Payload ≈ 200 bytes则200 × 2 400 bytes吞吐400 / 0.03≈ 13 KB/s再考虑ACKCPU调度iOS发送节流最终6 ~ 8 KB/s十一、iOS 发送节流Flow Control在 iOS 中如果使用WriteWithoutResponse系统内部有发送队列限制。需要监听peripheralIsReadyToSendWriteWithoutResponse否则会出现发送暂停这也是吞吐下降的重要原因。十二、BLE 吞吐量的核心公式BLE 吞吐量近似为throughput ≈(payload_per_packet × packets_per_event)/ connection_interval十三、提高 BLE 吞吐量的方法如果需要更高速度可以优化1 减小 Connection Interval例如30 ms → 7.5 ms吞吐会提升约4 倍。2 启用 Data Length Extension确保LL payload 2513 使用 WriteWithoutResponse避免等待 ACK。4 合理分包每包大小maximumWriteValueLengthForType十四、总结很多开发者误以为MTU 吞吐量其实 BLE 吞吐量取决于多个因素因素影响ATT MTU单次写入大小Data Length空口包大小Connection Interval发送频率Packets per event每次可发包数因此即使MTU 517实际吞吐量仍可能只有6~8 KB/s如果你在做BLE OTA 或高速数据传输理解这些机制非常重要否则很容易误判问题。例如误以为 MTU 不够大误以为设备性能不足实际是连接参数限制
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2408687.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!