動態

詳情 返回 返回

vivo HTTPDNS 端到端體驗優化實踐 - 動態 詳情

作者:來自 vivo 互聯網運維團隊- Zhang Qianqian

在信息時代,用户的手機應用訪問量日益增多,DNS 解析作為連接互聯網的關鍵環節,也被提出了更高要求。這一背景下,HTTPDNS 域名解析服務憑藉防劫持、精準調度、實時解析生效等特性,逐漸成為行業主流解決方案。我們構建了 vivo HTTPDNS 端到端的一體化解決方案,通過對 HTTPDNS SDK、HTTPDNS 服務端、統一調度網關和全鏈路監控4大模塊的能力及架構優化,顯著提升了端側業務的訪問體驗,支撐業務高效、穩定開展。

一、vivo HTTPDNS 技術背景

1.1 為什麼要建設 vivo HTTPDNS 端到端一體化解決方案

伴隨業務的高速發展,應用的訪問量也越來越大;用户對手機終端應用的訪問體驗的要求也越來越高。但是我們在訪問互聯網業務的過程中可能會出現訪問被劫持到非法的資源;訪問的資源無法正常展示;資源打開比較慢,用户等待的時間比較長;運營商的 DNS 解析不精準,影響用户訪問的體驗;想要解決以上的問題,行業比較通用的方案是使用 HTTPDNS。

在這樣的背景下,vivo 在2017年開始 HTTPDNS 探索和使用;但是,在落地的過程中遇到以下幾個問題:

  • 一是 HTTPDNS 作為備用 DNS 的情況下無法解決域名誤封禁的問題;
  • 二是各業務沒有統一的接入方案,接入的成本比較高;
  • 三是客户端的網絡框架不統一,業務適配比較困難;
  • 四是行業商業化 HTTPDNS 的成本比較高,業務無法大範圍使用;
  • 五是缺乏統一的用户全鏈路監控,無法實時監控端側 DNS 解析情況。
  • 為了解決以上落地過程中的難題,我們需要建設 vivo HTTPDNS 端到端的一體化解決方案。

1.2 HTTPDNS 如何解決核心問題

建設一套 HTTPDNS 一體化解決方案,解決以上核心問題,助力業務的發展;我們主要從以下幾個方面切入:

  • 第一是統一 SDK 能力建設,解決封禁問題、降低業務接入成本、提升用户體驗;核心能力主要是域名解析優化,業務建連優化以及統一接入方案;
  • 第二是 HTTPDNS 服務端能力建設,降低業務使用 HTTPDNS 的成本,減小 DNS 訪問時延;核心能力是服務端的智能調度和多級緩存策略;
  • 第三是全鏈路監控能力的建設,實現用户訪問的統一監控;核心能力是提供端到端的用户訪問全鏈路的監控能力。

基於以上的建設思路,那下面看我們具體是如何實現的。

二、vivo HTTPDNS 平台實踐

2.1 vivo HTTPDNS 技術架構

vivo HTTPDNS 平台為業務提供一體化的 HTTPDNS 解決方案,整體架構主要包括四大模塊;分別是 HTTPDNS SDK,HTTPDNS 服務端、統一調度網關和全鏈路監控。

  • HTTPDNS SDK 主要提供 DNS 解析和業務建連優化;
  • HTTPDNS 服務端提供 HTTPDNS 高性能 API、緩存庫、代理網關等能力;
  • HTTPDNS 調度網關提供 DNS 解析策略和 DNS 調度能力;
  • 統一監控提供客户端監控、服務端監控、質量監控、地域監控等能力。

基於 HTTPDNS 平台能力,我們核心的流程是 vivo 手機應用集成 HTTPDNS SDK,SDK 首先向 HTTPDNS 調度網關請求獲取 DNS 策略等配置;獲取配置後向首選 DNS 發起域名解析,當首選 DNS 出現解析失敗、建連失敗、域名封禁、域名劫持等問題時向備選 DNS 發起域名解析請求,獲取正確的解決結果,發起建連請求,同時也會對解析的結果進行緩存與建連優化。

2.2 HTTPDNS SDK 優化

