DNS调度追问Q&A-连接复用漂移与HTTPDNS-Anycast-BGP-CDN-健康检查

DNS调度追问Q&A-连接复用漂移与HTTPDNS-Anycast-BGP-CDN-健康检查

DNS 调度追问 Q&A

本文是对 [[1️⃣DNS负载均衡详解-异地多活与缓存及扩展性]] 的延伸补充。原文讲到"DNS 调度只在解析时生效，连接复用后会话会漂移"“HTTPDNS 治本”“Anycast 兜底”“CDN 调度”"DNS 层健康检查"等概念时一笔带过，这里把这些点单独拎出来讲透，并补充 HTTPDNS / Anycast / BGP / CDN / 健康检查 这几个常被一并提及的网络概念。

阅读顺序建议：先看 Q1 搞懂"连接复用为什么会让会话漂移"（这是 DNS 调度最容易被忽视的盲区），再看 Q2~Q5 这几个"治本/兜底"手段，最后看 Q6 CDN 调度把调度对象从"机房"换成"边缘缓存节点"。

Q1：DNS 调度只在解析时生效，连接复用后会话会漂移 —— 这里的"连接复用"是 Java 的还是 DNS 的？为什么会话会漂移？

1. 先回答"是谁的连接复用"

是 HTTP / TCP 层的连接复用，也就是应用层（Java 的 HttpClient、OkHttp、URLConnection，或浏览器、Nginx 反代的 upstream keepalive）层面的连接池 / Keep-Alive，不是 DNS 的。

要分清两件事：

所以原句"连接复用后会话会漂移"指的是后者：客户端用一条长连接发了好几个请求，这条连接是在某次 DNS 解析后建立的，之后它就钉死在那个 IP 上，DNS 再怎么调它都不管了。

2. 为什么会话会漂移？—— 关键在于"DNS 只在解析那一刻有话语权"

把一次完整调用拆开看：

时间线 T0：客户端发起请求 www.example.com
T1：本地 DNS 解析（命中权威调度策略）→ 返回 IP_A（北京机房）
T2：客户端与 IP_A 建立 TCP 连接，发请求 ①，得到响应，连接不关（Keep-Alive）
↓
—— 此后 DNS 层对这条连接再无任何控制权 ——
↓
时间线 T3（几分钟后）：业务方做容灾切换，DNS 权威把 www.example.com 改成 IP_B（深圳机房）
T4：DNS 缓存按 TTL 逐渐刷新，新发起的解析会得到 IP_B
T5：但客户端的连接池里还躺着那条到 IP_A 的长连接
T6：客户端发请求 ②③④…… 还是走 IP_A 这条老连接（连接池优先复用，不重新解析 DNS）

漂移就发生在 T5→T6：DNS 这时已经"指挥"流量去深圳（IP_B），但这条老连接的会话仍然赖在北京（IP_A）。会话的实际走向和 DNS 当前的调度策略不一致——这就是"漂移"。

会话（session）在这里指"一个逻辑用户/一次业务交互跨越的多个请求"，它跟随的是物理连接，而不是 DNS。

3. “连接都复用了，会话为什么还会漂移”—— 这是个好问题，恰恰相反

这句话的潜台词是"连接复用 = 稳定，那会话应该更稳才对，怎么反而漂移？" 答案是：

• 稳定 ≠ 跟随 DNS 调度。 连接复用确实让会话稳定地钉在某台服务器上（这对会话亲和、缓存命中是好事），但这个"稳定"是针对第一次解析时的那个 IP 的稳定，而 DNS 调度策略是会随时间变化的（加权轮询、容灾切换、灰度回切）。
• DNS 调度是"快照式"的： 它只在"建立新连接需要解析域名"的那个瞬间生效一次。一旦连接建好，这条连接的生命周期内，DNS 再变都跟它无关。
• 所以"连接复用"和"会话漂移"不是矛盾，而是因果：正是因为连接被复用（长存），它才绕过了后续每一次 DNS 解析，从而和 DNS 实时调度脱节，表现为"漂移到旧 IP"。

4. 这种漂移会带来什么实际问题

5. 怎么治

一句话总结：DNS 是"指路牌"，连接复用是"已上路的司机不肯掉头"。指路牌换得再勤，已经上路的连接也不会回头重新问一次路——这就是漂移的根因。

