设备总掉线却复现不了？话说回来，把弱网"造"出来：tcconfig 五种网络故障模拟实战

设备批量出货后客户反馈来了：设备经常掉线。

做物联网网站的都知道这种反馈有多难接。掉线的设备分布在各地，网络环境千差万别，你总不能扛着电脑去客户现场蹲着。老实说，而实验室里的网络好得过分——千兆内网、专线出口。设备挂一个月都稳如老狗，什么问题都复现不了。

排查陷入了死局：问题在弱网里弱网在千里外。其实，

我们的破局思路是：既然设备来不了弱网。就把弱网搬到设备面前，说起来，不需要买昂贵的网络损伤仪，Linux 自带的流量控制工具就能干——我们用 tcconfig在服务端网卡上注入网络损伤。把五种典型的弱网场景在机房里造了出来：延时、丢包、包重复、包损坏、包乱序。

这篇讲清楚两件事：怎么造。还有造出来之后看到了什么——有些实测结果，和教科书说的不一样。

一、测试环境：一行命令造出一种故障

说到环境很简单，

• 再看服务端，EMQX+ 一个内网 Web 服务
• 从验证工具来看，tcping+ MQTTX
• 损伤注入的观点是，tcconfig。直接打在服务端的 eth0 网卡上

flowchart LR
C -->|正常网络| TC
subgraph S
TC -->|延时/丢包/损坏/乱序| APP
end
style TC fill:#fff3cd,stroke:#d4a017

从关键点来看，损伤打在服务端网卡上，对客户端完全透明。客户端以为自己在和一个"网络很烂的服务器"通信——这正是设备在现场的视角。说起来，

五种场景的命令模式：

测完用 tcdel eth0 --all 一键清除。逐个场景说实测结果，主要在和预期不符的地方。

二、丢包：% + % = %，还有一次诡异的"假死"

设定值不等于实际值

设 % 丢包。tcping 实测丢包率在 %~% 之间波动——netem 的丢包是概率模型，不是严格的"每两个丢一个"。

更有意思的是叠加效应：入向、出向各设 % 丢包，直觉上以为还是 %。实测整体丢包率到了%. 道理不复杂：一个来回要穿过两道鬼门关，两个方向是独立事件。设 % 时实际可用率大约只有 × = %，加上波动，% 是合理读数。

MQTT 在丢包下的两个极端

轻度丢包时MQTT 客户端的重发机制会兜底：上报的消息有时秒到，有时延迟几秒到——表现为"能用，但抖".

• 创建 MQTT 连接，"连 X 次才成功 Y 次"
• 连上之后一开始发的消息都能收到
• "某一次发送失败后就再也收不到了"—翻 EMQX 的日志。broker 明明收到消息并重发了 Z 次客户端一条都没收到

sequenceDiagram
participant D as 设备
participant E as EMQX
Note over D,E: 双向 % 丢包
D->E这方面，连接尝试 ✗
从D->E来看，连接尝试 ✗
至于D->E，连接尝试 ✓
D->E的观点是，消息 ✓
D->E这方面，消息 ✓
从D->E来看，消息 ✗ 丢失
E->D的观点是，重发 ~ 次
Note over D: 全部丢失,一条未达
Note over D,E: 连&#;活着&，数据已死

This is classic "假在线": 网站显示在线，却没有数据更新。很多客户现场抱怨“在线却没有数据”，根源就在这里。

三、延时： 秒延时连接先死

The 延时 scenario behaves exactly as intuition predicts:

• If you inject a single‑direction delay of X ms,RTT grows by roughly X ms.
• If you inject X ms on both inbound and outbound directions,RTT grows by ~2·X ms – linear addition.
• The tcping tool reports this cleanly.
• The real surprise appears on MQTT side.
• If inbound delay reaches **Y seconds**,client’s CONNECT handshake starts failing dramatically. Message latency is secondary – handshake timeout is killer.
• This explains *** devices log “connection failed” in large numbers while server looks perfectly healthy.
• The first victim of a weak network is **not** payload,it’s ** connection establishment** .
• You must size your client‑side timeout based on *worst‑case* RTT rar than average RTT.

四、包损坏与包重复：一个太狠，一个太温柔

* 包损坏 : tcping receives no reply because checksum failures cause kernel to drop packets outright. On MQTT you see prolonged connection attempts and n a pattern similar to loss – after one failure everything keeps failing. In practice packet corruption at TCP layer just looks like a more aggressive loss.

* 包重复 : Neir tcping nor MQTTX shows any effect. The reason is that TCP already deduplicates based on sequence numbers,so duplicate packets never reach application layer. To test application‑level duplication you must generate duplicate messages at application level。not via network‑layer tools.

This yields an important methodology lesson: "Network damage tools only simulate network‑layer symptoms – higher‑layer bugs must be injected at ir own layer."

五、包乱序：抓到“后发先到”，逼出一个协议改动

The tricky part of reordering is that `` **must be used toger with ``**. Without an underlying delay re’s no space for packets to be reordered,so netem throws an error.

• `tcping` doesn’t notice reordering because each connection measurement is independent.
• `MQTTX` reveals a textbook scenario where messages arrive out of order – later published readings overwrite earlier ones because platform processes m strictly by arrival time.
• This “后发先到” problem forces us to change our protocol:
• Add a sequence number to every telemetry packet.
• The server discards any packet whose sequence number is less than or equal to latest stored value.

This simple rule prevents stale data from overwriting fresh data when reordering occurs. It would never have been discovered without actually reproducing weak‑network conditions.

sequenceDiagram
participant D as 设备
participant N as 网络
participant P as 网站
至于D->N，消息A
说到D->N，消息B
再看D->N，消息C
Note over N: A 被延迟
N->P的观点是，到达 B
从N->P来看，到达 C
N->P这方面，到达 A ← 老数据最终到!说起来，Note over P: 若按到达顺序覆盖，则旧值覆盖新值
If you’re dealing with chat messages this may only look odd。but for sensor readings it can become a safety incident.

六、有效/无效矩阵 




工具
延时
丢片​​​​​​​​​​​​​​​​​​​​​​​​​​​​​?�，?
��，?�，?‍，?，��?，‍?��，��?����，不过，��������?，?，?，?，?，?����，?，��������?，?，?，️?，?⚪，?️，?，?，�?，?，�?，?，?说起来，
❔❔?按理说，
❔?
❔?




tcping  
 有效    
 有效    
 无效    
 有效    
 无效   

MQTTX
 有效
 有效
 无效
 无效
 有效




用法建议的观点是。

使用 tcping 确认规则已经被 netem 正确写入，随后使用 MQTTX 检查业务层受影响程度。按理说，两者缺一不可，因为只有两层同时满足才能说明“规则生效且业务受影响”。

七 、三个教训  💡  🔧  🚀  🧭
🔎
⚙️
 🧱
✍️



.复现不了的问题,先把 环境造出来