4、Wi-Fi基础：Wi-Fi模块的功耗特性、TCP/IP栈、MQTT/HTTP上传方式
在TinyML设备的联网方案中，Wi-Fi是最具“双刃剑”特性的连接方式：它提供最高的数据吞吐量（数Mbps至数十Mbps）和最成熟的云对接生态，但代价是功耗远高于BLE和LoRa。对于电池供电的TinyML节点，Wi-Fi通常不适合做持续在线连接，而更适合“间歇性唤醒-快速上传-深度睡眠”的工作模式。本章将深入剖析Wi-Fi模块的功耗构成、TCP/IP协议栈在MCU上的资源开销，以及MQTT与HTTP两种主流上传方式的选型逻辑。
4.1 Wi-Fi模块的功耗特性与工作模式
Wi-Fi模块的功耗特性与BLE/LoRa有本质差异。BLE的广播电流约10-20mA，LoRa的发射电流约30-120mA，而Wi-Fi模块在TX状态下的峰值电流可达240-350mA（以ESP32-C3、ESP8266等常用模块为例，@3.3V供电）。这种数量级的差异决定了Wi-Fi不能像BLE那样维持周期性广播，也不能像LoRa那样长时间监听下行数据。
Wi-Fi模块的功耗主要由四个状态构成：TX（发射）、RX（接收）、空闲（Idle）和睡眠（Sleep）。其中TX和RX的电流消耗接近，而睡眠电流可以低至20μA（ESP32-C3在深睡模式下）。真正影响系统总功耗的，不是单次TX的电流大小，而是连接建立时间和保持连接的时间占比。
| 工作状态 | 典型电流 | 持续时间 | 功耗占比（典型场景） |
|---|---|---|---|
| TX（发射） | 240-350mA | 50-200ms/包 | 30-40% |
| RX（接收） | 80-100mA | ACK等待、下行监听 | 10-20% |
| 连接建立（扫描+关联+DHCP） | 100-200mA | 1-3s | 30-50%（一次性） |
| 睡眠（DTIM10） | 0.8-1.2mA | 保持连接时的间隔 | 5-10% |
| 深睡（Deep Sleep） | 20-50μA | 非工作时段 | <1% |
从表中可以看出，连接建立过程是功耗的“隐形杀手”。一次完整的Wi-Fi连接（扫描AP→认证→关联→DHCP获取IP）需要1-3秒，平均电流150mA左右。如果设备每次唤醒都重新连接，那么即使只上传1KB数据，连接开销也占了总能量的80%以上。因此，TinyML场景下的Wi-Fi设计核心原则是：减少连接次数，延长单次连接的有效数据传输量。
4.2 TCP/IP协议栈在MCU上的资源开销与优化
TinyML设备通常使用Cortex-M4/M7或RISC-V内核的MCU，RAM资源在256KB-2MB之间。完整的TCP/IP协议栈（如Linux内核网络栈）需要数MB内存，显然不适合MCU。因此，嵌入式领域普遍采用轻量级TCP/IP协议栈，最典型的是lwIP（lightweight IP）。
lwIP在MCU上的资源占用如下：
- Flash占用：50-100KB（取决于启用的协议特性，如TCP、UDP、DHCP、DNS等）
- RAM占用：30-50KB（包括PBUF池、TCP PCB表、Socket结构体等）
- 每个TCP连接额外开销：4-8KB（用于发送/接收缓冲区）
- TLS（如mbedTLS）：额外增加10-20KB RAM和50-100KB Flash
对于TinyML设备，这意味着如果使用Wi-Fi+TCP/IP+MQTT+TLS，总RAM需求可能达到80-120KB，Flash需求200-300KB。这已经接近ESP32-C3（400KB SRAM、4MB Flash）的可用资源上限。因此，协议栈的选择需要根据MCU资源进行权衡：
| 方案 | RAM占用 | Flash占用 | 适用场景 |
|---|---|---|---|
| AT指令集（模块内置协议栈） | 2-5KB（仅串口缓冲） | 0KB（MCU侧） | MCU资源极紧张，但模块成本高 |
| lwIP（无TLS） | 30-50KB | 50-80KB | 有足够RAM，可接受明文传输 |
| lwIP + mbedTLS | 50-80KB | 100-150KB | 需要加密传输，RAM≥256KB |
| FreeRTOS+TCP | 40-60KB | 60-100KB | 已使用FreeRTOS，需统一生态 |
在TinyML场景中，一个常见的优化策略是使用UDP代替TCP。UDP协议栈开销仅为TCP的1/3左右，且不需要维护连接状态。对于容忍丢包的数据上报（如传感器读数、推理结果），UDP+应用层ACK机制可以显著降低资源占用和功耗。但需要注意，UDP不保证数据到达顺序和完整性，需要应用层自行处理。
4.3 MQTT与HTTP上传方式对比与选型
MQTT和HTTP是TinyML设备上传数据最常用的两种应用层协议。两者在连接模型、数据开销、实时性和服务器要求上有显著差异。
4.3.1 MQTT：面向低带宽、高延迟容忍的发布/订阅协议
MQTT基于TCP长连接，采用发布/订阅模型。设备（客户端）连接到Broker（如EMQX、Mosquitto），发布消息到主题（Topic），其他订阅该主题的设备或服务端接收消息。MQTT的核心优势在于：
- 连接开销低：CONNECT报文仅50-100字节，PUBLISH报文头部仅2-4字节
- 支持QoS级别：QoS 0（最多一次）、QoS 1（至少一次）、QoS 2（恰好一次），可根据可靠性需求选择
- 双向通信：设备可以订阅下行控制指令，无需额外建立连接
- 遗嘱消息（LWT）：设备异常断开时，Broker可自动发布预设消息，便于云端感知设备状态
在TinyML场景中，MQTT的典型应用是周期性上报推理结果。例如，一个振动分析节点每30秒通过MQTT发布一次设备健康状态（正常/异常/故障），云端订阅该主题进行可视化展示和告警。
4.3.2 HTTP：简单直接但开销较大的请求/响应协议
HTTP基于TCP短连接，采用请求/响应模型。设备发送HTTP POST请求（通常为JSON格式），服务器返回200 OK。HTTP的优势在于：
- 实现简单：不需要额外的Broker，直接对接RESTful API
- 调试方便：可以使用浏览器、Postman等工具直接测试
- 兼容性好：几乎所有云平台（AWS IoT Core、阿里云IoT、腾讯云IoT）都提供HTTP接口
但HTTP的劣势也很明显：每个请求的Header就有200-500字节，对于小数据量（如几十字节的传感器读数）来说，协议开销占比过高。此外，HTTP是单向的，设备无法通过HTTP主动接收下行指令（除非使用轮询或WebSocket）。
| 对比维度 | MQTT | HTTP |
|---|---|---|
| 连接模型 | 长连接（可保持） | 短连接（每次请求新建） |
| 协议开销 | 2-10字节/消息 | 200-500字节/请求 |
| 实时性 | 毫秒级（长连接） | 秒级（含连接建立） |
| 双向通信 | 支持（订阅/发布） | 不支持（需轮询） |
| 服务器要求 | 需要MQTT Broker | 任意Web服务器 |
| 典型功耗（每次上报） | 30-50mAs（含连接保持） | 80-150mAs（含连接建立） |
| 适用场景 | 频繁小数据、需要下行控制 | 低频大数据、简单上传 |
4.4 实战案例：基于ESP32-C3的工业振动监测节点上传策略设计
下面通过一个完整的案例，展示如何根据实际约束选择Wi-Fi上传策略。
背景与约束：某工厂需要在20台旋转设备上部署振动监测节点。每台设备安装一个ESP32-C3节点，内置加速度计（ADXL345）和TinyML模型（用于判断设备是否异常）。节点需要每5分钟上传一次振动特征值（FFT峰值频率、RMS加速度、温度），数据量约200字节。工厂已有Wi-Fi网络覆盖，但AP数量有限，信号强度中等（RSSI -65dBm）。节点使用两节18650电池（并联，容量5000mAh）供电，期望电池寿命≥6个月。
初始方案与问题：最初采用HTTP POST方式，每次唤醒后重新连接Wi-Fi，上传JSON数据后断开。实测单次上报耗时4.2秒（连接2.8秒+上传0.4秒+断开1.0秒），平均电流145mA。计算单次上报能耗：4.2s × 145mA = 609mAs。每天上报288次（每5分钟一次），日能耗175,392mAs ≈ 48.7mAh。加上深睡电流（50μA × 24h = 1.2mAh），总日耗约50mAh。5000mAh电池理论寿命仅100天，不满足6个月要求。
分析与优化：问题核心在于每次唤醒都重新连接Wi-Fi。优化方案如下：
- 改为MQTT长连接：首次连接成功后不主动断开，使用MQTT Keep-Alive（每30秒发送PINGREQ）维持连接。模块在两次上报之间进入DTIM10睡眠（电流约1mA），而非深睡。
- 调整上报频率：将5分钟上报改为10分钟（根据设备故障发展速度，10分钟间隔仍可接受）。
- 使用QoS 0：振动特征值允许偶发丢失，选择MQTT QoS 0（最多一次），避免QoS 1/2的ACK等待开销。
- 精简JSON字段：将字段名缩短（如"freq"代替"peak_frequency"），数据量从200字节降至150字节。
优化后实测数据：
- 连接建立（首次）：2.8秒，145mA → 406mAs（一次性开销）
- 每次上报（含唤醒、发送、确认）：0.8秒，平均120mA → 96mAs
- DTIM10睡眠（10分钟间隔）：平均1.0mA × 600秒 = 600mAs
- 单次周期总能耗：96 + 600 = 696mAs ≈ 0.193mAh
- 每天上报144次（每10分钟）：144 × 0.193 = 27.8mAh
- 加上首次连接摊销（406mAs/天 ≈ 0.113mAh）和深睡（1.2mAh），总日耗约29.1mAh
- 5000mAh电池理论寿命：5000/29.1 ≈ 172天 ≈ 5.7个月
结果与复盘：优化后电池寿命从100天提升至172天，接近6个月目标。但仍有差距，进一步优化方向包括：将上报间隔延长至15分钟（寿命可超7个月）、使用太阳能辅助充电、或更换为ESP32-C3的IEEE 802.11b模式（降低发射功率）。
4.5 常见误区与设计建议
在实际项目中，工程师常犯以下错误：
- 误区一：认为Wi-Fi功耗一定比BLE高。实际上，如果单次传输数据量大（如>10KB），Wi-Fi的传输效率反而更高，因为BLE的有效吞吐率仅约100-200kbps，传输大数据的持续时间更长。
- 误区二：忽略DHCP和DNS的耗时。在弱信号环境下，DHCP可能耗时2-3秒，DNS解析可能再增加1秒。建议使用静态IP和IP直连（或预解析IP），减少连接时间。
- 误区三：盲目使用TLS。对于工厂内网等可信环境，可以关闭TLS，使用明文MQTT，显著降低握手开销。如果必须加密，优先考虑PSK模式而非证书模式。
- 误区四：MQTT Keep-Alive设置过短。Keep-Alive太短（如5秒）会导致频繁发送PINGREQ，增加功耗；太长（如60秒）可能导致Broker误判设备离线。建议设置为30-45秒。
最后，建议在项目初期就建立功耗预算表，明确每个状态的电流、持续时间和频率，计算总平均电流。使用Joulescope或Nordic Power Profiler等工具实测各阶段电流波形，验证理论计算。Wi-Fi上传策略的优化是一个持续迭代的过程，需要结合具体场景、网络环境和电池容量进行权衡。