Q2：HTTPDNS 是什么？为什么需要？谁在用？好处？

1. 它是什么

HTTPDNS = 用 HTTP 协议（而不是传统 DNS 的 UDP 53）去做域名解析。 客户端不向操作系统的本地递归解析器（LDNS）发 UDP DNS 查询，而是直接向一个 HTTPDNS 服务的 URL 发一个 HTTP/HTTPS 请求，拿回一段 JSON，里面就是"域名 → IP（列表）"，并且 IP 是已经按调度策略选好的。

对比传统 DNS：

传统 DNS：
App → 系统 getaddrinfo() → 运营商递归解析器(LDNS) → 根 → 顶级域 → 权威 DNS
（UDP 53，明文，LDNS 会缓存，链路长，调度基于 LDNS 出口 IP）

HTTPDNS：
App → HTTP GET https://httpdns.aliyun.com/resolve?host=www.example.com → 直接返回 JSON {"host":"www.example.com","ips":["1.1.1.1","2.2.2.2"]}
（HTTPS 加密，直连 HTTPDNS 服务，无 LDNS 中间层，调度基于客户端真实 IP）

2. 为什么需要它——传统 DNS 的几个硬伤

3. 谁在用

• 厂商/服务方：阿里云 HTTPDNS（AliHTTPDNS）、腾讯云 HTTPDNS（HTTPDNS of Tencent）、华为云、AWS Route53（虽然不叫 HTTPDNS，但提供 Resolver over HTTPS / DoH 类似能力）、Cloudflare（DoH 1.1.1.1）。这些是提供 HTTPDNS 服务的平台。
• 实际客户：重度依赖 HTTPDNS 的几乎清一色是移动端 App 和 SDK——淘宝、支付宝、微信、抖音、美团、拼多多这类国民级 App。原因是：
  • 移动网络下 DNS 劫持最严重（WiFi 路由器、公共 WiFi、运营商 SP 都可能劫持）。
  • 移动用户漫游多（切换网络、跨地区），传统 DNS 调度更不准。
  • App 能自己集成 HTTPDNS SDK，绕开系统解析器（浏览器/PC 端集成成本高，更多走 DoH）。
• Web/浏览器场景：近年浏览器主推 DoH（DNS over HTTPS） 和 DoT（DNS over TLS），本质和 HTTPDNS 同源（都是把 DNS 查询塞进加密通道），代表是 Cloudflare 1.1.1.1、Mozilla+Cloudflare、Chrome 的 DoH。

4. 好处一句话

HTTPDNS 把"域名解析"从一个不可控的、明文的、被各级缓存和劫持污染的公共协议，变成了一个可控的、加密的、由业务直连的私有 API，从而拿到防劫持、精准调度、秒级生效三大能力。代价是必须有客户端 SDK 集成，不适合普通 Web/PC 浏览器（除非走 DoH）。

Q3：Anycast 是什么？为什么需要？谁在用？好处？

1. 它是什么

Anycast（任播）= 同一个 IP 地址，从网络上的多个节点同时对外宣告（announce），路由协议会把发往这个 IP 的包，送到"路由意义上最近"的那个节点。

四种播的方式对比：

关键点：Anycast 的"就近"不是 DNS 算出来的，是 BGP 等路由协议在网络层算出来的。 用户根本不需要知道有多个节点，他只看到一个 IP，路由器自己决定送到哪。

用户在东京 用户在纽约
│ │
▼ ▼
"1.1.1.1" "1.1.1.1" ← 同一个 IP
│ │
(BGP 路由选路) (BGP 路由选路)
│ │
▼ ▼
东京节点（宣告1.1.1.1） 纽约节点（宣告1.1.1.1）

2. 为什么需要它

• 天然就近接入：不用 DNS 智能解析，不用 EDNS-Client-Subnet，路由层直接就近。
• 自动容灾：某个节点挂了，它停止对外宣告这个 IP 的 BGP 路由，路由自动收敛，流量转到下一个最近的节点，秒级到几十秒级完成切换——比 DNS 容灾（分钟级 + 缓存漂移）快得多。
• 抗 DDoS：攻击流量打到一个 Anycast IP，会被路由分散到全球几十上百个节点，每个节点只承受一小部分，整体带宽被摊薄。这就是为什么 Cloudflare 敢扛超大流量攻击。
• 简化客户端：一个 IP 走天下，客户端无需复杂调度逻辑。

