GATT系列前六篇我们一直站在客户端的视角看 GATT：先发现地图，再按图取值，然后分七个可靠等级把值写回去。所有动作都由客户端发起，服务器始终是一个被提问的角色。但真实设备上有大量数据根本等不及客户端来问：心率带每秒要报新采样，手表固件传输时要不断回送接收进度，服务表发生变化时要主动提醒所有绑定手机。这一篇把方向彻底倒过来，看服务器如何不请自来地推送。
目录
一、推送之前先装开关：性质位与 CCCD
二、三种推送报文的全景
三、单条通知：0x1B，发后即忘的下行通道
四、空口实录一：467 条通知撑起的双向会话
五、多值变长通知：0x1F，一条报文打包多个特征
六、指示：0x1D 加 0x1E，点名必须答到
七、通知还是指示：一个可靠性加价的选择题
八、全系列收束之一：GATT 过程到 ATT opcode 的全景总表
九、全系列收束之二：30 秒事务超时与承载的死亡
十、全系列收官：一张地图、三条通道、一条红线
十一、测验
推送只有两种正式机制：通知（Notification）和指示（Indication）。前者发后即忘，后者必须等到客户端的确认。围绕这两种机制，这一篇还要完成整个系列的两次收束：把全部 GATT 过程到 ATT opcode 的映射总表串讲一遍，它是日后查任何报文的一页式索引；再讲透 30 秒 ATT 事务超时这条所有请求类过程共同的红线。老规矩，所有结论都拉到一份真实空口上。这份抓包记录的是一次 Central 手机给 Peripheral 手表传输表盘资源的 OTA 过程，恰好又是一个速率问题的现场，推送通道在里面留下了 467 条通知和一个有意思的未解码 opcode。
先看一个最直观的现场。传输开始前，手机往订阅描述符写入 0x0001，打开通知开关；31.1 毫秒后，手表方向的第一条 Handle Value Notification 就到了，载荷 12 字节。客户端什么都没问，数据自己上门——整个推送家族的故事就从这 31 毫秒开始。
