在一次版本更新后,我们的后端监控发现 iOS 端某接口 QPS 突然飙升数倍,甚至超过安卓端。没有异常崩溃、也没有大规模新增用户,唯一现象是服务端同一用户会在一分钟内多次重复请求该接口。
这是最难排查的异常:既不像崩溃能看到日志堆栈,也没有用户主观反馈问题,只有冷冰冰的接口流量激增数据。我们依靠抓包和流量复现,完整地还原了问题触发链。
问题接口为首页刷新数据接口,按逻辑只需每次进入首页请求一次。但后端日志显示同一用户在短时间内重复调用同一接口,每次请求参数完全相同。
分析团队初步怀疑:
为了还原真实行为链,我们将问题拆解为四步:
| 工具 | 使用目标 | 阶段 |
| ----------- | ------------------------------------ | ------------ |
| Charles | 抓取桌面端正常请求行为,建立对照基线 | 初期验证 |
| Sniffmaster | 捕获 iOS 真机请求频率和间隔 | 关键行为还原 |
| mitmproxy | 构造不稳定网络,观察自动重发是否触发 | 条件模拟 |
| Wireshark | 分析 TCP 层是否出现丢包/重传 | 网络层排查 |
| Postman | 重放抓包请求,验证服务端行为 | 结论确认 |
在 Electron 客户端上通过 Charles 抓包:
桌面端没有问题,锁定问题只在 iOS 端。
连接 iPhone,通过 Sniffmaster 抓包进入首页后的真实行为,抓到如下情况:
这一步确认了: 重复请求确实是客户端行为,而非网络问题。
为了排除网络原因导致重试,我们通过 mitmproxy 编写脚本,将响应延迟 3 秒:
python
def response(flow):
if "/home/refresh" in flow.request.path:
import time
time.sleep(3)
结果 App 依旧在 5 秒后发出下一次请求,无论网络是否稳定。这表明重复请求与网络状态无关,而是 App 内部定时触发。
通过 Wireshark 抓包 iPhone 的流量,检查是否存在 TCP 层意外重传:
用 Sniffmaster 抓到的请求体在 Postman 中多次重放,确认后端对相同内容的请求并未合并或去重,确实每次都完整处理。也就是说, 后端并未做幂等控制。
结合抓包结果可确定:
根因是一次优化首页“数据实时性”的改动,将自动刷新频率硬编码为 5 秒,但未结合页面离开或进入状态进行控制。
| 工具 | 作用 |
| ----------- | --------------------------- |
| Charles | 验证正常基线请求频率 |
| Sniffmaster | 精确还原 iOS 请求频率与行为 |
| mitmproxy | 验证请求是否受网络影响 |
| Wireshark | 确认是否有 TCP 层异常 |
| Postman | 验证后端是否合并重复请求 |
这套组合让我们排除掉“网络问题”“后端异常”等干扰,将问题准确定位到 App 行为逻辑,并快速制定修复方案。
流量异常激增不一定是外部攻击或后端故障,很多时候只是客户端行为的非预期后果。iOS 平台抓包更要依赖物理连接型工具(如 Sniffmaster)配合其他工具,让你清楚每次请求的来源、规律和触发条件。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70044672/viewspace-3089480/ ,如需转载,请注明出处,否则将追究法律责任。