9.4 HTTP/HTTPS与BLE GATT互操作
9.4.1 HTTP/HTTPS在物联网中的适用性
HTTP（HyperText Transfer Protocol，超文本传输协议）是互联网最通用的应用层协议，但在物联网场景里，工程师面对的核心问题不是“HTTP好不好”，而是“什么时候该用它，什么时候该避开它”。这需要先拆解HTTP的协议约束，再衡量它不可替代的几项硬实力。
先说约束。HTTP 围绕请求—响应交互：客户端先发请求，服务器再响应。传感器完全可以作为 HTTP 客户端定时 POST 数据，并不需要公网地址或在设备上运行 Server；真正不自然的是平台在没有设备请求的情况下主动向 NAT 后的设备下发消息。HTTP/1.1 的流水线与连接复用存在队头阻塞问题；HTTP/2 通过流和多路复用缓解应用层阻塞，但 TCP 丢包仍会影响同一连接上的流；HTTP/3 改用 QUIC，使流之间的传输阻塞得到进一步隔离。请求—响应语义没有阻止设备主动上报，只是缺少 MQTT 那样内建的发布订阅、会话与离线消息语义。
传输效率和实时性也不乐观。TCP三次握手加TLS（Transport Layer Security，传输层安全协议）握手才能发起第一次HTTP请求。对一个电池供电的传感器来说，每次握手消耗的电量可能超过传输数据本身。报文开销也不小：HTTP请求头动辄数百字节，包含User-Agent、Accept、Cookie等为浏览器设计的字段，传感器根本用不上。而CoAP固定头极小，典型请求开销远低于HTTP；MQTT固定头也非常低（基于协议标准综合分析）。传感器一次只发送一个8字节的温度值时，HTTP的头部开销显然不可接受。在毫秒级响应的工业控制中，HTTP的握手延迟和队头阻塞可能直接拖慢生产节拍——这并非HTTP的设计失误，而是它的适用边界。
然而，HTTP有三块硬实力，让物联网工程师无法绕开它。
其一，通用性与生态系统。所有编程语言、操作系统和调试工具原生支持HTTP。团队开发时，打开浏览器或一条curl命令就能验证接口，集成门槛几乎为零。RESTful API（Representational State Transfer，表征状态转移）设计拥有完整的工具链（OpenAPI、Swagger），无论是GraphQL还是gRPC，底层都绕不开HTTP。设备和平台开发者共用同一套API契约，沟通成本大幅降低。
其二，安全生态成熟。HTTPS 是 HTTP over TLS，拥有成熟的密码套件、证书、库和运维工具。但“用了 HTTPS”不等于安全完成：仍需验证协议版本、证书链、私钥保护、主机身份、轮换、授权和应用漏洞。它的优势是复用经过广泛审查的标准机制，而不是让安全审计只剩证书有效期一项。
其三，与上游系统无缝衔接。现代云原生架构、微服务、Web API默认使用RESTful接口。物联网平台向上对接企业的业务系统（ERP、MES、CRM），天然通过HTTP REST API实现。如果设备层也支持HTTP，平台就不必额外做协议转换，减少一层代理开销。许多工业协议转换网关正是这个模式：南向接Modbus总线，北向用HTTP上报聚合数据。
基于这些特点，HTTP在物联网中有两个典型适用角色。
角色一：设备配网
智能灯泡、Wi-Fi摄像头第一次使用时，手机App通过HTTP向设备临时开启的Web Server发送Wi-Fi SSID和密码。配网是一次性的、用户交互式的场景，对功耗不敏感——HTTP的通用性和方便性才是关键。配网完成后，Web Server自动关闭。
角色二：网关北向通信
边缘网关向上与平台通信，数据量不大、实时性不高时，HTTP REST API足以胜任。网关有稳定电源，不关心心跳开销；它聚合子设备数据，打包成JSON批量发送。在云边协同架构中，HTTP是网关与平台之间最直接的通信方式。
下面的对比表从传输层、报文开销、连接建立和典型场景等维度展示HTTP、MQTT、CoAP的差异。
表9-4 HTTP vs MQTT vs CoAP性能对比（基于IETF协议标准与通用工程判断）
| 对比维度 | HTTP/HTTPS | MQTT | CoAP |
|---|---|---|---|
| 传输层协议 | TCP（HTTP/3为QUIC/UDP） | TCP | UDP |
| 通信模型 | 请求/响应 | 发布/订阅（Broker中转） | 请求/响应（支持Observe观察者模式） |
| 报文开销 | 大（头部数百字节） | 极小（固定头开销低） | 极小（固定头开销低，典型请求远低于HTTP） |
| 连接建立时间 | 慢（TCP三次握手+TLS握手） | 中（TCP长连接心跳维持） | 快（无连接，直接UDP报文） |
| 典型功耗 | 高（握手频繁） | 中（心跳维持开销） | 低 |
| 服务质量 | 无原生QoS（依赖TCP重传） | QoS 0/1/2 | CON/NON确认与非确认消息 |
| 设备管理模型 | 无（需自行设计） | 无（仅消息投递） | 无（仅数据交换） |
| 典型场景 | 设备配网、平台API、网关北向 | 远程监控、大规模设备通信 | 传感器采集、NB-IoT终端 |
HTTP的安全与运维细节
HTTPS的安全成熟度是通用判断，但把它落到设备侧，工程量集中在证书生命周期上。设备端证书与浏览器证书的最大区别在于：浏览器有用户看着，过期了弹窗提醒即可换新；设备证书过期则表现为“设备失联”，现场排查后才发现是证书到期，这类事故在物联网运维中占比不低。因此设备侧HTTPS必须把证书轮换设计进生命周期：证书有效期要与产品换代周期对齐（长周期设备宁可三年一换也不要一年一换），轮换要在旧证书过期前通过双证书重叠期完成，且轮换通道本身不能依赖即将过期的那张证书——否则就是自锁。通用方法是平台侧监控证书剩余有效期并主动下发轮换指令；标准层面，IETF 在 RFC 7030 中定义了 EST（Enrollment over Secure Transport，基于安全传输的证书注册协议），设备可在证书到期前向注册机构在线申请新证书、完成自动续期，但嵌入式TLS栈对 EST 的支持参差不齐，选型时需要先确认。
TLS会话恢复对功耗的意义常被低估。完整的TLS握手需要两个往返（TLS 1.3压缩到一个），对电池设备来说，每次冷启动连接都要重付这笔电费。会话恢复机制（Session ID、Session Ticket）允许客户端凭上次会话的凭据跳过完整握手；TLS 1.3的0-RTT（零往返时间）更进一步，第一个数据包就能携带应用数据。对一个每天上报十次、每次八个字节的传感器，握手开销占每次通信能耗的比例可能超过八成，会话恢复直接决定电池寿命。但0-RTT有重放风险——攻击者截获0-RTT报文重发，服务器无法区分——因此0-RTT只适合幂等请求（数据上报天然幂等），不适合“开锁”这类指令。
OTA固件下载是HTTP在设备侧少有的“正场”。固件镜像动辄数百KB到数MB，是日常上报数据量的万倍级；这样的传输需要三件事：断点续传（HTTP的Range请求头天然支持，中断后从偏移量继续，不必整包重传）、大文件分发（CDN基础设施围绕HTTP构建，固件可以推到边缘节点就近下载）、可校验的完整性（Content-Length与分块校验配合）。MQTT不适合这个场景的原因同样是结构性的：发布/订阅模型为小消息设计，把数MB的镜像切片塞进Topic，发布者还要自己实现断点逻辑、背压控制和慢消费者隔离，等于在应用层重新发明一遍HTTP已经解决的问题。工程上常见的分工是：控制面（通知设备“有新固件了”）走MQTT，数据面（固件本体下载）走HTTPS——各用所长。
从轮询到推送：HTTP的三种补网方案
HTTP的请求/响应模型不擅长推送，但现实中总有一些设备只能跑HTTP（受限网络策略、存量固件、只能出站连接）。这时有三条“补网”路径，各自用不同的代价换取推送能力。
短轮询（Polling）：设备定时向平台发 GET 请求“有新指令吗”。实现最简单，但时延下限等于轮询间隔。长轮询（Long Polling）：平台持有请求直到有数据或超时，设备收到响应后再发起下一次请求；现代异步服务器不必为每条连接占一个操作系统线程，但容量仍要按长期在线连接规划。Webhook（回调）：平台主动调用设备或网关的 HTTP 接口，要求目标可被可靠寻址并妥善保护入站端口，通常更适合受管网关。SSE（Server-Sent Events）：服务器沿客户端先建立的 HTTP 长连接单向向客户端推送事件，因此适合“平台→网关”的指令或事件通知；网关向平台上报仍需另发 HTTP 请求，不能把 SSE 写成双向事件流。
这三条路径的共同问题在于：它们都是对请求/响应模型的“补丁”。短轮询浪费在空查询上，长轮询占用连接，Webhook要求可入站寻址，SSE与Webhook的连接保活、断线重连、事件序号去重都要自己实现。MQTT长连接把这些统一在协议内：心跳保活、QoS重传、遗嘱消息、会话恢复都是标准件。工程结论因此很清晰：HTTP推送方案适用于网关级、低频、改造受限的场景；一旦设备侧需要高频主动上报或可靠的指令下发，就应该回归MQTT/CoAP，而不是继续在HTTP上叠补丁。
实践边界：选择 HTTP、MQTT 还是 CoAP，要同时看电源、报文频率、连接保持、网络可达性、安全方案和平台基础设施。稳定供电、低频请求—响应可优先评估 HTTP；需要发布订阅、断线会话或低开销 UDP 时再分别评估 MQTT 或 CoAP。电池供电和主动上报都不是单独的排他条件。AI Agent 常经 HTTP 接入平台，但设备侧推理结果可以使用任何经过验证且满足交付语义的上行协议，不必为了“维持长连接”一律改用 MQTT。
9.4.2 BLE GATT协议与应用层抽象
在BLE设备开发中，决定数据交互效率和部署质量的，从来不是蓝牙射频本身，而是GATT模型的设计。GATT（Generic Attribute Profile，通用属性配置文件）是BLE的应用层协议，它定义了一套属性数据库的发现与访问规则。一个温湿度传感器能否被手机App读取出当前数值、一个智能锁能否按需上报状态，都取决于GATT中Service、Characteristic、Descriptor的划分粒度与权限分配。
GATT的数据模型是三级嵌套结构：Service（服务）、Characteristic（特征）和Descriptor（描述符）。 每个BLE设备可以暴露多个Service，例如心率服务、电池电量服务。每个Service包含一个或多个Characteristic——承载数据的最小单元，其Value字段存放诸如温度、开关状态等实际数值。每个Characteristic通过Properties位掩码声明允许的操作：Read、Write、Notify（无确认推送）或Indicate（带确认推送）。Descriptor提供附属配置，最典型的是CCCD（Client Characteristic Configuration Descriptor，客户端特征配置描述符）——中央设备写入CCCD即可订阅该Characteristic的Notify或Indicate消息。从结构上看，GATT本质不是通信协议，而是一个属性数据库的访问和事件分发模型，它定义了一套标准化的RPC规则。
下图展示了BLE协议栈从射频到应用层的主链路，以及Notification与Indication在执行路径上的关键分支。
Notification与Indication的取舍
这是BLE工程中一个经典权衡：Notification模式下，设备发送数据后无需中央设备确认，能耗极低，适合周期性传感器数据（如温度、心率），但无线环境恶化时可能丢包；Indication模式要求每个数据包都被逐包确认，可靠性高，但时延和功耗明显增加。两者均为Bluetooth Core Specification定义的GATT子过程。工程建议是：环境监测、周期性采样用Notification；指令执行结果、故障告警等必须确认的事件用Indication。
BLE安全：配对、绑定与隐私地址
GATT本身不提供安全，加密与身份认证由配对（Pairing）机制完成。BLE有四种配对模式，核心差异在于能否抵抗中间人（MITM）攻击。Just Works：双方不经任何带外验证直接协商密钥，无法防中间人——攻击者可以分别与两端各配一次对，在中间明文转发。Passkey：设备端显示或输入六位数字密码，双方比对一致才建立连接，能防中间人，但六位密钥空间小，且要求设备具备显示或输入能力。Numeric Comparison（LE Secure Connections引入）：两端屏幕各显示一个六位数字，用户确认两者一致，安全性建立在“两条信道独立”之上——攻击者无法让两块屏幕显示出相同的数字。Out of Band（OOB）：密钥材料经NFC、二维码等非蓝牙信道交换，安全性最高，且用户体验可以做到“碰一下即配对”。
绑定（Bonding）是配对之后的密钥持久化：双方把协商出的长期密钥（LTK）存进安全存储区，重连时跳过完整配对直接加密，既省时又省电。工程上的风险点在于密钥存储位置——若LTK存在可读的Flash且无安全启动保护，物理接触设备即可提取密钥、伪造身份，因此高价值设备需要支持加密加速硬件与安全存储区。隐私地址（Resolvable Private Address，RPA）解决的是另一个问题：BLE地址默认是静态的，任何人拿扫描器就能长期跟踪一台设备的行踪。RPA让设备周期性更换随机地址，只有持有对应IRK（Identity Resolving Key）的绑定方才能解析出真实身份——防跟踪与可识别这对矛盾由此调和。工程建议归纳为：有屏幕的设备用Numeric Comparison；无屏幕但高价值的用OOB（NFC、出厂预烧二维码）；Just Works仅用于低价值数据（如传感器读数），绝不用于门锁、支付类指令。
BLE Mesh
BLE Mesh将GATT的点对多点星型拓扑扩展为多点对多点的中继网络。它不取代GATT，而是在GATT之上增加基于发布/订阅的寻址和转发机制。每个节点既是发送者也是中继者，通过受控洪泛保证覆盖。Mesh的Model Layer标准化了灯控、传感器、场景等行为——开发者只需配置Generic OnOff模型，即可控制网络中所有相关设备的开关状态。从抽象角度看，BLE Mesh将开发者从逐跳路由上升到对语义模型的操作，与GATT的Service/Characteristic范式一脉相承，粒度更大、拓扑更复杂。
从GATT到平台位号：BLE网关的桥接模式
GATT定义了设备本地互操作的数据模型，但物联网平台的消费方不是手机App，而是位号（Point）与物模型——中间需要一座桥。桥接路径有两类：其一是手机App路径，用户手机作为临时中央设备读出GATT数据再经Wi-Fi上报平台，适合消费级、人在场的场景，缺点是数据连续性依赖用户手持设备；其二是BLE网关路径，网关作为常驻中央设备批量扫描、连接子设备，把GATT读数转成平台报文——这是工业与楼宇场景的主路径。
网关桥接的核心是映射：一个子设备的Service/Characteristic组合，映射为平台上的一个设备及其位号集合；Characteristic的UUID与解析格式对应位号的属性定义（数据类型、量程、单位——与第 4 章物模型的属性建模直接呼应），Properties位掩码则决定位号的读写方向：Read型Characteristic映射为可读位号，Write型映射为可写位号（指令下发），Notify/Indicate型映射为事件订阅源。Descriptor层面，CCCD的订阅状态对应平台侧“该位号是否启用上报”的配置项。映射做好之后，南向的BLE细节对平台完全透明，上位系统看到的就是一组统一模型的位号。
两个物理层参数决定桥接的容量边界。连接参数（Connection Interval）是中央设备与子设备约定的轮询周期：间隔短（如15ms）则吞吐高、时延低，但双方射频唤醒频繁、功耗高；间隔长（如1s以上）则反之。网关通常对功耗不敏感、追求吞吐，可与子设备协商较短间隔；但单个网关的射频时间是共享资源，连接的子设备越多，每条连接分到的空口时间越少，实际吞吐随连接数下降。扫描侧同理：批量扫描的窗口与占空比决定了发现新设备的速度，与维持既有连接的数据收发互相争抢空口。通用工程经验是单个网关维持十余个活跃连接、按分钟级周期轮询数十个低频传感器是舒适区；数百设备的高密度场景要么堆网关做分区，要么直接转用BLE Mesh。DC3的BLE驱动是南向驱动族中的一员，定位为示例实现，不代表当前能力边界——读者应以桥接模式本身作为方法参考，而非以驱动的现网规模作为选型依据。
在物联网应用中，BLE GATT 定义了短距设备本地互操作的数据模型。对于近距离、电池供电并有成熟手机或网关生态的场景，GATT 是常见选择。Service/Characteristic/Descriptor 结构与 Notification/Indication 机制只是工程基础的一部分；部署还要验证连接间隔、MTU、并发连接、配对方式和厂商互操作。小结本节：HTTP 的价值在通用生态与北向衔接，BLE GATT 的价值在短距本地数据模型，两者的边界由电源、通信模式与安全需求共同决定。设备协议汇聚到平台并向外部 AI Agent 开放时，问题就从“选哪个协议”转向“如何以标准化、可授权的方式暴露平台能力”——这正是 9.5 节的 MCP 要回答的。