ProxyPin HAR 性能分析 慢请求定位

HAR timings 字段含义

HAR 的 timings 对象是性能分析的核心：

"timings": {
  "blocked": 10,     // 排队等待时间（TCP 连接池满）
  "dns": 20,         // DNS 域名解析时间
  "connect": 30,     // TCP 三次握手时间
  "ssl": 40,         // TLS 握手时间（包含在 connect 里）
  "send": 5,         // 发送请求时间
  "wait": 100,       // TTFB：首字节到达时间
  "receive": 15,     // 接收响应体时间
  "time": 150        // 总耗时
}

总耗时 = blocked + dns + connect + send + wait + receive

各阶段慢意味着什么

在 ProxyPin 中找慢请求

方式一：请求列表排序

ProxyPin 请求列表支持按耗时排序，点击列头切换降序。

方式二：高级搜索

duration:>1000 AND method:GET

找出所有 GET 请求中耗时超过 1 秒的。

方式三：导出 HAR 后 Python 分析

import json

with open('traffic.har') as f:
    har = json.load(f)

entries = har['log']['entries']

# 找出各阶段最慢的 Top 10
for metric in ['dns', 'connect', 'wait', 'receive']:
    slowest = sorted(entries, key=lambda x: x['timings'].get(metric, 0), reverse=True)[:10]
    print(f'\n--- {metric} 最慢 Top 10 ---')
    for e in slowest:
        print(f"  {e['timings'].get(metric, 0):.0f}ms | {e['request']['url'][:80]}")

典型性能问题定位

场景一：App 首屏慢

HAR 导出后发现：

• dns 时间都很慢（域名解析 ~500ms）→ 考虑 HTTPDNS 或 App 内预解析
• wait 时间高（TTFB ~2s）→ 后端接口响应慢，需要后端优化
• receive 时间高（响应体 ~2MB 下载 ~3s）→ 响应体需要分页或压缩

场景二：大量 blocked 时间

blocked 占了总耗时的 30%+：

• 典型原因：HTTP/1.1 连接池满了，请求排队
• 解决：升级 HTTP/2（ProxyPin 设置中开启），多路复用减少连接数

场景三：TLS 握手慢

iOS/Android 首次启动 App 时 HTTPS 请求特别慢：

• 典型原因：证书链太长、TLS 1.2 握手需要多轮往返
• 解决：服务端升级 TLS 1.3（1-RTT 握手）、启用 OCSP Stapling

自动化性能守卫

在 CI/CD 中接入：

1. ProxyPin headless 抓包
2. 导出 HAR
3. 检查关键 API 的 TTFB 是否超标
4. 超标则构建失败提醒

这样性能回退能在提交代码时就被发现，而不是上线后用户反馈。