DoT/DoH 性能 — 给 DNS 加密之后网页变快还是变慢

是什么

这篇论文做了一件事：把传统 DNS（Do53）、DNS-over-TLS（DoT）、DNS-over-HTTPS（DoH）三种协议放进真实网络里测一遍，看到底加密后网页加载会慢多少。

日常类比：你点外卖前要查餐厅地址。

Do53（传统）：你大喊”川菜馆在哪”，全街都听得到
DoT：你和地址簿管理员先握个暗号，再小声问，旁人只看到两人在嘀咕
DoH：你把这次问询塞进一封普通邮件里寄出去，连”在问地址”都看不出来

加密让旁人听不到你在查什么，但加密本身要花时间——这篇论文测的就是这笔账划不划算。

为什么重要

不读这篇就回答不了几个真实工程问题：

公司内部要不要把 DNS 全切到 DoH，会不会拖慢首页打开
浏览器（Firefox、Chrome）默认开 DoH 是不是合理
移动端弱网下应该选哪种 DNS
DoH 比 DoT 慢这件事是协议本身问题，还是工程问题

加密 DNS 是 2018 年后的全网趋势，但绝大多数推动它的人讲的是隐私故事，没人测真实代价。这篇论文是少数把代价数字化的实证工作。

核心要点

论文的实验拆成三层，每层结论不一样：

单次查询响应时间：DoT/DoH 普遍比 Do53 慢，因为多了 TLS 握手。一次握手 1～2 个 RTT，对一次”查 IP”这种几十 bytes 的小请求是巨大开销。
页面加载时间（PLT）：反直觉——DoT/DoH 有时反而更快。原因是浏览器加载一个网页要查几十个域名，TLS 连接可以复用，第一次握手后续几十次查询都共用一个加密通道，摊销下来比 Do53 每次单独发包还快。
网络变差时：低带宽 / 高丢包 / 高延迟下 Do53 反超。加密通道一旦丢包就要重传整个 TLS 段，Do53 的 UDP 单包丢了再发一个就行。

另一个独立结论：DoH 失败率显著高于 Do53 和 DoT。HTTP 层的复杂性（重定向、压缩、连接管理）让 DoH 在不稳网络下更容易卡住。

实践案例

案例 1：浏览器默认 DoH 的争议

Firefox 在 2019 年推 DoH 默认开启，业界吵翻天。这篇论文给出的数据支持：良好网络下 DoH 不慢甚至略快。但弱网用户会受损。Mozilla 后来给出妥协方案：检测到网络异常就回退到 Do53。

案例 2：为什么 DoT 比 DoH 表现好

维度	DoT	DoH
端口	853（专用）	443（混在 HTTPS 里）
协议层	TCP + TLS	TCP + TLS + HTTP/2
报文	二进制 DNS	HTTP 包 DNS
失败率	低	高

DoH 多了 HTTP 这层包装，在弱网下重传、流量控制、连接复用都更复杂。DoT 直接二进制 DNS 套 TLS，路径短就稳。

案例 3：连接复用是 DoT/DoH 唯一翻盘点

Do53:  查 a.com → UDP 包 → 答
       查 b.com → UDP 包 → 答         (每次独立)

DoT:   握手  → 查 a.com → 查 b.com → 查 c.com ...
       (一次握手摊给几十次查询)

工程含义：短连接（只查一次就关）的场景 DoT/DoH 永远输给 Do53。所以浏览器开 DoH 合理（要查几十个域名），但 dig 命令测一次根本看不出 DoT 优势。

案例 4：观测点位置很重要

论文用了 5 个观测点（北美、欧洲、亚洲、南美、大洋洲）。同一个解析器，不同观测点测出来的 PLT 差距很大——离 Cloudflare 边缘节点近的地方加密 DNS 几乎无感，远的地方延迟会被 TLS 握手放大。结论：做加密 DNS 决策时不能只看本机数据，必须考虑用户实际地理分布。

踩过的坑

不能用单次查询时间评判加密 DNS：很多 benchmark 只测”一次查询多少 ms”，得出”DoH 慢两倍”。论文证明这个指标会误导——真实世界看 PLT 才有意义。
DoH over HTTP/3 这篇没测：2020 年 HTTP/3 刚铺开，论文用的是 HTTP/2。后续工作（如 2022 年的若干测量）显示 HTTP/3 + DoH 能进一步缩小差距。
CDN 和 DNS 选址耦合：传统 DNS 解析器和你的 ISP 在一起，能就近返 IP。集中式 DoH（Cloudflare 1.1.1.1）会让 CDN “认错地理位置”，间接影响 PLT。这篇论文有触及但没量化。
失败率定义模糊：论文说”DoH 失败率高”，但失败的根因（DNS 服务器拒绝 / TLS 错误 / HTTP 错误）没拆开。后续工作做了更细的划分。