3. 谁在用

• DNS 根服务器：13 套根（A-M），每套用 Anycast 部署到全球数百个站点，是互联网的基石。
• 公共 DNS：Google 8.8.8.8、Cloudflare 1.1.1.1，都是 Anycast。
• CDN / 安全厂商：Cloudflare（整个边缘网络都是 Anycast）、Akamai、AWS CloudFront/Route53、Fastly。
• 云厂商的核心入口：AWS S3、ALB，阿里云的很多公网入口也用 Anycast。
• 能用 Anycast 的前提是你得有自己的 AS 号、能做 BGP 宣告——所以这是大厂/运营商/IDC 的游戏，普通公司用不起也用不到，只能消费它（用这些厂商的服务）。

4. 好处一句话

Anycast 把"就近接入 + 自动容灾 + 抗 DDoS"三件事从应用层下沉到网络路由层，不依赖 DNS、不依赖客户端、不依赖业务代码，纯靠 BGP 选路自动完成。代价是要有 AS 号和全球 BGP 宣告能力，门槛极高。

Q4：BGP 是什么？为什么需要？谁在用？好处？

1. 它是什么

BGP（Border Gateway Protocol，边界网关协议）= 互联网上"连接不同自治系统（AS）"的路由协议。 它负责在不同网络之间交换"我这边能到达哪些 IP 段"的信息，是整个互联网能跨网互通的根本。

• AS（Autonomous System，自治系统）：一个独立管理的网络，分配一个全局唯一编号（ASN）。中国电信是一个 AS，阿里云是一个 AS，清华大学校园网也可能是一个 AS。
• BGP 做的事：A 网络通过 BGP 告诉 B 网络"我能到达 1.1.1.0/24 这个网段"，B 收到后就知道"要把去 1.1.1.0/24 的包，发给 A"。
• 对比 OSPF/IS-IS：那些是"一个 AS 内部"用的内部网关协议（IGP），BGP 是"AS 之间"用的外部网关协议（EGP）。

2. 为什么需要它

• 跨网可达：没有 BGP，不同运营商、不同云、不同企业网络之间无法知道彼此的路由，互联网就碎成一个个孤岛。
• 多线接入（Multi-homing）：一个机房同时接入电信、联通、移动三条线路，靠 BGP 把自己的 IP 段向三个运营商都宣告，让三家用户都能"就近"进来，这就是所谓的 BGP 多线机房。
• 路由优化与容灾：BGP 可以宣告多条路径，按策略（AS-Path 长度、Local Preference 等）选优；某条线路断了，BGP 收敛后自动切到另一条。
• 是 Anycast 的基础：Q3 说 Anycast 是"同一个 IP 多点宣告"，这个"宣告"就是 BGP 做的。没有 BGP 就没有 Anycast。

3. 谁在用

• 基础运营商：电信、联通、移动、Verizon、NTT 等骨干网运营商，BGP 是它们的日常。
• 大型内容/云厂商：Google、Meta、Netflix、AWS、阿里云、腾讯云——都有自己的 AS 号，和众多运营商做 BGP 互联（Peering）。
• CDN / 安全厂商：Cloudflare、Akamai，用 BGP 把边缘节点宣告到全球。
• BGP 多线机房/IDC：国内大量"多线机房"卖点就是"接入电信+联通+移动 BGP"，让用户跨网访问不绕远。
• 企业：超大型企业（银行、头部互联网）会有自己的 AS 和 BGP，普通企业用不到。

4. 好处一句话

BGP 是互联网的"路由语言"，让分属不同运营商/云/企业的网络彼此可达、择优、冗余。它是 Anycast、多线机房、跨网容灾的底层前提，门槛同样是"要有 AS 号、要能和运营商做 Peering"，是大网络玩家的基础设施。

和 Q3 的关系：Anycast 是"用法"，BGP 是"实现这个用法的协议"。 你用 BGP 把同一个 IP 段从多个点宣告出去，效果就是 Anycast。

Q5：DNS 层的 HTTP/TCP 健康检查是什么？是 Java 的 health 接口吗？

1. 先明确"是谁在做检查"

