curl -fsSL https://raw.githubusercontent.com/offzen/TcpQCanvas/main/run -o TcpQCanvas.sh && bash TcpQCanvas.sh -v4
这两张图几乎是在同一时段（2026-07-21 02:39 vs 02:59）测出的结果，对比起来非常生动。
NQ（NetQuality） 与 Canvas 在丢包检测的原理、粒度以及“真假丢包”的判定机制上有着本质的区别：
核心差异对比
| 维度 | 图 1：NQ 脚本 (NetQuality) | 图 2：Canvas 脚本 (TcpQuality Canvas) |
|---|---|---|
| 测试定位 | 一次性全能快照（三网+路由+测速+互连） | 长效/动态持续滚动监控（L4 探测 + L7 交叉核实） |
| 丢包/重传触发机制 | TCP 大包 (Payload) / 测速数据流重传 | 标准 TCP 握手 (nc/socket) 多轮小包探测 |
| 丢包统计粒度 | 单次发包/单次测速的重传计数（快照式） | 滑动窗口轮次累计（如 26 次探测中丢包的百分比） |
| 丢包真伪校验 | 无二次校验（阻断或丢包直接显示 0 或 ERROR） |
L7 HTTPing 交叉复盘（区分“墙拦截”与“真实链路丢包”） |
丢包检测的具体差异解析
1. 探测 Payload 的不同：TCP 大包 vs 标准 TCP 握手
-
NQ 的大包检测（图 1 - 第四部分）：
-
NQ 采用的是 TCP 大包延迟/丢包测试（Step=80ms）。
-
缺点：网络中间节点（如运营商 QoS 策略、防火墙）对 TCP 大包极度敏感。大包更容易触发分片丢弃、限速或重传，因此 NQ 测出来的丢包/重传通常反映的是高负载/大包分片下的极端链路表现。
-
现象：在 NQ 的图 1 中，天津联通、广西联通直接显示为红色的
0（无法建连或大包被完全阻断），深圳移动测速甚至直接爆掉显示ERROR。
-
-
Canvas 的标准握手（图 2 - 上半部分）：
-
Canvas 采用的是标准 TCP 建连（Socket /
nc），不带或仅带少量协商 Payload，模拟最真实的 TCP 握手过程。 -
优势：剔除了大包分片和 QoS 恶意丢包的影响。图中 89 个节点显示 0.00% 零丢包，证明在正常握手尺寸下，大部分链路非常平稳。
-
2. 面对“真实丢包”时的诊断深度差异
对于真的存在丢包的节点（比如两图测试中都表现不佳的 吉林联通 4837），两者的处理逻辑截然不同：
[ NQ 逻辑 ] : 发送大包/测速 -> 发现异常/重传高 -> 给出单次延时/重传数（无法判断是墙还是线路烂）
[ Canvas 逻辑 ]: L4 频繁探测(26次) -> 发现 57.69% 丢包 -> 触发 L7 HTTPing 二次复盘 -> 确认 L7 仅 1/2 通且延时飙升至 355ms
-> 准确输出结论：⚠️ 质差（双层链路严重不稳定/抖动丢包）
示例分析：吉林联通 (4837)
-
NQ（图 1）：吉林联通延迟显示为 203ms，但单凭快照很难看出它此刻是否在剧烈抖动。
-
Canvas（图 2）：
-
L4 经过 26 次持续滚动轮次监测，精准算出丢包率高达 57.69%。
-
底部 L7 深度诊断 立即跟进复盘：HTTPing 两次请求只通了 1 次 (1/2 通)，且平均 RTT 膨胀到了 355ms。
-
最终结论：成功排除了“WAF 防火墙误报”，定性为真实的“双层链路严重不稳定/抖动丢包”。
-
总结
-
NQ (NetQuality) 就像是给服务器做全面体检（抽血+CT），它的丢包/重传数据偏向于反映 TCP 大包吞吐、极限测速和路由盲区，适合快速看个大概，但对丢包原因无法深究。
-
Canvas 则像是一个心电图监护仪，通过小包高频采样 + L7 深度复盘，专门用来精准捕捉链路真实的丢包率，并彻底解决“到底是防火墙拦截，还是线路真的烂了”这一行业难题。