入网协议概览：常见的物联网通信协议与选型原则
各位同学，欢迎来到第二章。上一章我们聊了物联网的整体架构，今天咱们把目光聚焦在「连接」这件事上。
设备怎么把数据发出去？用哪种「语言」跟云端对话？这就是入网协议要解决的问题。说实话，我入行头三年，最头疼的就是选协议。项目做了一半发现 Wi-Fi 功耗扛不住，或者 LoRa 带宽不够用，那真是欲哭无泪。
所以这一章，我会把主流的几种协议掰开揉碎讲清楚。你不需要全部精通，但得知道它们各自擅长什么、不擅长什么。这样以后选型时，心里才有底。
2.1 近距离无线协议：Wi-Fi、BLE、Zigbee
先看离我们最近的。这三种协议，覆盖了家里、办公室、工厂车间这些场景。
2.1.1 Wi-Fi：高带宽，高功耗
Wi-Fi 大家最熟悉。手机、电脑、智能音箱，基本都靠它上网。它的优点是带宽大——802.11ac 能跑到几百 Mbps，传输距离在室内也有几十米。
但代价也很明显：功耗高。一个 Wi-Fi 模块待机电流动辄几十毫安，干电池根本撑不住。我做过一个智能插座项目，客户要求用电池供电，结果 Wi-Fi 方案测下来，两节 AA 电池只撑了三天。后来果断换成了 Zigbee。
2.1.2 BLE：低功耗，短连接
BLE（蓝牙低功耗）是手机生态的宠儿。它的功耗极低——一颗纽扣电池能跑一年。而且手机原生支持，不需要额外网关。
但 BLE 的传输速率不高（约 1-2 Mbps），通信距离也短（空旷环境也就 10-30 米）。它最适合做「小数据、低频次」的传输，比如温度计、手环、门锁。
我记得有个做智能门锁的客户，一开始用 BLE 直连手机，用户反馈说「每次开门都要掏出手机等 3 秒」。后来加了 BLE Mesh，体验才上来。嗯，这里要注意：BLE 的广播模式延迟不稳定，实时性要求高的场景要慎用。
2.1.3 Zigbee：自组网，低功耗，但生态封闭
Zigbee 是我个人比较喜欢的一种协议。它最大的特点是支持自组网——设备之间可以互相中继，形成一张大网。一个 Zigbee 网络理论上可以挂几百个节点，而且每个节点功耗极低。
但 Zigbee 也有硬伤：它需要网关。手机不能直连 Zigbee 设备，必须通过一个 Zigbee 协调器（通常是智能音箱或专用网关）来转发。另外，不同厂家的 Zigbee 设备互操作性很差——你买 A 家的灯泡，不一定能连 B 家的网关。
2.2 远距离低功耗协议：LoRa 与 NB-IoT
如果你的设备分布在几公里甚至十几公里范围内，比如农田、停车场、管道监测，那 Wi-Fi 和 BLE 就鞭长莫及了。这时候需要 LPWAN（低功耗广域网）技术。
2.2.1 LoRa：自主可控，适合私有网络
LoRa 是一种扩频调制技术，灵敏度极高。在郊区空旷环境下，一个 LoRa 网关覆盖半径可达 5-15 公里。功耗也低——一颗 18650 电池，每天发几次数据，能撑两三年。
LoRa 最大的优势是你可以自建网络。不需要运营商基站，自己架一个网关就能覆盖一片区域。这对很多企业来说很有吸引力。
但 LoRa 的带宽非常有限——实际有效速率只有几百 bps 到几十 kbps。你只能传一些短报文，比如「温度 25.3℃」「阀门状态：开」。想传图片？别想了。
2.2.2 NB-IoT：运营商背书，可靠但需付费
NB-IoT 是 3GPP 标准的一部分，由运营商建网。它的覆盖比 LoRa 更广——有手机信号的地方基本都能用。而且因为是授权频段，干扰少，可靠性高。
但 NB-IoT 需要 SIM 卡，每年要交流量费。虽然资费不高（一年几十块），但对海量设备来说，这笔钱不可忽视。另外，NB-IoT 的功耗比 LoRa 略高，而且不支持设备间直接通信，所有数据必须经过运营商核心网。
| 特性 | LoRa | NB-IoT |
|---|---|---|
| 频段 | 免授权（如 470 MHz） | 授权频段（运营商） |
| 覆盖半径 | 2-15 km（视环境） | 1-10 km（基站密度决定） |
| 速率 | 0.3-50 kbps | 20-250 kbps |
| 功耗 | 极低（电池数年） | 低（电池 1-2 年） |
| 网络所有权 | 自建 | 运营商 |
| 资费 | 无（设备成本） | 按年收费 |
2.3 应用层协议：MQTT 与 CoAP
物理层和数据链路层搞定了，数据怎么组织、怎么传输？这就轮到应用层协议登场了。
2.3.1 MQTT：发布/订阅，适合不可靠网络
MQTT 是我用得最多的协议。它基于发布/订阅模式，客户端不直接通信，而是通过一个 Broker 中转。这样做的好处是：解耦、灵活、支持一对多。
MQTT 有 3 个 QoS 等级：
- QoS 0：最多发一次，丢了不管。适合传感器定期上报，丢几包无所谓。
- QoS 1：至少发一次，会重传。适合控制指令，但可能重复。
- QoS 2：恰好发一次，最可靠。适合计费、告警等关键数据。
我建议：大部分场景用 QoS 1 就够了。QoS 2 的握手开销大，在弱网环境下反而容易卡死。
2.3.2 CoAP：类 HTTP，适合资源受限设备
CoAP 是另一种轻量级协议，设计思路跟 HTTP 很像——请求/响应模式，支持 GET、POST、PUT、DELETE。但它跑在 UDP 上，头部只有 4 字节，比 HTTP 轻得多。
CoAP 还有一个亮点：支持观察模式。客户端可以「订阅」一个资源，服务器有变化时主动推送，不用轮询。这对功耗敏感的设备很友好。
不过 CoAP 的生态不如 MQTT 成熟。很多云平台对 CoAP 的支持比较有限。我个人习惯：如果设备资源极度受限（比如 8 位 MCU、几十 KB RAM），优先考虑 CoAP；否则还是 MQTT 更省心。
2.4 协议选型原则：怎么选才不翻车？
说了这么多，到底怎么选？我总结了一个「四步法」：
- 看供电：插电设备 → Wi-Fi 或以太网；电池设备 → BLE、Zigbee、LoRa、NB-IoT。
- 看距离：室内几十米 → BLE/Zigbee；室外几公里 → LoRa/NB-IoT。
- 看带宽：视频流 → Wi-Fi；传感器小数据 → LPWAN 或 BLE。
- 看成本：自建网络 → LoRa；用运营商网络 → NB-IoT；手机直连 → BLE。
下面这张图，是我自己画的一个选型决策流程，你可以存下来当参考。
2.5 我的选型心法
最后分享一点个人经验。选协议不是「哪个好就用哪个」，而是「哪个最不坏就用哪个」。你想想看，一个智能水表项目，用 NB-IoT 确实可靠，但每年几十万台的流量费，老板能接受吗？用 LoRa 自建网关，前期投入大，但长期运营成本低。
我一般会画一个矩阵：横轴是功耗，纵轴是带宽，然后把候选协议标上去。落在「低功耗 + 低带宽」象限的，基本就是 LPWAN 的天下；落在「高功耗 + 高带宽」的，乖乖用 Wi-Fi。
嗯，协议选型没有银弹。但只要你把供电、距离、带宽、成本这四个维度想清楚，至少不会犯大方向上的错误。