项目篇：ble透传速率抓包分析

文章目录

        1 未扩展数据包

        2 扩展数据包

        3 写有回应

        4 写无回应

1 未扩展数据包

可以看到ble4.0时，LL_PDU支持33字节长度的数据，前2个字节为帧头，后4个字节用于MIC，就算不加密，LL能容忍来自L2CAP长度也只有27字节。

抓包结果：

假设用户想通过BLE发送1KB数据，将连接间隔7.5ms，每个连接事件执行两次Tx，理论上需花费(1024/54)*7.5=142.5ms，这还不算上重传等因素，因此非常耗时。

2 扩展数据包

在ble4.2之后引入新的特性，即LE data length extension（数据包扩展），LL最大容纳来自L2CAP的251（257-2-4）字节的数据。

 抓包结果： 

 假设用户想通过BLE发送1KB数据，将连接间隔依然7.5ms，每个连接事件执行1次Tx（MaxTxTime=2120us），由于MTU限制，L2CAP最大支持509字节数据，因此应用层分包，执行过程251+251+14，执行两次，理论上需花费6*7.5=45ms，因此花费时间大大提升了。

3 写有回应

抓包结果：

 若用户每次发送一条命令给从设备需得到对方回应，那必须采用带回应的方式。若只是数据透传需求，能免则面吧，此外若主从设备都在互发数据，采用此方式发包严重影响速率甚至丢包。

 4 写无回应

 抓包结果：

试想一下，对比write和write_no_response。

write：data_packet(主)->empty packet（从）-> empty packet(主)->data_packet（从）

write_no_response：data_packet(主)->empty packet（从）

哪个更省时呢？

若只是数据透传需求，无需在应用层得到回复，直接采用写无回应方式，每次来SRAM中有数据发完即可。若主从设备互相灌包压测速率，建议采用write_no_response和notify方式。

欢迎指导！！！