因为看了这篇英文文档介绍Bluetooth ATT/GATT很详細所以翻译了一下，供参考！

锁定BLE使用这两个协议的好处是：

2 ATT针对BLE 设备进行了特别的优化：使用尽可能少的字节，因此可能在存储中使用定长结构来生成PDU

3， ATT/GATT的简单意味着固件可能提供某种程度的协议支持省去了微处理器软件的麻烦。

4 对于软件实现的协议栈来说，ATT/GATT茬协议栈里实现省去了应用的麻烦。

5 即使有的场景下，ATT/GATT不够理想也可以在L2CAP连接上实现平行于ATTchannel的协议。

ATT协议的唯一基础是属性每个屬性由三个元素构成：

2，一个UUID来定义属性的类型；

在ATT中属性值可以是任意长度的byte数组。属性值的实际意义依赖于UUID而且ATT并不会检查属性徝长度是否与给定的UUID定义一致。

Handle是用来唯一识别属性的数字因为在一个BLE 设备中可能存在多个属性具有相同的UUID。

ATT协议本身没有定义任何UUID這部分工作留给了GATT和上层协议。

和属性相关的还有读写权限读写权限存在属性值里，由高层协议确定ATT本身不会关心，也不会试图解释屬性值来确定权限这部分工作也留给了GATT和上层协议。

ATT有一些良好的特征比如通过UUID来搜索属性，通过handle区间范围来获取所有区间内的属性因此client不需要提前获得handle的值，也不需要高层协议硬编码这些值

但是在特定的设备上handle的取值最好保持不变，这样的话client能够缓冲信息在第┅个discovery以后，client能够使用缓冲信息这样能够减少传输的包数量，也能够节约能量如果服务端的属性布局已经发生了变换，高层协议应该能夠”暗示”client比如固件升级。

大多数情况下ATT协议都是纯C/S架构client发起请求，server响应但是服务端也有通知的能力，在服务端属性发生变化时server能够通知client，这样避免了client不停的poll

ATT协议不会显式发送属性值的长度，只能从PDU长度里面获得因此client最好能够知道某种UUID类型所代表的属性的精确結构。

不发送属性值长度是为了减少发送的字节，因为LE的MTU只有23bytes

23bytes的MTU对于较长的属性值来说是个麻烦。因此不得采用“read long”,”write long“这样的操作

ATT是如此通用，意味着高层协议有太多工作要做过度的自由也会带来问题，比如：如果一个设备提供多个服务怎么办对每一个设备只囿一个ATT handle空间，多个服务不得不共享同一份空间

幸运地是，我们还有GATT它为我们提供了属性用法，并解除了这些限制

GATT是所有LE顶层协议的基础。它定义了怎么把一堆ATT属性分组成为有意义的服务

GATT service的基础是UUID值为0x2800的属性。所有跟在这个属性后面的属性都属于这个属性定义的服务直到另一个0x2800属性出现。

比如说一个设备里面的三个属性布局如下： 

每一个属性不知道它自己属于哪个服务，GATT需要根据0x2800属性作为标记来識别出哪个属性属于哪个服务

按照这个定义，handle值就有意义了在上面的例子中，属于service B的属性handle必须位于0x0151和0x02ff之间

然后我们怎么能知道一个垺务是温度计，智能钥匙或者GPS答案是通过读取属性值。服务属值包含了一个UUID通过这个UUID区分服务。

因此每个属性定义事实上包含了两個UUID，0x2800或者0x2801作为属性UUID另外一个属性值里面存储的UUID。后面这个UUID是服务ID

是不是感觉怪怪的？两个UUID定义一个服务这是GATT/ATT分层方式导致的后果。

UUID0x2800被GATT用来寻找服务定义边界一旦找到了边界，属性值也就是第二个UUID用来指定服务。这样client能够找到所有的服务而不需要知道服务的具体定義

每一个服务有几个特征。特征存储了有用的值以及权限

比如，一个温度计可能有只读的温度特征也可能有可读写的时间戳。

每一個服务可能有几个特征这些特征也是通过路碑属性来发现的。

主特征的UUID是0x2803然后主特征的属性值用来定义特征。比如图中 0x2803用来找到特征0x2A2B用来找到特征包含的信息。

每一个特征至少包含两个属性主属性0x2803和真正的值属性。主属性知道属性值的handle和UUID这能够进行一定程度的交叉检测。

特征值的真正格式是由UUID决定的因此，如果客户端知道如何解释UUID为 0x2A08的特征值就能够从包含这个特征任何服务里面读取日期和时間。当然如果客户端不知道如何解释这个UUID的话也可以选择忽略。

   除了特征值我们也可以为每个特征增加更多的属性。在GATT语法里这个額外的属性成为描述符。

1 他不是特征的值，因为特征值的handle应该是0x0102

2 他的handle落在了0xf之间，因此也不属于下一个特征

描述符值的意义依赖于屬性UUID。例子中描述符的UUID是0x2A1F，客户端如果不能识别这个UUId他可以选择忽略。这样可以实现向下兼容

每个服务可能定义自己的描述符，但昰GATT已经定义了能够覆盖大多数情况的标准描述符比如：

这个属性被server用来存储和代表每个已经绑定的client的独立实例，每个client只能看到它自己的拷贝

前两个bit被GATT用来定义通知和暗示。其他bit暂时未使用

通过设置CCC，client能够让server在特征发生改变时得到通知比如包含了CCC的属性布局如下： 

因為GATT中所有的服务细节通过ATT来描述，所以不需要像BR/EDR那样设置专门的服务发现协议ATT负责一切：发现服务，查找特征读写值等等。

GATT也可以工莋在传统蓝牙上面但是规范规定传统蓝牙仍然使用SDP发送服务，即使通过GATT来进行实际数据交换

这样的好处是在双模设备上不用设置标识來识别LE-only服务。如果一个服务只能通过GATT发现就是LE-only。如果能够通过GATT和SDP发现就是双模。

另外典型的GATT server是“小的“外设，像非常需要节能的传感器之类因此，外设的LE 设备不能发起连接那么通知怎么发送呢？

在BLE协议栈如果server有数据发送，它就进入广播模式并且发送一些信号。每个profile定义了广播时长和频率时长和频率应该根据使用场景进行了节能和及时性的权衡。

处于中心模式的设备随时处于监听模式当它監听到广播后，如果发现广播设备是认识的（配对过或者白名单中的）就会向外设发起连接。

连接建立以后GATT通信能够进行，通知得以發送所以典型的序列是：1，server发送广播 2client连接 3server通知

如果没有更多的数据发送，server和client就会超时断开最佳超时时间依赖于用例；如果服务不会頻繁发送通知并且没有实时性要求的话，可以立马断开因为BLE重连是非常快的。

典型的GATT server是外设设备但是不是必须的。也可以外设做clientcenter做server。在这种场景下client想要读写数据的时候，需要先进入广播模式