SDK 為我們承載 HTTPDNS 一體化解決方案的核心能力;在架構上主要提供底層網絡協議的支持,支持 HTTP1.X、HTTP2.0 和 QUIC 傳輸協議,同時也支持 TLS1.1、TLS1.2 和 TLS1.3 等加密協議;同時,在 TLS 協議的基礎上支持 Session Ticket 等優化策略;服務層提供 DNS 解析、DNS 緩存、業務建連、DNS 策略管控等功能;應用層提供接口、下載、上傳等能力;同時也提供全鏈路的網絡監控。

基於 SDK 的能力和使用場景,我們確定了 SDK 三個重點優化方向:

  • 一是域名解析優化,通過解析策略優化和緩存優化,提升 DNS 解析成功率和降低 DNS 解析時延;
  • 二是業務建連優化,通過網絡診斷、網速檢測、長連接優化、最佳路由、QUIC 建連競速,提升業務訪問的成功率和降低業務訪問時延,提升我們 vivo 手機用户的使用體驗;
  • 三是統一接入方案,通過調度網關和多網絡框架適配,降低業務接入的成本。

2.2.1 域名解析優化

首先介紹在解析策略優化方面的探索;DNS 解析是用户訪問 vivo 互聯網業務的第一步;傳統的 DNS 解析是使用運營商的 LocalDNS 進行域名的解析,在這個過程中經常會出現解析失敗或者解析的地址不精準的問題;針對解析失敗和解析地址不精準的問題,我們對 DNS 解析的優化主要分為以下三個階段:

  • 第一個階段是重試解析策略,DNS 解析失敗使用備選 DNS 重試解析;
  • 第二個階段是自適應解析策略,支持自適應的 DNS 解析失敗或者建連失敗的重試解析;
  • 第三個階段是IP優先/兜底策略,基於業務場景的IP優先或者兜底的解析策略。

首先,我們看一下重試解析策略,核心邏輯就是 DNS 解析失敗之後切換 DNS 方案重試解析,vivo 目前首選的 DNS 是運營商的 LocalDNS,LocalDNS 解析失敗或者解析超時使用 HTTPDNS 重試解析,這樣可以在提升解析的成功率的同時極大的降低 HTTPDNS 的使用成本。但是此策略無法解決建連失敗的場景;同時,DNS 解析的靈活性比較低,變更策略需要業務升級 SDK。

為了解決以上的問題,我們上線了自適應解析策略;自適應解析策略就是在重試解析策略的基礎上增加建連失敗的場景下切換 DNS 方案重試解析和建連訪問的策略;同時支持動態配置 DNS 策略,可以動態調整首選和備選 DNS,自適應解析策略場景進一步提升了用户的訪問成功率;重試解析策略和自適應解析策略上線後,DNS 解析成功率提升2%。

自使用解析策略之後是否可以進一步優化呢?如果備選 DNS 解析或者建連失敗我們應該如何處理?針對用户訪問時延要求比較高的場景是否可以優化掉 DNS 解析過程呢?

基於以上的問題,我們對解析策略進一步做了優化,針對業務訪問時延越短越好的冷啓動場景我們使用IP優先的策略,提前動態下發IP地址給客户端建連,優化掉 DNS 解析過程,進一步縮短用户訪問的時延;在成功率提升場景我們在備選 DNS 解析失敗之後使用IP兜底的策略,動態下發IP地址給業務建連,進一步提升用户訪問的成功率。

基於以上的優化方案,IP優先場景 DNS 解析時間下降80%,IP兜底場景業務成功率進一步提升0.2%~0.4%。

我們剛才介紹瞭解析策略的優化,下面我們介紹在緩存策略優化方面的探索;緩存是提升用户體驗的核心策略,但是緩存如果使用不好,可能會出現負向的效果,我們在緩存策略優化方面也是做了一些嘗試。

  • 第一個階段是使用固定緩存策略,直接將 DNS 解析IP地址進行緩存,緩存時間也是提前設置的固定值;
  • 第二個階段是動態緩存策略,基於域名加網絡信息的緩存策略,不同的網絡緩存不同的地址,同時緩存時間支持動態配置;
  • 第三個階段是樂觀緩存的策略,對於解析的結果,如果緩存已經過期,先將結果返回給客户端發起建連,再異步進行 DNS 解析,將異步解析的結果重新進行緩存。