这里的健康检查是 DNS 服务商（云解析平台，如阿里云 DNS、腾讯云 DNSPod、AWS Route53、Cloudflare）主动去探测你的 IP 健不健康，不是你的 Java 应用自己做的健康检查。

主体区别：

两者可以指向同一个 URL（你可以让 DNS 健康检查去 GET 你的 /actuator/health），但发起方和决策层完全不同：一个是集群内/服务治理层，一个是公网 DNS 调度层。

2. TCP 健康检查 vs HTTP 健康检查

• TCP 健康检查：DNS 探测点向你的 VIP 的某端口（如 443）发起 TCP 三次握手，握手成功就算健康，不管上层业务对不对。粒度粗，但快、省资源、对后端无侵入。
• HTTP 健康检查：DNS 探测点向你的 VIP 发一个 HTTP GET（如 https://www.example.com/health.html），看响应码（要求 2xx）和可选的响应体匹配字符串（比如要求 body 含 OK）。粒度细，能验证"应用真的能对外服务"，但每次探测是一次完整 HTTP 请求。

3. 不可达时怎么"自动切到备用线路"

配置上一般是这样：

www.example.com 的 A 记录配置：
主线路 IP_A（北京机房 VIP）—— 开启健康检查
备用线路 IP_B（深圳机房 VIP）—— 健康检查
（或用加权/优先级策略）

当 DNS 探测点连续 N 次探测 IP_A 都失败，DNS 服务商就把 IP_A 从应答里摘除（或降权），后续所有新解析只返回 IP_B，用户自然被引到深圳机房。这就是原文说的"VIP 不可达时自动切到备用线路"。

4. 为什么说这是"DNS 层能做的最主动的容灾"

• 经典 DNS 是被动的：它只负责返回记录，根本不知道后端 IP 死没死。你机器挂了，DNS 还傻傻地返回那个死 IP，直到人工去改记录。
• 加了健康检查，DNS 主动探测、自动摘除，是 DNS 这一层能做到的"最主动"行为。
• 但它仍然受 DNS 缓存限制：摘 IP 只影响新解析，老解析结果在各级缓存里还能存活一个 TTL。所以它"主动"是相对的，做不到 LB/Nginx 健康检查那种秒级摘除。配合短 TTL 才接近实时。

5. 和 Java Actuator health 的关系

• 不是一回事，但可以联动：你可以把 DNS HTTP 健康检查的目标 URL 配成你的 Java actuator /actuator/health 或一个专门的 /health.html 静态页。
• 区别场景：
  • K8s liveness/readiness probe → 控制 Pod 是否被 Service endpoints 收录、是否重启（集群内）。
  • Nginx/upstream 健康检查 → 控制某后端实例是否被转发（机房内/网关层）。
  • 注册中心健康检查（Eureka/Nacos）→ 控制实例是否在注册表里（服务治理层）。
  • DNS 健康检查 → 控制 IP 是否出现在 DNS 应答（公网入口层，最上游）。
• 四者从内到外、从细到粗，是分层递进的健康防线，不要混为一谈。

Q6：CDN 是什么？CDN 调度是什么意思？

1. CDN 是什么

CDN（Content Delivery Network，内容分发网络）= 分布在各地区的大量"边缘节点"，把源站的内容缓存到离用户最近的边缘，让用户就近取内容，而不是都回源站。

最早 CDN 就是为了解决两个问题：

• 延迟：用户在北京，源站在广州，每次请求跨大半个中国，慢。
• 源站压力：一个爆款视频/图片，几亿人同时回源站拉，源站扛不住。

CDN 把内容复制（缓存）到全球/全国成百上千个边缘节点，用户请求被引到最近的边缘节点，命中缓存就直接返回，不命中再回源。

源站（广州机房，内容源头）
│ （内容回源/预热）
┌──────────────┼──────────────┐
▼ ▼ ▼
北京边缘节点 上海边缘节点 成都边缘节点 ← 缓存了内容
▲ ▲ ▲
│ │ │
北京用户就近取 上海用户就近取 成都用户就近取

现代 CDN 早已不只是缓存静态文件：动态加速（DSA）、视频直播/点播加速、安全（WAF/DDoS 防护，所谓"安全 CDN"如 Cloudflare）、边缘计算（边缘函数）都长在 CDN 上。

2. CDN 调度是什么意思

