2、物联网基础：IoT 基本概念、设备通信协议（MQTT、HTTP、CoAP）、常见应用场景
物联网（Internet of Things, IoT）的本质是将物理世界中的设备、传感器与执行器接入数字网络，实现数据的采集、传输、计算与控制闭环。理解IoT的基本概念、通信协议选型与应用场景，是构建Google Cloud IoT解决方案的前提。本章将从设备-网关-云端的参考架构出发，深入剖析MQTT、HTTP、CoAP三种主流协议的适用边界，并通过智慧农业与工业预测性维护两个案例，帮助您建立从协议选型到方案落地的完整判断框架。
2.1 IoT核心概念与参考架构
IoT系统并非简单的“设备+云”，而是由感知层、网络层、平台层与应用层构成的复杂体系。感知层负责物理量采集与执行动作，网络层解决异构连接问题，平台层提供设备管理、数据接入与规则引擎，应用层则面向业务场景实现可视化与决策。在Google Cloud IoT架构中，Cloud IoT Core作为平台层核心，负责设备注册、鉴权（RS256/ES256证书）、遥测数据接收（MQTT/HTTP桥接）以及设备配置下发（Config/Command）。
理解IoT的关键在于区分“设备标识”与“设备影子”。设备标识是物理设备的唯一ID（如IMEI或自定义Device ID），而设备影子是云端维护的设备状态缓存，即使设备离线，应用层仍可读取最新状态或下发期望状态。Google Cloud IoT Core通过Device State和Config Topic实现这一机制，设备重启后自动同步云端配置，避免状态不一致。
2.2 设备通信协议深度对比：MQTT、HTTP、CoAP
协议选型直接决定系统的功耗、实时性、可靠性与开发复杂度。下表从传输层、消息模型、QoS机制、适用场景四个维度进行对比：
| 维度 | MQTT | HTTP/HTTPS | CoAP |
|---|---|---|---|
| 传输层 | TCP（可靠连接） | TCP（短连接） | UDP（轻量，支持DTLS） |
| 消息模型 | 发布/订阅（Topic） | 请求/响应（REST） | 请求/响应 + 观察（Observe） |
| QoS级别 | 0/1/2（最多一次/至少一次/恰好一次） | 无原生QoS，依赖TCP重传 | CON/NON（确认/非确认） |
| 报文开销 | 2字节固定头 + Topic | Header通常200-800字节 | 4字节基础头 |
| 典型场景 | 传感器遥测、命令下发、双向通信 | 设备配置、固件升级、REST API | 资源受限设备、NB-IoT、低功耗传感器 |
| Google Cloud支持 | Cloud IoT Core原生支持 | Cloud IoT Core支持HTTP桥接 | 需通过网关转换或自定义桥接 |
2.2.1 MQTT：双向通信的事实标准
MQTT基于TCP长连接，适合需要持续在线、双向通信的场景。其核心优势在于：持久会话（设备断线重连后自动恢复未确认消息）、遗嘱消息（设备异常离线时通知订阅方）、Topic通配符（+和#实现灵活的消息路由）。在Google Cloud IoT Core中，设备通过JWT或证书认证后，可发布遥测数据到/devices/{device-id}/events，订阅配置更新到/devices/{device-id}/config。
# 设备端使用Python Paho MQTT客户端连接Cloud IoT Core
import paho.mqtt.client as mqtt
import ssl, jwt, time
client = mqtt.Client(client_id="projects/my-project/locations/us-central1/registries/my-registry/devices/my-device")
client.username_pw_set(username="unused", password=jwt_) # JWT作为密码
client.tls_set(ca_certs="roots.pem", tls_version=ssl.PROTOCOL_TLSv1_2)
client.connect("mqtt.googleapis.com", 8883, 60)
client.publish("/devices/my-device/events", payload="{\"temp\":25.3}", qos=1)2.2.2 HTTP：简单直接的RESTful接入
HTTP适合设备不频繁上报、或需要与现有Web服务集成的场景。Cloud IoT Core提供HTTP Bridge，设备通过POST请求发送遥测数据，通过PATCH请求更新设备状态。但HTTP的短连接特性导致每次请求需重新建立TCP连接，功耗较高，且无法实现服务端主动下发（需设备轮询）。
2.2.3 CoAP：为资源受限设备而生
CoAP运行在UDP之上，报文头仅4字节，非常适合内存小于64KB、电池供电的传感器节点。其Observe模式允许云端订阅设备资源变化，减少轮询开销。但CoAP缺乏像MQTT那样的Broker机制，设备发现与消息路由需额外实现。在Google Cloud生态中，通常通过Cloud IoT Edge或第三方网关将CoAP转换为MQTT后接入。
2.3 常见应用场景与方案设计
IoT应用场景可归纳为三类：遥测监控（数据采集与可视化）、命令控制（远程执行与自动化）、资产追踪（位置与状态管理）。不同场景对协议、延迟、数据量的要求差异巨大。
2.3.1 案例：智慧农业环境监测
背景与约束：某农业科技公司需在500亩大棚内部署温湿度、土壤水分、光照传感器，每10分钟上报一次数据。大棚内无Wi-Fi覆盖，需采用LoRa网关汇聚数据，再通过4G回传云端。设备端MCU为STM32L0（RAM 20KB），电池供电需维持2年。
方案设计：传感器节点采用CoAP over LoRa（因LoRaWAN协议栈本身基于类似CoAP的确认机制），网关侧运行MQTT Broker，将CoAP数据转换为MQTT消息后通过4G上传至Cloud IoT Core。云端使用Cloud Functions处理数据，当土壤湿度低于阈值时，自动触发灌溉阀门控制命令（通过MQTT下发）。
关键指标与结果：设备端平均电流消耗12μA（休眠模式），单次上报功耗0.8mAh，2节AA电池（2000mAh）理论续航2.3年。端到端延迟（传感器→云端→控制指令）约2.8秒，满足灌溉控制需求。相比全MQTT方案，CoAP使设备待机功耗降低40%。
复盘经验：协议转换层（网关）是系统稳定性的关键瓶颈。需在网关实现消息缓存（断网时暂存数据）、协议超时重试、以及设备时钟同步（CoAP的Observe依赖时间戳）。此外，LoRa的扩频因子需根据大棚内障碍物密度动态调整，避免数据冲突。
2.3.2 案例：工业设备预测性维护
背景与约束：某工厂的压缩机需7×24小时监测振动与温度，采样频率1kHz，要求异常报警延迟小于5秒。工厂内网带宽有限，且不允许将原始振动数据全部上传云端（数据隐私）。
方案设计：采用边缘计算架构——工业网关（NVIDIA Jetson）运行TensorFlow Lite模型，实时计算振动特征（RMS、峰值因子、FFT频谱），仅上传特征值（每秒1条）至Cloud IoT Core。云端使用Cloud Pub/Sub触发异常检测模型，若判定异常则通过MQTT下发停机指令。协议选择上，边缘网关与云端采用MQTT QoS 1，确保特征数据不丢失；网关与传感器之间采用Modbus TCP（工业标准）。
关键指标与结果：异常检测准确率92.3%，误报率降至每月0.8次。数据上传量从原始1kHz×16bit×3轴≈48KB/s降至特征值约200B/s，带宽占用下降99.6%。报警延迟平均3.2秒，满足5秒要求。
风险与代价：边缘模型需定期更新（每季度重新训练），且网关硬件成本较高（约$800/台）。若网关宕机，本地传感器数据将丢失，因此需配置冗余网关或本地存储（SQLite）兜底。
2.4 常见误区与设计复盘
- 误区一：所有设备都使用MQTT。对于仅上报、无下行控制的传感器，HTTP或CoAP可能更省电。MQTT的长连接维持需要心跳包（Keep Alive），频繁心跳反而增加功耗。
- 误区二：忽略QoS等级选择。QoS 2虽保证恰好一次，但开销大且易阻塞；QoS 0适合高频遥测（丢失可接受）；QoS 1适合控制指令。Google Cloud IoT Core默认支持QoS 0/1，QoS 2需额外配置。
- 误区三：设备影子使用不当。设备影子并非数据库，不应存储历史数据。它仅保存最新状态，历史数据应通过Cloud Pub/Sub流入BigQuery。
- 误区四：安全仅依赖TLS。TLS加密传输层，但设备认证需使用证书或JWT。Google Cloud IoT Core要求每台设备有唯一密钥，且建议定期轮换。