帧间耗时列
tcp.time_delta 是 Wireshark 为同一条 TCP 流计算的帧间隔，即当前帧与本流上一帧的时间差。把它添加成一列并按数值排序，「卡在哪一段」立刻呈现：某个请求之后长时间没有数据，那一行的间隔值会格外大。它只对有前序帧的报文取值，是 TCP 流专项分析中效率最高的手段之一。
基本信息
| 适用平台 | Wireshark 3.x / 4.x（tcp.time_delta 字段） |
|---|---|
| 添加方式 | 选中 TCP 详情的 Timestamps 分组 → 右键字段 → Apply as Column |
| 取值前提 | 同一 tcp.stream 内存在更早的帧 |
| 排序技巧 | 点击列头降序，耗时最大的帧排到最前 |
典型使用场景
- 定位响应空白期：请求已发出却迟迟无响应，看该帧相对上一帧的间隔
- 排序找出异常帧：按间隔降序排，前几行往往就是问题所在
- 观察周期性任务：同一连接上定时请求的间隔是否规律
- 对比不同客户端：同一接口在不同客户端上的帧间隔差异
- 与异常标注交叉验证：结合 tcp.analysis 的标记行共同判断
操作路径
操作路径
# 选中 TCP 详情 → Timestamps 分组 → 找到 time_delta 字段
# 右键 → Apply as Column，列名可改为 delta
tcp.time_delta > 0.5 # 筛出帧间隔超过 500 毫秒的包
# 点击该列列头降序，直接看到耗时最大的帧间隔读法
| 现象 | 可能原因 | 下一步 |
|---|---|---|
| 请求行之后间隔大 | 服务端处理耗时或网络往返 | 对照服务端侧抓包或应用日志 |
| 数据帧间隔规律递增 | 发送端节流或受窗口限制 | 查看 Window Full 与拥塞标记 |
| 响应后长时间无帧 | 应用未继续发送，或连接已断 | 结合 RST/FIN 与两侧日志 |
| 每包间隔都很小 | 链路顺畅 | 关注吞吐而非单帧间隔 |
time_delta 只在已有前序帧的流上有值，每条流的首个包显示为空或破折号，这不代表异常；做统计时也不要把它按零处理，否则平均值会被拉低。
该字段按 tcp.stream 计算，同一五元组在抓包期间被复用成两条连接时会拆成两个流，跨流之间的间隔不会被计入，判断「连接是否被重建」时要结合 SYN 一起看。