案例 5：实测数字大概长这样

论文在良好网络下测出的中位数（不同观测点和解析器有波动，这里取大致量级）：

响应时间：Do53 约 20-30 ms，DoT 约 50-70 ms，DoH 约 60-90 ms
页面加载时间（Alexa Top 1500 中位数）：三者差距在 ±5% 以内，DoT 偶尔最快
失败率：Do53 < 1%，DoT 约 1-2%，DoH 约 3-5%

弱网（带宽 1 Mbps、丢包 5%）下数字翻几倍，且 Do53 失败率上升最少。这告诉我们一个朴素事实：加密协议在好网络下的额外成本可以接受，在坏网络下被放大几倍。

适用 vs 不适用场景

这篇论文结论适用的场景：

评估浏览器/操作系统是否要默认启用 DoT/DoH
设计企业内部 DNS 加密策略
移动端弱网决策（结论：弱网回退 Do53）

不适用的场景：

衡量”加密 DNS 的隐私收益”——本文不谈隐私，只谈性能
HTTP/3 + DoH 的最新数据——本文用 HTTP/2，已不代表最新性能
自建递归解析器场景——本文测公共解析器（Cloudflare/Google/Quad9）

历史小故事（可跳过）

2016：Snowden 事件后 IETF 启动 DPRIVE 工作组，目标是给 DNS 加密
2016：DoT（RFC 7858）发布，监听 853 端口
2018：DoH（RFC 8484）发布，复用 443 端口
2018-2019：Cloudflare 1.1.1.1 / Google 8.8.8.8 / Quad9 9.9.9.9 全部支持 DoT/DoH
2019：Firefox / Chrome 陆续默认开 DoH，争议爆发
2020：本文发表于 PAM 2020，给出第一批跨地域大规模实测数据

学到什么

协议层堆叠的代价不是线性的——DoH 比 DoT 多一层 HTTP，但失败率不是多 10%，是多几倍。每加一层都会非线性放大不稳定性。
指标选错全错——单次查询时间 vs 页面加载时间，得出相反结论。设计 benchmark 时先问”这个指标和用户体验对应吗”。
连接复用是加密协议的救星——TLS 握手贵，但只贵一次。任何”开多次”的场景都被 TLS 拖死，“开一次用很多次”才能赚回来。HTTP/2、QUIC、DoT 全是这个套路。
隐私 vs 性能不是非此即彼——好网络下两者兼得，弱网下要选。这种”条件依赖”的工程权衡才是真实世界。
测量驱动决策——加密 DNS 在 2018 年是政治正确的故事，工程师只能闭嘴推。这篇论文是少数把”它到底慢多少”量化的工作，给后续浏览器/操作系统的回退策略提供了基础。没有测量就没有理性决策。
协议演进有窗口期——DoH over HTTP/2 是 2020 年的最佳答案；HTTP/3 + QUIC 出来后又得重测。任何”加密 DNS 的最终性能数据”都有有效期，不能拿一篇论文吃十年。

关联

dns —— DNS 协议本体，本文测的就是给它加密后的代价
mockapetris-1988-dns —— DNS 1988 原始设计，纯明文 UDP，本文要解决的就是它的隐私缺口
rfc-3833-dns-threats —— RFC 3833 系统化列举 DNS 威胁，DoT/DoH 是其中部分威胁的回应
[[tls-1.3]] —— TLS 1.3 把握手压到 1-RTT，直接决定 DoT/DoH 的下限性能
http-2 —— DoH 跑在 HTTP/2 上，多路复用是它能复用连接的根基
mitls-2014-triple-handshake —— TLS 形式化分析，DoT/DoH 安全性依赖 TLS 本身没洞
akamai-2002 —— CDN 与 DNS 选址耦合，集中式 DoH 会让 CDN 失去地理位置信号

反向链接

akamai-2002 —— Akamai 2002 — 把网站搬到离用户 10 毫秒的地方
dns —— DNS — 把全球域名解析切成一棵可分布维护的树
http-2 —— HTTP/2 — 把 HTTP 从文本协议改造成二进制多路复用
mitls-2014-triple-handshake —— Triple Handshake — TLS 同一把主密钥被复用，黑客就能换人不换锁
mockapetris-1988-dns —— Mockapetris 1988 DNS — 设计者亲口讲为什么 DNS 长这样
rfc-3833-dns-threats —— RFC 3833 — IETF 第一次正式承认 DNS 不安全