观察 HTTP 响应耗时
http.time 字段给出请求到响应之间的时间差，省去手工相减时间戳的麻烦。筛出耗时超过阈值的请求，再叠加路径条件，就能快速找出慢接口。它基于请求行与响应首行的配对计算，因此同一条持久连接上的多次请求可以分别计量。
基本信息
| 适用平台 | Wireshark 显示过滤器（http.time 字段） |
|---|---|
| 过滤语法 | http.time > 1（单位为秒） |
| 测量范围 | 请求行到响应首行之间的时间差 |
| 前提条件 | 明文 HTTP，或加密流量已完成解密 |
典型使用场景
- 找慢接口：按耗时阈值筛出需要重点关注的请求
- 按路径收窄：叠加路径条件，只看某个业务接口
- 对比状态码：把慢请求与响应状态放在一起看
- 验证优化效果：改动前后对比同一接口的耗时
- 持久连接分析：同一连接上的多次请求可以分别计量
常用示例
常用示例
http.time > 1 # 超过 1 秒的请求
http.time > 2 && http.request.uri contains "/api" # 指定路径下的慢请求
http.time && http.response.code == 200 # 成功响应里的耗时样本耗时归属
| 现象 | 偏向原因 | 下一步 |
|---|---|---|
| 直到响应首行都很慢 | 服务端处理慢 | 看服务端日志与依赖 |
| 首行后正文传输慢 | 带宽或窗口受限 | 看窗口填充与重传 |
| 错误响应且耗时长 | 错误处理路径慢 | 看错误日志与超时配置 |
| 整体都慢 | 链路往返或前置阶段 | 先看握手与解析耗时 |
加密流量必须先解密才能使用这个字段。没有配置密钥日志时，只能回到传输层看握手与数据传输的耗时，不能据此判断应用慢。
这个耗时从抓包点起算，包含网络往返。要把服务端处理时间单独拆出来，仍然需要服务端侧抓包或应用日志配合。
响应首行到达之后，正文的传输时间不计入该字段。大响应的整体耗时需要结合末字节时间一起评估，单看这个值会低估。