BLE开发实战：如何用ATT协议实现设备间数据交互（附抓包分析）

BLE开发实战：深入ATT协议的数据交互与抓包解析

最近在调试一个智能穿戴项目时，遇到了一个棘手的问题：设备间歇性地无法上报心率数据。排查了硬件驱动和应用层逻辑，一切正常。最终，问题定位到了BLE通信的ATT协议层——一个客户端发送的读取请求，因为MTU设置不当，被服务器以“无效句柄”错误拒绝，而应用层却只收到了一个笼统的“操作失败”。这次经历让我深刻体会到，对于物联网和嵌入式开发者而言，仅仅知道BLE能通信是远远不够的。真正要构建稳定、高效的低功耗蓝牙产品，必须深入理解其通信的基石：属性协议（ATT）。它不像GATT那样定义了丰富的服务与特征，却是所有数据得以在空中准确无误传递的底层语言。本文将抛开理论堆砌，直接从实战出发，带你拆解ATT协议的数据结构，并通过真实的Wireshark抓包，一步步还原设备间数据交互的完整过程。

1. ATT协议：BLE数据交互的无声翻译官

在蓝牙低功耗的世界里，设备间的对话并非随心所欲。它们遵循一套精密的协议栈，而ATT层，正是这场对话中负责“词句组织”的关键角色。你可以把整个BLE通信想象成一次图书馆借阅：GATT层定义了图书馆的藏书分类规则（如“自然科学区”、“文学区”），以及每本书的详细信息卡（书名、作者、简介）。而ATT层，则是那位管理着所有书籍实体、负责根据索书号（句柄）准确找到并取出或放入书籍的图书管理员。没有这位管理员，即使分类再完善，你也无法实际触达任何一本书的内容。

ATT协议的核心是属性（Attribute）。这个概念非常精妙，它将设备所能提供或接收的任何一段数据，都抽象为一个统一的、可寻址的单元。每个属性包含三个基本要素：

• 句柄（Handle）：一个16位的唯一标识符，相当于书籍在图书馆书架上的绝对位置编号。客户端通过句柄来精确指定它想操作哪个数据。
• UUID（通用唯一识别码）：一个128位的标识符，用于说明这段数据的“类型”或“含义”。例如，它可能代表“温度读数”、“设备名称”或“电池电量”。为了传输效率，空中常用其16位或32位的短格式。
• 值（Value）：数据本身，以字节数组的形式存储。它可以是一个简单的整数，一个浮点数，或一段字符串。

注意：ATT协议本身并不关心“值”的具体意义。它只负责安全、可靠地传输这些字节块。赋予这些字节以实际含义（比如，0x0A代表10摄氏度），是上层GATT规范的工作。

ATT协议定义了客户端与服务器之间交互的基本“动词”，也就是操作码（Opcode）。这些操作非常直观，构成了数据交互的基石：