页面加载中的 DNS 放大
一个页面往往不只依赖一个域名：主站、静态资源域名、接口域名、第三方脚本与统计服务各自需要解析，叠加起来可能是几十个查询。这些查询集中在页面加载的起始阶段发出，如果解析阶段整体偏慢，后面的资源下载就会被一并推后，形成「什么都没做就很慢」的观感。抓包时按页面加载的时间窗把域名查询聚集起来，逐个统计耗时，就能量化解析阶段占了多少时间。
基本信息
| 适用平台 | 客户端侧抓包，Wireshark 或命令行统计均可 |
|---|---|
| 观察方式 | 按时间窗过滤域名查询，统计数量与逐个耗时 |
| 推荐字段 | frame.time_relative、dns.qry.name、dns.time |
| 对比口径 | 首次访问与再次访问的查询数量差异反映缓存效果 |
典型使用场景
- 首屏慢，确认解析阶段在总耗时中的占比
- 评估缓存预热或预解析策略的实际收益
- 识别页面依赖的第三方域名数量，为治理提供依据
- 对比内网与公网环境的解析耗时差异
- 验证更换解析服务后页面加载是否改善
- 为浏览器侧的预解析配置提供数据支撑
聚集与统计
聚集与统计
tshark -r page.pcap -Y 'dns.flags.response == 0' -T fields \
-e frame.time_relative -e dns.qry.name # 按时间列出所有查询
# 再按域名聚合响应耗时，找出最慢的几个
tshark -r page.pcap -Y 'dns.flags.response == 1 && dns.time > 0.2' \
-T fields -e dns.qry.name -e dns.time
# 对比首次访问与再次访问的查询数量，评估缓存收益统计项逐项读法
| 统计项 | 含义 | 判读方向 |
|---|---|---|
| 查询总数 | 页面依赖的域名规模 | 数量大说明存在域名发散问题 |
| 最慢的几个查询 | 拖累整体解析的短板 | 优先优化或改为预解析 |
| 查询时间分布 | 集中在开头还是分散 | 集中在开头说明阻塞首屏 |
| 两次访问差异 | 缓存效果 | 差异小说明缓存未起作用 |
预取与预连接会让部分查询出现在用户操作之前，统计归属时要按时间线判断，不能全部算作用户点击触发。
第二次访问仍然产生大量查询，说明缓存策略或存活时间需要重新评估，这是优化收益最直接的检查点。