移动端弱网优化专题(十五)：字节跳动移动端网络HttpDNS优化实践

本文由自字节跳动技术肖新蔚、赵彦奇分享，有修订和重新排版。

1、引言

本文要分享的是字节跳动团队针对火山HTTPDNS Cache2.0通过自研网段库与动态划分算法，将缓存粒度从“城市-运营商”细化为“网段”，解决了传统方案的城市级调度污染问题。配合缓存分级、预取等优化，在提升调度精准度的同时保证了高命中率，最终实现了服务端调度准确性提升和客户端性能优化。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4876-1-1.html）

2、系列文章

《移动端弱网优化专题(一)：通俗易懂，理解移动网络的“弱”和“慢”》

《移动端弱网优化专题(二)：史上最全移动弱网络优化方法总结》

《移动端弱网优化专题(三)：现代移动端网络短连接的优化手段总结》

《移动端弱网优化专题(四)：百度APP网络深度优化实践（DNS优化篇）》

《移动端弱网优化专题(五)：百度APP网络深度优化实践（网络连接优化篇）》

《移动端弱网优化专题(六)：百度APP网络深度优化实践（移动弱网优化篇）》

《移动端弱网优化专题(七)：爱奇艺APP网络优化实践（网络请求成功率优化篇）》

《移动端弱网优化专题(八)：美团点评的网络优化实践（大幅提升连接成功率、速度等）》

《移动端弱网优化专题(九)：淘宝移动端统一网络库的架构演进和弱网优化实践》

《移动端弱网优化专题(十)：爱奇艺APP跨国弱网通信的优化实践》

《移动端弱网优化专题(十一)：美图APP的移动端DNS优化实践》

《移动端弱网优化专题(十二)：得物自研移动端弱网诊断工具的技术实践》

《移动端弱网优化专题(十三)：得物移动端常见白屏问题优化（网络优化篇）》

《移动端弱网优化专题(十四)：携程APP移动网络优化实践（弱网识别篇）》

《移动端弱网优化专题(十五)：字节跳动移动端网络HttpDNS优化实践》（☜ 本文）

3、技术背景

在字节跳动的业务生态中，HTTPDNS 承担着为抖音、今日头条、西瓜视频等核心应用提供域名解析服务的重任。但目前我们所采用的业界主流缓存机制（火山Cache1.0），却存在着调度不准的问题。

这些问题主要是：

1）业界主流缓存机制的问题；
2）缓存粒度：城市-运营商；
3）致命缺陷：当自身IP库与权威DNS服务器不同，易发生调度不准，可能影响用户体验。

4、主流HttpDNS调度修正机制的局限性

针对 HTTPDNS 调度不准风险，业界主流处置流程采用 “发现-定位-修复” 三步闭环机制.

具体如下：

1）发现：通过监控告警、业务异常反馈等方式，识别存在调度偏差的解析场景；
2）定位：结合访问日志、链路追踪数据等，定位调度不准的具体域名、源IP段和目标 IP 段；
3）修复：通过技术手段修正解析结果。

针对上述第 3）点，核心修复方式包含以下两类（均存在显著局限性）：

1）地址库升级：基于外部供应商数据聚合构建的 IP 地址库，即使实时更新，仍难与外部 CDN 厂商的映射保持一致；
2）临时劫持：手动配置解析劫持规则修正解析结果，不仅操作流程繁琐、耗时长，且需人工维护大量静态配置；若规则未得到及时维护，易引发解析结果异常。

5、主流厂商的HttpDNS缓存粒度技术方案

缓存粒度设计直接影响 DNS 解析精准度，主流厂商的方案存在明显差异：

6、HttpDNS的缓存键精细化重构

我们综合考量调度精准度、工程复杂度以及成本，决定将缓存粒度由“城市+运营商”细化为“网段”。

6.1 传统方案（国内某厂商/火山Cache1.0）

1）缓存粒度：城市+运营商；
2）污染范围：整个城市运营商；
3）调度准确性：低。

6.2 Cache2.0方案

1）缓存粒度：网段；
2）污染范围：单个网段；
3）调度准确性：高。

6.3 网段自适应划分算法

背景：外部 CDN 厂商的调度结果会随网络拓扑和调度策略持续变化，而静态网段库划分方式固定，难以实时跟踪调度结果变化。

为解决这一问题，网段库动态划分算法通过“数据输入—一致性校验—网段调整—结果输出”的闭环流程，实现了网段库的自适应动态划分。

具体流程如下。

1）数据输入：

* 收集客户端IP—CDN IP映射数据：

a）数据来源：主动拨测结果；HTTPDNS 递归节点日志；
b）数据范围：主流CDN厂商的解析结果。

* 网段归属判断：

a）若相邻客户端IP的CDN IP 归属同一运营商，则该组CIP可合并为连续网段；
b）将合并后的连续网段输出，作为探测网段数据集。

2）一致性校验：

a）将探测网段数据集与存量CIDRDB网段库进行逐网段对比，检查 “映射一致性”；
b）若存在映射不一致，则触发网段调整流程。

