代理层延迟怎么量化
反向代理与网关每多一层，就多一次排队与转发开销，可能还多一次到上游的连接建立。量化方法很直接：把直连与经代理的同一请求时间线并排比较，差值就是代理段的成本。前提是后端与缓存状态保持一致，否则变量混杂，算出来的差值没有解释力。
基本信息
| 关键指标 | TTFB（首字节时间），P50 与 P95 一起看 |
|---|---|
| 对照方法 | 直连与经代理两组，固定后端与缓存状态 |
| 观察位置 | 代理侧抓包能看到它到上游的连接耗时 |
| 常见放大因素 | 代理排队、连接池未命中、响应缓冲 |
典型使用场景
- 量化新增一层网关带来的延迟成本
- 排查代理侧排队导致的 TTFB 长尾
- 判断代理连接池是否命中，未命中会多一次上游握手
- 对比不同代理配置（缓冲开关、超时参数）的差异
- 为架构评审提供可复核的数据，而不是凭感觉判断
两组时间线对比
两组时间线对比
tshark -r direct.pcap -Y "http" -T fields -e http.request.uri -e frame.time_relative | head
# 直连基线：请求发出到首个响应数据帧的时间差就是 TTFB
tshark -r proxied.pcap -Y "http" -T fields -e http.request.uri -e frame.time_relative | head
# 同一 URI 对比两组数据，差值即代理段引入的开销
# 代理侧同时抓包：能直接看到它向上游发起的连接与握手耗时TTFB 对照表
| 场景 | P50 | P95 | 说明 |
|---|---|---|---|
| 直连后端 | 基线 | 基线 | 作为参照 |
| 经一层代理 | 略升 | 明显上升 | 代理排队主要影响尾部 |
| 代理连接池未命中 | 明显上升 | 明显上升 | 多一次上游建连与握手 |
| 启用响应缓冲 | 视策略而定 | 长尾更明显 | 缓冲会改变可见时序 |
代理的连接池命中时成本很低，未命中时多一次上游握手。做对照实验要记录连接池状态，否则同一套配置下两次测量的差异会很大，结论也不可复现。
代理开启响应缓冲后，可能先收完整个响应再转发给客户端，抓包看到的 TTFB 与用户实际感受不一致。分析前先确认代理工作模式，再解释数据。
排查顺序
- 先固定后端、缓存与并发条件，保证两组数据可比
- 分别统计直连与经代理的 TTFB 分位数，关注 P95 而不是只看均值
- 在代理侧抓包，确认其到上游的建连与等待各占多少
- 检查代理工作模式与缓冲、超时、连接池配置是否与预期一致
- 结论要区分「代理本身开销」与「上游变慢」，两者混在一张表里会误导优化方向