固定緩存策略的核心策略是 DNS 解析之後將解析的結果進行緩存,下次客户端解析直接使用緩存的地址發起建連,以達到減少 DNS 解析時延的優化效果;緩存設置固定的過期時間,緩存過期之後進行 DNS 解析,如果解析成功,則重新進行緩存。此策略主要存在以下幾個問題:

  • 第一是用户切換網絡會導致緩存的結果出現跨網訪問的情況;
  • 第二是緩存時間固定,無法及時對緩存進行干預,出現異常會延長故障時間;
  • 第三是無法針對異常IP緩存進行優化,導致異常的時間較長。

基於以上的問題和痛點,我們實現了動態緩存策略;核心策略是針對緩存跨網、緩存時效性和異常IP緩存進行優化:

  • 針對緩存跨網,緩存中記錄用户網絡標識信息,使用緩存時需要同時匹配域名加網絡標識信息,避免出現緩存跨網的情況。
  • 時效性優化是緩存設置過期時間,過期時間支持動態可配置,提升了緩存的靈活性。
  • 異常IP緩存優化是在用户建連異常是清空對應的緩存,建連異常時切換 DNS 進行重試解析。

基於以上的優化策略,DNS 解析時延整體下降超過30%,優化效果顯著。

在動態緩存策略的基礎上,我們做了進一步的優化,提供了樂觀緩存的策略;一般情況下,緩存的結果過期之後都還是可以繼續使用的;對於解析的結果,如果緩存已經過期,我們樂觀判斷緩存是有效的,先將緩存返回給客户端建連,再異步發起 DNS 解析並重新緩存;此策略能夠進一步降低客户端的 DNS 解析時延,提升用户訪問體驗。

以上就是我們在域名解析優化方面針對域名解析策略和域名緩存邏輯做的探索和實踐。

2.2.2 業務建連優化

下面我們介紹在業務建連方面的優化,首先介紹網絡診斷的能力,網絡診斷的核心原理是通過網絡聯通質量檢測模塊,提供網絡連通性、認證 WiFi、信號強度、系統聯網策略、DNS、 ping 等檢測能力;診斷當前用户是否有網,網絡類型,網絡強度,是否限制聯網和訪問的域名是否可以 ping 通,為上層應用建連訪問優化提供數據支撐。

網絡診斷主要使用的場景是為視頻播放、瀏覽器網頁訪問提供網絡檢測功能;診斷出用户有網但是無法連接的問題原因;根據問題原因,做出用户提示與問題修復,提升 vivo 手機終端用户的使用體驗。

建連優化的第二能力是網速檢測,其核心原理是讀數據場景對各個請求進行數據統計,計算全局網速以及單個請求的網速,以達到監控網絡質量的目的。例如接入方在該時間點想知道近x秒內的全局速度;則可以逆序重組採集到的網絡質量數據信息,將此時間段內的多個請求的數據進行分段求和,算出在x秒內傳輸 y kb 的數據,用數據除以時間則為該時間段內用户的全局網絡速度。

網速檢測在視頻點播場景,可以根據檢測的網速對播放視頻的清晰度進行智能切換,保證視頻播放的流暢度,減少視頻播放的卡頓率。

建連優化的第三點是 DNS 最佳路由策略;核心邏輯是對多個 DNS 策略解析的IP地址選擇最好的地址發起建連訪問。主要的流程是 SDK 將運營商 LocalDNS、HTTPDNS、公共 DNS、IP直連等策略下的 DNS 解析結果進行匯聚;獲取對應網絡狀態下的IP地址,結合歷史行為庫中網絡ID相同的數據;按照訪問成功率和訪問耗時的智能算法對IP進行排序,對排序後的IP地址依次建連。

使用最佳路由模型能夠提升短視頻播放的成功率和瀏覽器網頁打開的成功率。

建連優化的第四點是 HTTP2 長連接優化;HTTP2 中的連接複用可以提高網絡性能和減少延遲,但在實際應用過程中,也發現了一些缺點,比如在長時間不使用某條連接,此時這條連接就有一定的概率會被網絡鏈路中的設備丟棄,並且部分設備不會按照協議標準通知客户端當前連接已被關閉。這就會導致客户端在下次請求時,依然會去複用連接,但此時由於中間鏈路或者服務端丟棄了當前鏈接,因此會出現訪問超時異常。

