1、连接基础：物联网连接模型与核心协议

做物联网排查，第一件事不是拿抓包工具，而是先搞清楚——你的设备到底是怎么连上云的？

我见过太多工程师，一上来就查网络、改代码、换模块，折腾半天发现是架构理解错了。说白了，连模型都没搞对，排查就是瞎忙活。

1.1 物联网连接模型：设备 → 网关 → 云

典型的物联网系统，分三层：

• 设备层：传感器、执行器、嵌入式终端。资源受限，跑不了完整 TCP/IP 栈是常事。
• 网关层：协议转换、数据汇聚、本地决策。我习惯叫它「二传手」。
• 云平台层：数据存储、分析、远程控制。真正的业务大脑。

你想想看，设备断连，可能断在哪一层？

我在项目中遇到过一种情况：设备上报数据偶尔丢失，查了三天，最后发现是网关的 NAT 会话超时。设备端以为还连着，网关早把映射丢了。嗯，这就是没搞懂模型吃的亏。

1.2 TCP/IP 协议栈回顾

物联网断连，90% 的问题出在传输层和网络层。我建议你把 TCP/IP 栈的每一层都刻在脑子里。

层级	核心协议	常见断连原因
应用层	MQTT, CoAP, HTTP	心跳超时、Topic 权限、Payload 格式错误
传输层	TCP, UDP	端口不通、半开连接、窗口满、RST 包
网络层	IP, ICMP	路由不可达、TTL 超时、IP 冲突
链路层	以太网, Wi-Fi, LoRa	信号弱、重传率高、信道干扰

我记得有一次排查一个 NB-IoT 设备，设备上报总超时。抓包一看，TCP 三次握手都完成了，但服务器端一直没发数据。最后发现是运营商核心网侧把设备的 APN 配错了。网络层通了，应用层却卡在路由策略上。

1.3 MQTT 协议核心概念

MQTT 是物联网的事实标准。说白了，它就是为「低带宽、高延迟、不可靠网络」设计的。

发布/订阅模型

传统 HTTP 是「请求-响应」，客户端主动问，服务器被动答。MQTT 反过来——设备把数据扔到 Broker 上，谁订阅谁拿。设备不用关心谁在消费数据。

我在项目中遇到过一个问题：设备端频繁重连，每次重连都重新订阅 Topic，导致 Broker 端订阅表爆炸。嗯，后来加了持久化订阅才解决。

主题（Topic）

Topic 是 MQTT 的路由标签。它不像 IP 地址，更像文件路径：

设备上报：  sensor/temperature/room1
设备控制：  actuator/switch/room1/light
设备状态：  device/status/gateway01

Topic 支持通配符：

• + 匹配单级：sensor/+/room1 匹配所有 room1 的传感器
• # 匹配多级：sensor/# 匹配所有传感器数据

QoS（服务质量）

QoS 是 MQTT 最容易被误解的概念。很多人以为 QoS 越高越安全，其实不是。

QoS 等级	含义	发送次数	适用场景
0	最多发一次，不确认	1 次	传感器高频上报，丢几个无所谓
1	至少发一次，有确认	≥1 次	控制指令，允许重复但不能丢
2	恰好发一次，四次握手	2 次（严格）	计费、告警，不能重复也不能丢

你想想看，如果所有 Topic 都用 QoS 2，Broker 压力会翻好几倍。我建议：上报数据用 QoS 0，控制指令用 QoS 1，只有关键业务才用 QoS 2。