1. 物联网无线协议全景：七种协议栈对比与适用场景

做物联网抓包分析，第一件事不是拿起工具就抓。你得先搞清楚——对面跑的是什么协议？

我见过不少工程师，拿着 Wireshark 对着 Zigbee 网络一顿猛抓，结果全是乱码。为什么？因为 Zigbee 用的 802.15.4 帧结构，Wireshark 默认不解析。说白了，协议栈选型决定了你的抓包策略和分析工具链。

这一章，我把市面上主流的七种物联网无线协议拉出来，从协议栈结构、频段、速率、功耗、组网方式到适用场景，逐一拆解。嗯，这里要注意：我不打算讲成教科书式的罗列，而是结合我实际项目里踩过的坑，告诉你每种协议「到底能干什么、不能干什么」。

1.1 七种协议速览

先给一张总览表。你把它当作选型时的速查手册就行。

协议	频段	峰值速率	功耗	组网方式	典型距离
Wi-Fi	2.4 / 5 / 6 GHz	最高 9.6 Gbps (Wi-Fi 6)	高	星型（AP-STA）	室内 30-50 m
BLE	2.4 GHz	1-2 Mbps	极低	星型 / 广播 / Mesh	10-100 m
Zigbee	2.4 GHz / 868 / 915 MHz	250 kbps	低	Mesh	10-100 m（节点间）
LoRa	Sub-1 GHz (ISM)	0.3-50 kbps	极低	星型（网关-节点）	2-15 km
NB-IoT	授权 LTE 频段	约 200 kbps	低	蜂窝（基站-终端）	1-10 km
Thread	2.4 GHz	250 kbps	低	Mesh（IPv6）	10-30 m（节点间）
Z-Wave	800-900 MHz	9.6-100 kbps	低	Mesh	室内 30 m

1.2 协议栈分层对比

抓包分析的本质，是在物理层和数据链路层之间做文章。不同协议的分层模型差异很大，我习惯把它们分成三类来看。

1.2.1 短距高速类：Wi-Fi

Wi-Fi 的协议栈最接近 TCP/IP 经典模型。物理层用 OFDM/OFDMA，MAC 层用 CSMA/CA。抓包时你看到的是 802.11 帧头，里面有 RA、TA、BSSID、Sequence Control 这些字段。

我记得有一次排查智能摄像头频繁掉线的问题，抓包发现 AP 一直在发 Deauth 帧，但客户端不回应。后来定位到是 Wi-Fi 省电模式（PS-Poll）的交互时序出了问题。嗯，这种问题在 BLE 和 Zigbee 里几乎不会出现——因为它们的 MAC 层设计完全不同。

1.2.2 短距低功耗类：BLE、Zigbee、Thread、Z-Wave

这四兄弟都跑在 2.4 GHz 或 Sub-1 GHz，但协议栈差异很大。

• BLE：物理层用 GFSK，链路层有 40 个信道（37 个数据 + 3 个广播）。我个人习惯把 BLE 的协议栈看成「三层」：Controller、Host、Application。抓包时重点看 LL（链路层）和 ATT（属性协议）层。
• Zigbee：基于 802.15.4，网络层支持多跳 Mesh。它的 APS（应用支持子层）和 ZCL（Zigbee 集群库）是抓包分析的关键。我曾经在智能灯控项目里，发现开关指令有时延，抓包看到路由请求（Route Request）在网络里泛洪了 3 秒才收敛——这就是 Mesh 网络的代价。
• Thread：也是 802.15.4 物理层，但网络层用 IPv6 + 6LoWPAN。它的抓包分析更接近 IP 网络，你可以看到 ICMPv6、UDP、CoAP 这些上层协议。说白了，Thread 是「用 IP 的思路做物联网」。
• Z-Wave：私有协议，物理层用 FSK/GFSK，网络层也是 Mesh。它的帧结构比 Zigbee 简单，但兼容性是个大坑——不同代的 Z-Wave 芯片互操作经常出问题。

