时间头能暴露什么
HTTP 响应里的 Date 头是服务端（或中间缓存节点）生成响应时的时间，格式为 GMT；Last-Modified 描述资源最后修改时间；Age 表示这份内容在缓存里已存在多久。把响应到达时刻与 Date 头相减，就能看出服务端时钟是否准。偏差达到分钟级以上，往往意味着时钟未同步，随之而来的缓存新鲜度判断错误、签名过期、令牌校验失败都会变得难以解释。
基本信息
| 抓包字段 | http.date 为响应头时间，http.last_modified 为资源修改时间，http.age 为缓存时长 |
|---|---|
| 比较方法 | 把抓包时间戳换算为 GMT 后与 Date 头逐秒比较 |
| 正常范围 | 秒级以内的差异属正常，受生成与传输耗时影响 |
| 判据 | 分钟级以上差异基本可判定一侧时钟未同步 |
| 可能来源 | 服务端时钟、中间缓存或代理节点时钟、抓包机自身时钟 |
| 相关时间头 | Age 与 Date 组合可反推缓存的存入时刻 |
典型使用场景
- 疑难排查：签名字符串校验偶发失败、令牌刚签发就报过期，先核对时间头
- 缓存异常：内容该更新却不更新，用 Date 与 Age 判断缓存节点的时间基准
- 集群一致性：多台后端返回的 Date 时间差明显，说明节点之间没有统一对时
- 代理核查：确认响应头里的时间由谁生成，是源站还是中间节点改写的
- 审计留痕：用响应时间头与抓包时间互相印证，判断日志与流量是否同一时刻
查看与核对
查看与核对
# 列出响应头时间与抓包时间, 便于人工比对
tshark -r a.pcap -Y 'http.response' -T fields -e frame.number -e frame.time -e http.date | head -20
# 换算脚本里建议统一用 epoch 计数比较, 避免时区与格式歧义
tshark -r a.pcap -Y 'http.response' -T fields -e frame.time_epoch -e http.date
tshark -r a.pcap -Y 'http.age' -T fields -e frame.number -e http.date -e http.age现象与推断
| 现象 | 含义 | 下一步 |
|---|---|---|
| Date 明显早于抓包时间 | 生成响应的节点时钟偏慢, 或内容来自缓存 | 核对 Age 与缓存节点时间 |
| Date 明显晚于抓包时间 | 生成节点时钟偏快 | 先确认抓包机时钟可信再下结论 |
| Date 秒级偏差 | 正常范围 | 无需处理 |
| 多节点 Date 不一致 | 集群未统一对时 | 推动节点启用时钟同步 |
| Age 比预期大很多 | 缓存命中但新鲜度判断依赖错时钟 | 检查缓存节点的对时状态 |
抓包机自身的时钟也必须可信：如果抓包机时间偏了十分钟，比对结果会把问题错误地指向服务端。排查时间类问题前，先确认分析主机与采集主机都已同步时钟。
经过缓存或代理的响应，Date 头可能是中间节点生成的，不能直接代表源站时间；结合响应头里的其他标识与拓扑判断这份时间由谁写入。