抓包、分析、复盘：一站式解决物联网断联难题

💽 前言

在物联网场景中，设备因 IOT 模块资源受限、天线设计不佳、与路由器距离较远或受限于复杂的使用环境，常常面临不稳定的网络状况。断联问题更是绕不开的核心挑战之一。

那么，作为服务端开发或运维人员，如何从后台日志和数据链路出发，高效定位物联网设备的断联原因呢？

本文将结合实际案例，从网络结构、日志分析到抓包手段，分享排查思路。

⏰ 常见的物联网设备网络连接架构

通常，物联网设备通过如下链路与后台 MQTT 服务器建立连接：

设备 IOT 模块通过手机配网接入 Wi-Fi 路由器；

路由器连接外网（公网或企业内网）；

网络流量经过反向代理（如 Nginx）或云负载均衡；

最终到达 MQTT Broker（MQTT服务器）。

通过上图可以看出，设备与服务器之间的链路较长，涉及多个网络节点。因此，任一环节出现问题，都可能导致设备断联。这也对排查人员的网络知识、协议理解及综合分析能力提出了较高要求。

⏳ 常见日志排查场景

1. 正常断联或协议层面的断联

以 EMQX 为例，若设备主动断开或因协议原因断联，服务端日志通常会有详细记录。例如：

可以参考 MQTT 3.1.1 和 MQTT 5.0 的标准文档，对比 reason 字段判断断联是否为正常行为或由协议触发。

2. 相同 ClientID 导致互踢

根据 MQTT 标准，同一时间同一个 ClientID 只能维持一个连接。当新的客户端使用相同的 ClientID 连接时，服务器会强制断开旧连接。

【v3.1.1】1. If the ClientId represents a Client already connected to the Server then the Server MUST disconnect the existing Client [MQTT-3.1.4-2].

【v5.0】1. If the ClientID represents a Client already connected to the Server, the Server sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) as described in section 4.13 and MUST close the Network Connection of the existing Client [MQTT-3.1.4-3]. If the existing Client has a Will Message, that Will Message is published as described in section 3.1.2.5.

如果设备配置或烧录错误，导致出现不同设备使用了相同的 ClientID，就可能导致频繁掉线。

在 EMQX 中，可以通过日志系统追踪上下线事件，核对 IP 地址、协议版本等信息，判断是否为同一设备不断重连造成互踢。

3. 服务端响应延迟导致客户端重连

当设备未在超时时间内收到服务器返回的 CONNACK、SUBACK 等关键响应包时，会触发重连机制。

此时，需要重点检查 MQTT Broker 的日志，关注连接请求与响应报文之间的时间差距，判断是否存在处理瓶颈或网络延迟。

📡 深层排查：抓包分析

如果基础日志分析未能明确断联原因，抓包分析底层 TCP 通信是进一步定位问题的有效手段。

以下按链路顺序介绍几种常见抓包方式和工具：

A. 抓取设备与路由器间的 Wi-Fi 空口包

Windows：需外置网卡并开启混杂模式。

Mac：内置网卡支持混杂模式，可直接抓包。

Wireshark 是常用的抓包工具，抓取 Wi-Fi 报文时需配置解密参数

参考 How to Decrypt 802.11。

B、抓取WiFi路由器上的TCP报文

支持 OpenWRT 等系统的路由器可通过 SSH 访问并使用 tcpdump 抓包：

tcpdump 命令的一些基本使用

替代方案：用 Windows 电脑开启 Wi-Fi 热点，让设备连接，并在电脑端用 Wireshark 抓包。比较适合排除路由器问题场景。

C. 公司内网设备抓包

可通过以下方式捕获完整流量：

流量镜像交换机

有线抓包工具

此类方法适合分析网络设备是否存在 TCP 阻断或丢包，TTL 跳数变化也是常用的诊断手段。

D / E. 服务端抓包

直接在服务器上用 tcpdump 抓包分析，方法同上，不再赘述。

📸 分析TCP报文

抓取到空口包、路由器或服务器上的 TCP 报文后，接下来的关键步骤就是使用 Wireshark 进行深入分析。Wireshark 是网络协议分析的利器，能够帮助我们精准还原数据交互过程、捕捉异常信号，从而定位问题根源。

不过，在正式分析前，建议补充相关的基础理论知识，做到知其然更知其所以然。推荐以下经典资料：