“CDN 调度”= 把用户的请求，引到"最合适的那一个边缘节点"的过程。 调度的对象是边缘节点，目标函数是"延迟最低 / 命中率最高 / 节点不超载 / 线路最优"。

调度手段主要有三种：

实际厂商通常是组合使用：DNS 做大颗粒就近，302 做精细调度，Anycast 做容灾兜底。

3. CDN 调度和"DNS 负载均衡/GSLB"的区别

这是最容易混淆的点：

一句话区分：GSLB/DNS 负载均衡是"把用户调度到合适的机房去处理业务"，CDN 调度是"把用户调度到合适的边缘节点去取缓存"。 二者都靠 DNS 智能解析实现，但调度对象、目的、节点形态完全不同。

4. 谁在用 CDN / CDN 厂商

• CDN 厂商：Cloudflare、Akamai、AWS CloudFront、Fastly、阿里云 CDN、腾讯云 CDN、网宿（Wangsu）、白山云。
• 客户：几乎所有有公网流量的大公司——视频（B站、抖音、Netflix）、电商（淘宝、亚马逊）、新闻门户、下载站、游戏更新分发。普通公司直接买 CDN 厂商服务，不会自建。

七、把六个概念串起来：一张调度全景图

把 Q1~Q6 串进同一个"用户访问 www.example.com"的链路，就能看清它们各管哪一段：

用户敲入 www.example.com
│
▼
① 解析阶段（决定去哪个 IP）
├─ 传统 DNS：经 LDNS → 权威 DNS（智能解析/分线路） ← 受劫持、缓存、调度不准之苦
├─ HTTPDNS（Q2）：App 直连 HTTPS 取 IP ← 治①的三个病，移动端主流
└─ DoH：浏览器侧的"HTTPDNS 等价物"
│
▼
② 路由阶段（包到 IP 走哪条路）
├─ BGP（Q4）：跨 AS 选路，互联网能互通的根本
└─ Anycast（Q3）：同一 IP 多点宣告，路由就近 + 容灾 + 抗 DDoS
│
▼
③ 入口健康检查（DNS 层主动容灾，Q5）
└─ DNS 服务商探测 VIP 的 TCP/HTTP，不可达自动摘 IP
│
▼
④ 命中的是 CDN 边缘节点 还是 源站机房？（Q6）
├─ CDN 调度：DNS/302/Anycast 把用户引到就近边缘节点取缓存
└─ GSLB：DNS 把用户引到就近/合适机房处理完整业务
│
▼
⑤ 连接建立后——DNS 失去话语权（Q1）
└─ 连接复用让会话钉在首次解析的 IP 上，DNS 后续调度对它无效 → 会话漂移
└─ 治：短 TTL + 连接定期重建 + HTTPDNS + 多 IP 重试 + 服务网格
│
▼
⑥ 机房内部：LVS → Nginx → Java（actuator health、graceful shutdown、注册中心同机房亲和）

关系速记

• HTTPDNS 和 DNS 健康检查 都是"增强 DNS 这一层的手段"，一个治解析的实时性/准确性/防劫持，一个治 DNS 不知道后端死活的被动性。
• Anycast 和 BGP 是"网络层"的：BGP 是协议/能力，Anycast 是基于 BGP 的用法，把调度下沉到路由层，绕开 DNS 的所有毛病。
• CDN 调度 和 GSLB/DNS 负载均衡 形态相似（都靠 DNS 智能解析），但调度对象一个是边缘缓存节点、一个是源站机房。
• Q1 连接复用漂移 是上面所有"DNS 侧调度"的共同盲区：只要调度发生在解析阶段，就都受长连接复用的绕过。 这是为什么单纯靠 DNS 做容灾永远不够快，还得配合连接管理、HTTPDNS、Anycast、应用层重试。

八、总结表

核心认知：HTTPDNS、Anycast、BGP、DNS 健康检查、CDN 调度，本质上都是在"补 DNS 调度的洞"——分别补"劫持/不准/生效慢"“就近/容灾/抗 DDoS（下沉到路由层）”“跨网可达”“后端死活不知道”“调度对象应是缓存边缘节点”。而 Q1 的连接复用漂移提醒我们：只要调度只发生在域名解析那一瞬间，长连接就会绕过它——这是所有 DNS 侧方案的共同上限，治本要靠连接管理 + 应用层重试 + 服务网格。