DNS 段为什么要单独算
一次页面访问的耗时至少由四段组成：DNS 解析、TCP 建连、TLS 握手、首字节到达。DNS 段的定义很干净，就是「查询发出到应答收到」的时间差。把它和建连时间混在一起算，归因就会指向错误的层。缓存命中时这段趋近于零，未命中走递归解析则常是几十到几百毫秒，差别很大。
基本信息
| 关键字段 | dns.id、dns.flags.response、dns.qry.name、frame.time_relative |
|---|---|
| 配对方式 | 按事务 ID 与查询名配对请求与响应 |
| 单位提醒 | 注意 ms 与 s 的换算，报表口径统一 |
| 影响因素 | 本地缓存、递归解析器性能、CDN 就近调度 |
典型使用场景
- 首屏变慢时区分解析、连接、传输各占多少时间
- 验证 DNS 缓存是否生效：同一域名复访应接近零
- 横向对比不同解析器的响应速度
- 排查解析器重试带来的额外等待
- 为「域名解析慢」的投诉提供分段证据
配对测量
配对测量
tshark -r a.pcap -Y "dns" -T fields -e dns.id -e dns.flags.response -e dns.qry.name -e frame.time_relative | head -20
# 同一 dns.id 的请求与响应时间差即该次解析耗时
tshark -r a.pcap -Y "dns.flags.response==0" -T fields -e dns.qry.name | sort | uniq -c | sort -rn | head
# 统计查询次数与重复查询，识别缓存未命中的热点域名访问耗时分段
| 阶段 | 起止界定 | 异常时的指向 |
|---|---|---|
| DNS 解析 | 查询发出到应答收到 | 缓存与解析器配置问题 |
| TCP 建连 | SYN 到 SYN-ACK | 网络往返或丢包 |
| TLS 握手 | ClientHello 到 Finished | 往返次数多或证书链问题 |
| 首字节 | 请求发出到首个响应字节 | 服务端处理慢 |
| 传输 | 首字节到完成 | 带宽、丢包与并发影响 |
缓存命中时解析段接近零。报表必须区分首访与复访，否则同一域名多次访问中一次未命中，平均值就会被拉高，让人误判成解析普遍很慢。
解析器的重试与补全会让一个域名出现多条查询记录。逐条看别只看第一条，否则会把重试耗时漏掉，低估真实的解析等待。
排查顺序
- 先按域名分组，统计每个域名的查询次数与响应时间分布
- 区分首次查询与重复查询，确认缓存策略是否生效
- 检查是否出现超时后重试，重试往往意味着解析器或网络有问题
- 确认解析目标：本地解析器、公共解析器还是自建服务，路径不同结论不同
- 与其他阶段的耗时并列成表，给出各段占比再提优化建议