📘 《TCP/IP 详解》—— 深入理解 TCP 协议的握手、重传、窗口机制、拥塞控制等核心概念。

📘 MQTT Version 3.1.1

📘 MQTT Version 5.0

在海量抓包数据中高效提取有价值信息，是排查成功的关键。以下是实战中经常使用的 Wireshark 过滤技巧和关注点：

1️⃣ 过滤某个时间段内的报文

当已知设备发生异常的具体时间点时，利用时间范围过滤可以显著缩小分析范围，仅保留关键时间段的报文，方便比对异常前后的网络状态变化。

✅ 示例：

frame.time >= "Feb 26, 2025 11:34:18" and frame.time <= "Feb 26, 2025 11:34:19"

👉 使用场景：

精准还原设备掉线前后的网络行为；

分析短时突发网络波动、重连等异常。

2️⃣ 过滤 TCP-RST报文

TCP RST 报文意味着连接被强制断开，在排查掉线、断联等问题时极其关键。

✅ 示例：

tcp.flags.reset == 1

此过滤器用于查找连接被重置的所有记录，帮助我们判断是否由于异常 TCP 关闭导致断联。

👉 案例参考： 在之前案例中中，通过过滤 TCP-RST 报文，确认了在断联瞬间有大量 RST 包，进一步指向了服务端主动断开或中间网络设备异常重置连接的可能性。

3️⃣ 过滤指定 IP 的全部流量

用于聚焦单台设备的网络行为分析，快速提取指定设备的全部进出流量，排除无关数据干扰。

✅ 示例：

ip.addr == 192.168.0.100

使用场景：

针对单个设备分析上下行数据完整性；

核查特定设备的连接、断开、订阅等操作流。

4️⃣ 分析 TCP 或 SSL 握手包

在连接建立阶段，TCP 三次握手和 SSL/TLS 握手过程的完整性至关重要。特别是在启用加密通信的场景下，若 SSL 握手失败，通常可以在相关握手包中找到具体原因，如证书错误、协议不匹配等。

✅ 重点关注：

TCP：SYN、SYN-ACK、ACK 报文序列是否完整；

SSL：Client Hello、Server Hello 及证书交换是否成功。

👉 使用场景：

诊断因 SSL 证书问题导致的 MQTT 连接失败；

检查服务端或客户端配置是否正确匹配。

5️⃣ 关注断连前的关键报文

在出现异常断联的场景中，TCP 连接断开前的最后几帧报文往往含有关键线索，比如断开请求的发起方、重传次数、窗口大小变化等。

重点关注内容：

断联发起方：查看 FIN、RST 报文源头；

TTL 值变化：判断报文是否被中间网络设备篡改或阻断；

源 MAC 地址：核实报文是否经过异常设备或存在 ARP 欺骗。

📌 TTL 小科普： TTL（Time To Live）用于限制数据包在网络中的存活时间，每经过一台路由设备，TTL 减 1，直到为 0 被丢弃。在同一网络链路中，正常情况下，同一 TCP 会话的 TTL 值应基本一致。若发现 TTL 值忽然降低，可能存在转发路径变化或中间设备干预。

🔋 总结归纳

排查物联网设备的断联问题，是一项综合性极强的工作，既需要理解复杂的业务场景，又要熟练掌握底层网络协议（如 TCP）、消息传输协议（如 MQTT），以及抓包、日志分析等常用排障技能。

实际工作中，断联问题往往涉及多个因素交织：可能是网络链路不稳定，可能是协议配置异常，甚至是设备硬件或固件缺陷。因此，面对复杂环境下的断联问题，排查人员不仅要善于分析日志中的蛛丝马迹，还要敢于借助抓包等工具深入数据层，逐步定位故障源头。

更重要的是，一旦熟练掌握这套方法论，不仅仅是在物联网场景能大显身手。无论是移动 App 客户端频繁掉线、WebSocket 长连接不稳定，还是常见的 HTTP 请求超时、丢包等问题，背后的原理高度相似，排查逻辑和工具使用也基本通用。可以说，物联网断联问题的排查能力，是网络类问题诊断中的“通用技能”。

此外，掌握链路拓扑梳理、协议交互分析和端到端监控这些能力后，还能帮助我们反向优化系统设计，比如：