头体间隔是什么
响应头结束到响应体首块到达之间的时间差，反映服务端生成首块数据所花的时间。判读逻辑很直接：间隔大而后续传输很快，说明时间花在应用侧，例如等待下游服务、查询数据库、模板渲染；间隔小而后续传输慢，说明瓶颈在网络或窗口。这个方法的价值在于把“慢”拆成两段责任，避免把客户端侧的总耗时笼统地归给某一方。测量时以 HTTP 首行所在帧到首块实体帧的时间差为准，配合帧时间差排序能快速找出间隔偏大的响应。
基本信息
| 观察对象 | HTTP 响应首行到首块实体的时间差 |
|---|---|
| 判读方向 | 间隔大指向应用生成慢，间隔小指向传输问题 |
| 辅助字段 | tcp.time_delta、frame.time_delta |
| 对照基准 | 同接口在正常时段的间隔基线 |
| 干扰因素 | 压缩、分块传输、首字节与完整内容的区别 |
典型使用场景
- 应用慢定位：动态接口首字节迟迟不来，需要区分应用与网络各自占比
- 首屏优化：找出首字节生成慢的接口优先处理
- 与传输慢区分：间隔小但传输时间长时，方向应转向窗口与丢包
- 基线对比：与正常时段同一接口比较，判断性能是否劣化
- 下游依赖定位：确认应用慢时是否在等待数据库或第三方接口
观察方法
观察方法
http.response && http.content_length > 0 # 筛出带实体的响应
Follow 到 HTTP 流后比较头部帧与首块数据帧的间隔
tcp.time_delta > 0.5 # 阈值按基线调整
# 记录绝对值，并与同接口正常时段对比两段责任划分
| 特征 | 指向 | 下一步 |
|---|---|---|
| 头体间隔大、体传输快 | 应用生成慢 | 查应用日志与下游依赖耗时 |
| 头体间隔小、体传输慢 | 网络或接收窗口受限 | 查重传与窗口是否贴顶 |
| 两段都大 | 应用与网络同时有问题 | 先定位占比更大的一段 |
| 间隔忽大忽小 | 抖动或排队 | 按时间切片看分布而非均值 |
压缩传输下“首块实体到达”的时间与用户可见内容的时间并不等同，讨论优化收益时要把这两个口径分开说。
大响应分多段发送时，用首段到达时间对齐用户感知，用末段时间计算总下载耗时，两个口径分别标注，避免同一组数据得出互相矛盾的结论。