移动端弱网优化：字节跳动移动端网络HttpDNS优化实践
本文由自字节跳动技术肖新蔚、赵彦奇分享，有修订和重新排版。
1、引言
本文要分享的是字节跳动团队针对火山HTTPDNS Cache2.0通过自研网段库与动态划分算法，将缓存粒度从“城市-运营商”细化为“网段”，解决了传统方案的城市级调度污染问题。配合缓存分级、预取等优化，在提升调度精准度的同时保证了高命中率，最终实现了服务端调度准确性提升和客户端性能优化。
2、系列文章
《移动端弱网优化专题(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端弱网优化专题(二)：史上最全移动弱网络优化方法总结》
《移动端弱网优化专题(三)：现代移动端网络短连接的优化手段总结》
《移动端弱网优化专题(四)：百度APP网络深度优化实践（DNS优化篇）》
《移动端弱网优化专题(五)：百度APP网络深度优化实践（网络连接优化篇）》
《移动端弱网优化专题(六)：百度APP网络深度优化实践（移动弱网优化篇）》
《移动端弱网优化专题(七)：爱奇艺APP网络优化实践（网络请求成功率优化篇）》
《移动端弱网优化专题(八)：美团点评的网络优化实践（大幅提升连接成功率、速度等）》
《移动端弱网优化专题(九)：淘宝移动端统一网络库的架构演进和弱网优化实践》
《移动端弱网优化专题(十)：爱奇艺APP跨国弱网通信的优化实践》
《移动端弱网优化专题(十一)：美图APP的移动端DNS优化实践》
《移动端弱网优化专题(十二)：得物自研移动端弱网诊断工具的技术实践》
《移动端弱网优化专题(十三)：得物移动端常见白屏问题优化（网络优化篇）》
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）发起相同直播域名的解析请求时，由于对应网段缓存已提前预取，无需等待回源即可直接命中缓存，显著降低访问延迟。
8、HttpDNS优化后的实际效果
服务端调度精准度提高：借助网段级缓存，用户获取的 IP 地址更加精准。按服务端日志数据口径，调度不准比例从万分之六下降至万分之二，降幅 60%，有效缓解了传统粗粒度缓存导致的“城市级缓存污染”问题。
客户端性能优化：
- 1）成功率：核心 feed 接口，在弱网+非连接复用场景下提升 1.15%；
- 2）耗时：非连接复用场景耗时减少14ms。
用户体验提升：
- 1）性能指标：首刷及启动耗时下降；
- 2）用户指标：用户行为指标（send 与 click）正向，用户活跃度提升。
本方案通过服务端精准调度 → 客户端性能优化 → 用户体验提升，实现了全链路效能提升。
9、持续演进方向——共享缓存
目前，各机房的负载均衡策略与缓存策略未能完全对齐（部分采用随机转发，部分虽然使用一致性哈希但粒度不一致），导致同一数据在多个实例中被重复缓存，资源利用率偏低，缓存命中率也有待提升。
未来，我们计划构建一个分层共享的高可用缓存体系：
1）在同一机房内，实例通过一致性哈希协同分工，每台实例既是分片缓存，也能代理转发请求，从而减少重复存储并提升命中率；
2）在跨机房层面，按区域部署二级缓存节点，作为容量更大、延迟更低的共享中心，承接一级未命中的请求，降低跨区域访问和上游压力。与此同时，引入热点数据副本、请求合并和故障转移等机制，保证高并发和异常情况下的稳定性与可用性。
通过这一演进，整体架构将逐步升级为层次化、分布式且具备高可用能力的缓存网络，为业务的持续扩展提供坚实支撑。
10、参考资料
[1] TCP/IP详解 卷1：协议 - 第14章 DNS:域名系统
[2] 网络编程懒人入门(七)：深入浅出，全面理解HTTP协议
[3] 网络编程懒人入门(十二)：快速读懂Http/3协议，一篇就够！
[4] 从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路
[5] 脑残式网络编程入门(三)：HTTP协议必知必会的一些知识
[6] 全面了解移动端DNS域名劫持等杂症：原理、根源、HttpDNS解决方案等
[11] 美团点评的网络优化实践（大幅提升连接成功率、速度等）
[13] 爱奇艺APP跨国弱网通信的优化实践
[14] 得物自研移动端弱网诊断工具的技术实践
[15] 携程APP移动网络优化实践（弱网识别篇）
技术交流：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）
（本文已同步发布于：http://www.52im.net/thread-4876-1-1.html）