3）网段调整：

a）合并：探测数据集的网段比现有库粗，合并为大网段；
b）拆分：探测数据集的网段比现有库细，拆分为小网段。

4）结果输出：

a）生成优化后的新CIDRDB网段库；
b）替换存量网段库，实现动态更新。

5）持续迭代：

a）重复上述流程，实现网段库的自适应动态划分。

7、HttpDNS的缓存策略优化

为解决缓存粒度细化可能导致的命中率下降问题，Cache2.0 引入了四重优化策略，最终实现了如下收益：

缓存命中率提高了15%，缓存量、CPU 使用和出网流量降低了约70%。

1）两级一致性哈希分流：

火山 HTTPDNS 的流量转发以一致性哈希思想为核心，将用户请求链路（用户→LB→缓存层→递归层）拆分为两级哈希调度：

a）一级调度（LB→缓存层）：以“源 IP + 域名”为哈希键。使用LB的一致性哈希策略，将同一用户对同一域名的请求统一路由至固定的 HTTPDNS 节点，避免传统轮询导致的请求分散；
b）二级调度（缓存层→递归层）：以“域名 + 网段” 为哈希键。以 “域名 + 客户端网段” 作为哈希键，与缓存粒度完全对齐，确保某一“域名 + 网段”对应的查询请求均定向到唯一的递归层节点。

两级哈希协同调度，解决了缓存的碎片化问题，同时单一节点故障影响范围极小。

2）缓存分级管理：

在 HTTPDNS 场景中，不同域名对解析精度的需求不同。高优先级域名（如API 调用、直播 / 点播流媒体分发）对解析精准性要求高，跨网可能导致访问延迟增加；而低精度需求域名（如302域名）采用过细缓存会浪费存储资源，频繁回源也会增加权威 DNS 压力。

为实现缓存资源的精细化分配，火山 HTTPDNS 将缓存体系划分为“网段缓存、城市 - 运营商缓存、全局缓存” 三级，各级缓存适配不同应用场景。

具体是：

1）网段缓存：作为最高精度层级，聚焦高优先级业务场景：一方面适配高优域名（如抖音 API 调用、图片分发、点播 / 直播流媒体传输等对精准性敏感的域名），另一方面服务重点集群（如 ToB 企业 HTTPDNS 服务、ToB 专属公共 DNS 服务），通过网段级细粒度缓存确保解析结果与用户实际网络链路高度匹配，降低访问延迟；

2）城市 - 运营商缓存：定位中等精度层级，适配普通域名场景：针对调度精准度要求较低的域名，以 “城市 + 运营商” 为缓存单元，平衡缓存命中率与存储开销；

3）全局缓存：作为基础精度层级，专门适配非智能解析域名：针对不支持 CDN 动态调度、解析结果无地域 / 运营商差异的域名（如静态官网、通用工具类服务域名），采用全局统一缓存策略，所有用户查询共享同一缓存结果，最大化提升缓存命中率，降低回源请求压力。

3）缓存更新分级策略：

在 HTTPDNS 系统中，统一的主动刷新策略虽然能保证缓存命中率，但存在明显问题：对不需要精细调度的域名浪费了存储资源，增加了下游压力。

基于以上问题，火山 HTTPDNS引入 “主动刷新 + 被动刷新”分级策略，以域名优先级和业务需求为依据，将缓存更新机制分为两类。

具体是：

a）后台线程主动刷新机制：针对高优域名（白名单），保留后台线程主动刷新，确保缓存持续有效、用户请求直接命中最新数据；
b）用户请求被动刷新机制：针对普通域名或非智能解析域名，由请求触发缓存更新，按需刷新，无需常驻后台刷新线程，降低资源消耗。

通过这种分级更新策略，高优先级域名仍能保证低延迟和高命中率，同时普通域名的刷新开销显著降低。

4）缓存预取机制：

依托 “缓存空间局部性原理”，火山 HTTPDNS 设计了缓存预取机制。当某条缓存请求（如 A 网段域名解析）触发更新时，系统不仅刷新目标网段缓存，还会同步更新与其具有 “亲缘关系” 的网段缓存（“亲缘关系”指地理相邻、同运营商节点覆盖的网段）。这种 “单次请求触发批量预取” 的设计能够提前将关联网段缓存置于准备状态，提升后续请求的命中率。

以抖音直播域名的实际访问场景为例，预取机制的运作过程如下：

a）本网段更新：当用户 A（IP 归属北京联通 10.0.1.0/24 网段）发起直播域名解析请求时，系统首先刷新其所属的 10.0.1.0/24 网段缓存；
b）预取更新：系统同时刷新与 10.0.1.0/24 网段具有亲缘关系的网段缓存，例如北京联通下的相邻网段（10.0.2.0/24、10.0.3.0/24），确保这些网段缓存也处于准备状态。

随后，当用户 B（10.0.2.0/24）或用户 C（10.0.10.0/24）发起相同直播域名的解析请求时，由于对应网段缓存已提前预取，无需等待回源即可直接命中缓存，显著降低访问延迟。