本文由自字節跳動技術肖新蔚、趙彥奇分享，有修訂和重新排版。

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）發起相同直播域名的解析請求時，由於對應網段緩存已提前預取，無需等待回源即可直接命中緩存，顯著降低訪問延遲。

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解決方案等
[7] 通俗易懂，理解移動網絡的“弱”和“慢”
[8] 現代移動端網絡短連接的優化手段總結
[9] 百度APP網絡深度優化實踐（DNS優化篇）
[10] 愛奇藝APP網絡優化實踐（網絡請求成功率優化篇）
[11] 美團點評的網絡優化實踐（大幅提升連接成功率、速度等）
[12] 淘寶移動端統一網絡庫的架構演進和弱網優化實踐
[13] 愛奇藝APP跨國弱網通信的優化實踐
[14] 得物自研移動端弱網診斷工具的技術實踐
[15] 攜程APP移動網絡優化實踐（弱網識別篇）
（本文同步發佈於：http://www.52im.net/thread-4876-1-1.html）