1.2.3 远距低功耗类：LoRa 和 NB-IoT

这两兄弟是「广覆盖」的代表，但技术路线完全不同。

• LoRa：物理层用 Chirp Spread Spectrum（CSS），MAC 层是 LoRaWAN。抓包时你看到的是上行（Uplink）和下行（Downlink）帧，有 FCnt、FCtrl、FPort 这些字段。LoRa 的抓包难点在于——它用扩频技术，普通频谱仪看不到信号，得用专门的 LoRa 抓包器。
• NB-IoT：基于 LTE 的窄带版本，物理层用 SC-FDMA/OFDMA。它的协议栈就是 LTE 协议栈的简化版，抓包可以用商用 LTE 抓包工具（比如 QXDM、TEMS）。但 NB-IoT 的功耗优化主要在 RRC 状态机（IDLE、CONNECTED、eDRX、PSM），抓包时重点看这些状态切换。

1.3 协议栈结构图

下面这张 SVG 图，我把七种协议的协议栈分层画在一起。你一眼就能看出哪些协议共用物理层，哪些协议在网络层分道扬镳。

1.4 适用场景分析

协议栈结构决定了协议的能力边界。下面我按场景分类，说说每种协议「该用在哪儿、不该用在哪儿」。

1.4.1 智能家居场景

智能家居是物联网最卷的赛道。Wi-Fi、BLE、Zigbee、Thread、Z-Wave 都在抢这块蛋糕。

• Wi-Fi：适合摄像头、智能音箱、网关这类「持续供电 + 高带宽」的设备。但 Wi-Fi 的功耗是个硬伤，电池供电的门锁用 Wi-Fi 基本撑不过一个月。
• BLE：适合传感器、门锁、灯泡。BLE Mesh 在 2020 年后成熟度大幅提升，我个人习惯在需要「手机直连」的场景优先选 BLE。
• Zigbee：适合大规模传感器网络。它的 Mesh 自愈能力比 BLE 强，但互操作性是个坑——不同厂商的 Zigbee 设备经常连不上。我踩过这个坑：A 家的网关死活配不上 B 家的插座，最后发现是 ZCL 版本不一致。
• Thread：适合需要 IP 可达的场景。Thread 设备可以直接用 IPv6 地址访问，省去了网关协议转换的麻烦。但 Thread 的生态还不够大，目前主要在 Matter 标准里发力。
• Z-Wave：在欧美智能家居市场占有率很高，但频段和协议都是封闭的。抓包分析需要专用工具，不适合新手入门。

1.4.2 工业与远距场景

工业物联网和智慧城市，核心诉求是「覆盖广、功耗低、穿透强」。

• LoRa：适合水表、气表、烟感、资产追踪。它的灵敏度能做到 -140 dBm，穿透能力极强。但速率很低，传一张图片可能要几分钟。我记得有个智慧农业项目，客户想用 LoRa 传田间高清图像，我直接劝退了——LoRa 只适合传小数据包。
• NB-IoT：适合智能停车、井盖监测、市政路灯。NB-IoT 的优势在于「有运营商兜底」，网络覆盖和安全性比 LoRa 好。但 NB-IoT 需要 SIM 卡，有月租费，不适合纯私有网络。

1.5 选型决策流程

最后，我分享一个我自己在项目里用的选型决策流程。你照着走一遍，基本不会选错。

1. 先看供电：电池供电？→ 排除 Wi-Fi。持续供电？→ 所有协议都行。
2. 再看距离：室内 100 米以内？→ 短距协议（BLE / Zigbee / Thread）。室外 1 公里以上？→ 远距协议（LoRa / NB-IoT）。
3. 再看数据量：视频流或大文件？→ 只有 Wi-Fi 能扛。传感器读数或开关状态？→ 所有低功耗协议都行。
4. 最后看生态：需要手机直连？→ BLE。需要 IP 可达？→ Thread 或 Wi-Fi。需要大规模 Mesh？→ Zigbee 或 Thread。