2、蓝牙协议栈架构：Host与Controller分层、HCI接口、L2CAP、RFCOMM、SDP基础
好，咱们正式开始聊蓝牙协议栈。很多初学者一上来就被那一堆分层给吓住了，觉得特别复杂。其实你把它拆开看，说白了就是一套“分工协作”的体系。我做了这么多年车载蓝牙，最深的体会就是：搞懂分层，你就掌握了蓝牙的骨架。
2.1 Host与Controller：一个在明，一个在暗
蓝牙协议栈最核心的分层，就是Host和Controller。你可以这么理解：
- Controller：负责“干活”的。它处理射频、基带、链路管理等底层操作。它离硬件最近，像个埋头苦干的工人。
- Host：负责“发号施令”的。它处理逻辑链路、协议、应用层。它离用户最近，像个项目经理。
为什么这么分？我个人的理解是，为了解耦。你想想看，手机厂商想换一个蓝牙芯片，如果协议栈是揉在一起的，那整个软件都得重写。但有了分层，只要Controller的接口不变，Host层代码几乎不用动。我在项目中遇到过好几次芯片换型号，只要HCI接口兼容，上层应用基本无感。
关键点：Host和Controller之间通过HCI（Host Controller Interface）通信。这是蓝牙协议栈的“命门”。
2.2 HCI接口：协议栈的“高速公路”
HCI，全称Host Controller Interface。它定义了Host和Controller之间怎么说话。说白了，就是一套命令、事件、数据的传输规范。
HCI的传输方式有好几种：UART、USB、SDIO等。在车载蓝牙里，最常见的是UART。为什么？因为成本低、实现简单。我曾经调试过一个项目，HCI的UART波特率没配好，导致音频数据断断续续，查了两天才找到原因。嗯，这里要注意，HCI的物理层配置一定要和芯片手册对得上。
HCI的数据包格式很简单，就三种：
- 命令包：Host发给Controller，让它干点啥。比如“开始扫描”、“建立连接”。
- 事件包：Controller回复给Host，告诉它结果。比如“扫描完成”、“连接已断开”。
- 数据包：Host和Controller之间传的实际数据。比如音频流、文件。
我习惯在调试时，用逻辑分析仪抓HCI的UART数据。看到命令包发出去，事件包正确返回，心里就踏实了。如果事件包没回来，那八成是Controller那边出了问题。
小技巧：调试HCI时，可以先用厂商提供的HCI测试工具（比如TI的BTool、CSR的BlueTest）发几个简单命令，确认Controller能正常响应。这能帮你快速定位问题是出在Host还是Controller。
2.3 L2CAP：数据的分包与重组
L2CAP，全称Logical Link Control and Adaptation Protocol。名字挺长，但功能很单纯：把上层的大数据包，切成适合底层传输的小包；再把底层收来的小包，拼回完整的大包。
为什么会这样？因为蓝牙底层的基带包大小有限（比如经典蓝牙的ACL包最大也就几百字节）。你上层要传一个1MB的文件，不可能一次性塞进去。L2CAP就负责干这个“拆了装、装了拆”的活。
L2CAP还提供协议复用功能。什么意思？就是多个上层协议（比如RFCOMM、SDP、ATT）可以共用同一条L2CAP通道。每个协议都有一个固定的通道ID（CID）。L2CAP根据CID，把数据分发给对应的上层协议。
我记得在做一个车载免提项目时，音频和电话控制走的是不同的L2CAP通道。有一次音频突然卡顿，我查了半天，发现是L2CAP的MTU（最大传输单元）协商出了问题。MTU设得太小，导致音频数据被切得太碎，传输效率低下。
避坑指南：我曾经因为L2CAP的MTU协商没处理好，导致音频流在蓝牙链路上频繁重传。记住，MTU不是越大越好，也不是越小越好。要根据实际应用场景（音频、文件传输、控制指令）来动态调整。对于音频流，建议MTU不小于672字节。
2.4 RFCOMM：模拟串口的“老将”
RFCOMM，全称Radio Frequency Communication。它干的事很简单：模拟串口。你想想看，很多老设备（比如GPS模块、串口打印机）都是通过串口通信的。蓝牙想和它们无缝对接，最好的办法就是虚拟一个串口出来。
RFCOMM基于L2CAP，它把L2CAP的通道模拟成串口的信号（RTS、CTS、DTR、DSR等）。在车载蓝牙里，RFCOMM主要用于电话控制（比如AT指令）和SPP（串口配置文件）。
我调试过一台车载主机，它和手机之间通过RFCOMM传AT指令来控制电话接听、挂断。有一次手机死活发不出AT指令，我抓包一看，RFCOMM的DLCI（数据链路连接标识符）没对上。嗯，这种问题很隐蔽，不抓包根本发现不了。
核心要点：RFCOMM最多支持30个虚拟串口（通道0-29）。每个串口对应一个DLCI。在车载蓝牙里，电话控制通常用DLCI 1。
2.5 SDP：蓝牙世界的“黄页”
SDP，全称Service Discovery Protocol。它的作用就是发现对方有什么服务。你想想看，你的手机和车载主机连接后，怎么知道对方支持哪些功能？是支持打电话？还是支持放音乐？还是支持文件传输？SDP就是干这个的。
SDP的工作流程很简单：
- 设备A向设备B发起SDP查询，问“你有什么服务？”
- 设备B返回一个服务列表，每个服务都有对应的服务记录。
- 设备A根据服务记录，决定要不要建立连接。
每个服务记录包含：
- 服务类ID：比如“Handsfree Audio Gateway”（免提音频网关）、“Advanced Audio Distribution”（高级音频分发）。
- 协议描述符：说明这个服务用的是什么协议栈（比如RFCOMM、L2CAP）。
- 属性：比如服务名称、版本号、支持的特性。
我遇到过最头疼的问题，就是SDP查询超时。车载主机和手机连接后，SDP查询如果超过10秒没响应，系统就会认为对方不支持某些服务。有一次就是因为手机端的SDP响应太慢，导致车载主机认为手机不支持A2DP（蓝牙音乐），结果音乐放不出来。后来我调整了SDP查询的超时时间，问题就解决了。
经验之谈：在车载蓝牙开发中，SDP查询的响应时间最好控制在3秒以内。如果超过5秒，用户体验就会明显变差。我习惯在代码里加一个SDP查询的看门狗，超时就重试一次。
2.6 小结：分层架构的“哲学”
蓝牙协议栈的分层，其实是一种抽象。每一层只关心自己的事，不越界。Controller管硬件，Host管逻辑，HCI是桥梁，L2CAP管数据，RFCOMM管串口，SDP管服务发现。各司其职，互不干扰。
我个人觉得，搞懂分层架构，比背一堆协议细节更重要。因为当你遇到问题时，你能快速定位问题出在哪一层。是HCI通信断了？还是L2CAP的MTU没协商好？还是SDP查询超时了？有了这个思路，调试效率会高很多。
下一章，我们会深入HCI，聊聊怎么用HCI命令控制蓝牙芯片。到时候我会分享一些我在车载项目里踩过的坑，保证让你少走弯路。