針對以上的問題,我們做了以下優化策略:

  • 第一種是長連接複用的被動檢測,當出現長連接超時的異常時,SDK 會強制從緩存池中移除此連接,這樣業務重試時,SDK 就會新建連接,避免出現訪問超時的異常。
  • 第二種優化策略是長連接複用的主動探測:在連接複用時,同步發起 ping 幀請求,並在2秒後去檢查 ping 的結果,如果沒有收到 ping 幀且當前連接上近2s內沒有數據傳輸,則主動斷開連接並在 sdk 內部進行重試;被動檢測需要先產生一次超時異常才會命中相關策略,主動探測也需要先花費2秒進行檢測。因此我們需要一種更加智能的方式來判斷連接是否複用,以減少異常對業務的時延影響。
  • 第三種優化策略是端側的智能預測,預測長連接不可用的時間,提前做出是否新建長連接的抉擇。

端側智能預測的核心策略是針對當前生命週期,對用户請求的相關歷史數據進行收集,包括網絡類型、請求時間、請求域名、連接空閒時間和異常信息等;根據歷史請求數據,不斷縮小可能出現複用超時問題的數據區間;之後對收集到的數據進行清洗,丟失異常數據和進行數據特徵提取,形成數據集;根據數據集中的相關數據進行綜合判斷,形成是否複用當前連接或者新建連接的結論。

建連優化的第五點是 QUIC 建連競速;SDK 支持 QUIC 建連競速,當開啓 QUIC 建連競速,用户發起訪問時,如果 QUIC 競速勝出則使用 QUIC 建連,HTTP  競速勝出則使用 HTTP 建連,從而提升端側訪問的成功率。

QUIC 建連競速在視頻播放場景,對播放失敗率、播放卡頓率、慢起播場景都有比較明顯的優化;在弱網場景下,QUIC 協議的性能優勢尤為明顯。

以上就是 vivo 在建連優化策略方面做的探索和實踐。

2.2.3 統一接入方案

下面我們介紹統一接入方案方面的優化,第一點是實現了HTTPDNS 調度網關,SDK 的所有配置都是通過調度網關進行管理和下發,包括 DNS 解析策略、緩存策略,建連策略,都是通過配置網關進行管理,SDK 的配置和策略變更客户端不需要重新發版,調度網關極大的提升了 SDK 的靈活性;並且調度網關通過域名的方式訪問,同時也避免IP被封禁的情況。

第二點是網絡框架適配,vivo 手機應用使用多種網絡框架,包括 OkHttp、Volley、HttpURLConnection、Glide 等網絡框架,vivo HTTPDNS SDK 對這些網絡框架都做了適配,滿足各類業務的接入需求,降低了業務接入的成本。

2.3 HTTPDNS 服務端優化

下面我們介紹 vivo HTTPDNS 服務端的架構,HTTPDNS 服務端主要提供高性能 API、緩存庫、代理網關等能力;高性能API提供智能解析、鑑權、緩存查詢等能力;緩存庫提供多級緩存、懶更新等能力;代理網關提供 EDNS、智能調度、IP探測等能力。通過這些能力給 vivo 用户提供高可用,低時延的HTTPDNS 解析服務。同時,也提供 HTTPDNS 管理後台,支持 DNS 管理、系統管理、調度策略管理、鑑權管理、接入管理等能力。

服務端最核心的能力主要分為智能調度和多級緩存,服務端智能調度是獲取多個合作方的解析結果,通過異步IP探測等策略,取最優的結果進行緩存,SDK 從服務端獲取最優的IP地址進行業務訪問。多級緩存將緩存結果由同步刷新優化為基於 TTL 過期時間的自動異步刷新一級緩存和二級緩存,極大的提升服務端的性能,同時也降低了 HTTPDNS 的使用成本。

2.4 HTTPDNS 可視化監控

