为什么 iOS MTU=517，但 BLE 吞吐量通常只有 6~8KB/s？
在做 BLE 高速数据传输（例如 OTA、日志传输、大数据同步）时，很多开发者都会发现一个现象：
iOS 与设备协商MTU = 517
理论上 ATT payload 可以达到514 bytes
但实际测试吞吐量时却只有：
6 KB/s ~ 8 KB/s
这个结果往往让人困惑：
MTU 已经这么大了，为什么速度还是这么慢？
要理解这个问题，需要从 BLE 的三个关键因素来看：
MTU（ATT 层）
Link Layer Packet Size（空口包大小）
Connection Interval 与 Connection Event
一、BLE 数据从 App 到空口的路径
BLE 数据从应用层发送到无线空口，会经过多个协议层：
App
↓
CoreBluetooth
↓
ATT
↓
L2CAP
↓
Link Layer
↓
Air
MTU 只影响：
ATT 层
但吞吐量真正取决于 Link Layer 和连接参数。
二、MTU=517 的真实含义
BLE 中的 MTU 指的是ATT PDU 最大长度。
例如 iOS 连接 BLE 设备时常见：
Exchange MTU Request: 527
Exchange MTU Response: 517
最终：
ATT MTU = 517
ATT Write PDU 结构：
Opcode (1 byte)
Handle (2 bytes)
Value (N bytes)
因此最大 payload：
517 - 3 = 514 bytes
也就是说：
ATT 层一次最多可以写 514 bytes
但这并不意味着空口包也是 517 bytes。
三、ATT 数据会封装到 L2CAP
ATT 数据会被封装到 L2CAP：
Length (2)
CID (2)
Payload (ATT)
因此：
ATT 517
→ L2CAP 521
四、真正发到空口的是 Link Layer Packet
BLE 无线包结构：
Preamble
Access Address
LL Header
LL Payload
CRC
关键限制是：
LL Payload
五、BLE 有两个时代
BLE 4.0 / 4.1
最大：
LL payload = 27 bytes
如果 ATT payload = 514：
514 / 27 ≈ 20 packets
吞吐量非常低。
BLE 4.2 以后（Data Length Extension）
BLE 4.2 引入Data Length Extension (DLE)。
最大：
LL payload = 251 bytes
因此：
ATT 517
→ L2CAP 521
→ 分片
可能变为：
251 + 251 + 19
六、Data Length Extension 协商
连接建立后，BLE 设备还会协商数据长度：
LL_LENGTH_REQ
LL_LENGTH_RSP
协商内容：
MaxTxOctets
MaxRxOctets
MaxTxTime
MaxRxTime
如果双方都支持：
MaxTxOctets = 251
否则：
MaxTxOctets = 27
七、真正限制吞吐量的是 Connection Event
BLE 数据发送不是连续的，而是在connection event中发送。
连接参数通常类似：
Connection Interval = 30 ms
也就是说：
每 30ms 才能发送一次数据
八、每个 Connection Event 能发多少包？
iOS 控制器通常允许：
4 ~ 6 packets / event
假设：
6 packets
每个 packet payload：
≈ 247 bytes
（251 - L2CAP header）
九、吞吐量计算
假设：
247 bytes × 6 packets = 1482 bytes
Connection interval：
30 ms
吞吐量：
1482 / 0.03
≈ 49 KB/s
这是理论最大值。
十、为什么实际只有 6~8 KB/s？
因为实际情况通常更差。
常见情况：
Connection Interval = 30 ms
Packets per event = 2
Payload ≈ 200 bytes
则：
200 × 2 = 400 bytes
吞吐：
400 / 0.03
≈ 13 KB/s
再考虑：
ACK
CPU调度
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 = 251
3 使用 WriteWithoutResponse
避免等待 ACK。
4 合理分包
每包大小：
maximumWriteValueLengthForType
十四、总结
很多开发者误以为：
MTU = 吞吐量
其实 BLE 吞吐量取决于多个因素：
| 因素 | 影响 |
|---|---|
| ATT MTU | 单次写入大小 |
| Data Length | 空口包大小 |
| Connection Interval | 发送频率 |
| Packets per event | 每次可发包数 |
因此即使：
MTU = 517
实际吞吐量仍可能只有：
6~8 KB/s
如果你在做BLE OTA 或高速数据传输，理解这些机制非常重要，否则很容易误判问题。
例如：
误以为 MTU 不够大
误以为设备性能不足
实际是连接参数限制