QNET 与专业抓包工具的关系：互补而非替代
「有了 QNET 还要 Charles 吗」「它能不能替代 Wireshark」——这类问题的答案都是否定的。QNET 的抓包是为弱网测试配套的取证能力，不是全功能抓包平台；正确姿势是把它们组合起来用。
能力对照
| 能力 | QNET | Charles/Fiddler | Wireshark |
|---|---|---|---|
| 弱网注入 | 核心能力 | HTTP 代理层有限支持 | 无 |
| 免 ROOT/越狱抓包 | 支持（VPN 层） | 需配代理与证书 | 桌面侧监听 |
| 抓取 UDP/ICMP | 支持 | 基本不支持 | 支持 |
| 协议解析深度 | 导出标准 pcap | HTTP(S) 解析极强 | 全协议字段级解析 |
| 改包/断点调试 | 无 | 支持 | 有限 |
| 与被测设备的关系 | 同机运行 | 需代理到 PC | PC 侧分析文件 |
三种工具的实际分工
- 制造问题：QNET 注入损伤——它做的是别人做不了的「网络变差」；
- 应用层看流量：接口内容、加密前的请求参数、mock 调试，交给 Charles/Fiddler；
- 链路层定位：重传、握手、时序——QNET 抓出来的 pcap 交给 Wireshark 深挖，见pcap 文件与 Wireshark 分析。
一个常见的高效组合
同一次弱网会话里：QNET 开抓包 + 测试报告，跑完用 csv 先做统计结论（丢了多少、延迟多少），疑难点再开 pcap 深挖；接口行为层面的问题（超时阈值、重试次数）回 Charles 看业务报文。三段证据链各司其职。
QNET 抓包的已知边界
- 它记录的是经过 VPN 通道的包，观察视角在设备本地，看不到服务器侧的路径细节；
- 深度解析能力就是「标准 pcap」，复杂协议的字段解读靠外部工具；
- 长会话文件大，不适合当常驻监控用——它跟着弱网会话走，见开启网络抓包。
一句话总结
QNET 负责「让问题发生并留下现场」，Charles/Wireshark 负责「解剖现场」。弱网测试流程里它们是上下游，不是竞品——完整工作流回顾见弱网用例设计清单。