vivo HTTPDNS 平台提供全鏈路的可視化監控能力;能夠監控用户從 DNS 解析到整個請求全部結束的所有階段的耗時與請求;根據監控可以高效定位網絡請求的各個階段的異常;同時也提供省份運營商維度的區域性監控和異常預警的能力;解決了業務訪問鏈路無監控的難點。根據省份運營商維度的區域性監控,可以針對不同地區的網絡訪問環境制定對應的優化方案,預警能力能夠及時發現異常並及時進行優化。

2.5 HTTPDNS 業務效果

經過以上的優化實踐,截止當前,vivo HTTPDNS 平台已經覆蓋 vivo 手機100+的業務,HTTPDNS 的解析次數達到了15億次每天;客户端的解析時延由平均180ms下降到115ms,下降幅度36%,優化效果顯著;服務端解析成功率達到99.5%,給業務提供穩定可靠的解析服務;服務端響應時間約4ms,達到行業領先水平;服務端緩存命中率達到90%,降低 HTTPDNS 的成本的同時縮短 DNS 解析的響應時間。

在成功率提升方面,DNS 解析成功率由優化前的97%提升到優化後的99.85%,基本解決了全部 DNS 相關的問題;客户端訪問成功率也由優化前的97%提升到優化後的99%,優化效果顯著,經過優化,vivo 終端應用的用户體驗有非常明顯的提升。

在防劫持方面, 2023年2月 i音樂域名某地區被劫持,通過監控發現域名被劫持到國外地址;vivo HTTPDNS 平台監控發現域名使用 HTTPDNS 解析正常,域名成功率和連通率均正常;CDN 監控業務流量正常,未出現任何異常。

在域名誤封禁方面, 2023年4月 .com.cn 根域在某地區電信&移動網絡下被誤封禁,DNS 解析地址返回127.0.0.1;vivo瀏覽器、短視頻等接入 vivo HTTPDNS 平台業務未受到影響,提升了 vivo 服務的可用性、品牌形象和口碑。

以上就是 vivo HTTPDNS 平台的探索和實踐,以及業務接入之後的具體表現。

三、vivo HTTPDNS 總結與展望

3.1 vivo HTTPDNS 建設總結

vivo HTTPDNS 平台的諸多實踐,沒有全部詳細描述,業務的優化方面也將持續建設。

  • 在域名解析優化方面,得益於DNS自適應解析策略和IP優先/兜底策略的優化,DNS 解析成功率有顯著的提升。
  • 在緩存優化方面,動態緩存和樂觀緩存策略進一步降低 DNS 解析時間,優化鏈路訪問時延時延,整體 DNS 解析時延下降30%+。
  • 建連優化方面,依託於端側網速檢測、最佳路由、長連接預測模型、QUIC 建連競速等策略,客户端成功率提升到2%。
  • 統一調度網關作為 vivo HTTPDNS 平台實踐 SDK 與服務端的橋樑,使得端到端的優化策略得以串聯。
  • 服務端智能調度提升 vivo HTTPDNS 的解析成功率,服務端解析成功率達到99.9%,進一步助力端側業務的訪問體驗。
  • 全鏈路監控為 vivo HTTPDNS 平台提供端到端的全鏈路監控能力,為業務的發展提供數據支撐。

3.2 vivo HTTPDNS 未來展望

最後,是我們對未來的一些展望,未來我們將持續聚焦端側優化的前沿技術;在網絡加速方面探索多通道加速和端側調度優化方案;

在多通道加速方面探索雙移動網絡、雙 WiFi 或者移動網絡加 WiFi 的加速方案。

在端側調度方面利用端側就近調度、智能尋址和專用低時延網絡加速方案,進一步提升端側用户的體驗。

體驗優化是 vivo 用户導向最核心的體現,用户訪問成功率的提升需要我們不斷的投入和持續的優化;我們將會與行業一起繼續探索體驗優化的新技術和新方案。

user avatar nihaojob 頭像 dirackeeko 頭像 banana_god 頭像 yqyx36 頭像 congjunhua 頭像 tizuqiudehongcha 頭像 haijun_5e7e16c909f52 頭像 codepencil 頭像 yushang_66b0e8718bd85 頭像 guangmingleiluodebaomihua 頭像 nullwy 頭像 judei 頭像
點贊 22 用戶, 點贊了這篇動態!
點贊

Add a new 評論

Some HTML is okay.