在信息時(shí)代，用戶(hù)的手機(jī)應(yīng)用訪(fǎng)問(wèn)量日益增多，DNS 解析作為連接互聯(lián)網(wǎng)的關(guān)鍵環(huán)節(jié)，也被提出了更高要求。這一背景下，HTTPDNS 域名解析服務(wù)憑借防劫持、精準(zhǔn)調(diào)度、實(shí)時(shí)解析生效等特性，逐漸成為行業(yè)主流解決方案。我們構(gòu)建了 vivo HTTPDNS 端到端的一體化解決方案，通過(guò)對(duì) HTTPDNS SDK、HTTPDNS 服務(wù)端、統(tǒng)一調(diào)度網(wǎng)關(guān)和全鏈路監(jiān)控4大模塊的能力及架構(gòu)優(yōu)化，顯著提升了端側(cè)業(yè)務(wù)的訪(fǎng)問(wèn)體驗(yàn)，支撐業(yè)務(wù)高效、穩(wěn)定開(kāi)展。

一、vivo HTTPDNS 技術(shù)背景

1.1 為什么要建設(shè) vivo HTTPDNS 端到端一體化解決方案

伴隨業(yè)務(wù)的高速發(fā)展，應(yīng)用的訪(fǎng)問(wèn)量也越來(lái)越大；用戶(hù)對(duì)手機(jī)終端應(yīng)用的訪(fǎng)問(wèn)體驗(yàn)的要求也越來(lái)越高。但是我們?cè)谠L(fǎng)問(wèn)互聯(lián)網(wǎng)業(yè)務(wù)的過(guò)程中可能會(huì)出現(xiàn)訪(fǎng)問(wèn)被劫持到非法的資源；訪(fǎng)問(wèn)的資源無(wú)法正常展示；資源打開(kāi)比較慢，用戶(hù)等待的時(shí)間比較長(zhǎng)；運(yùn)營(yíng)商的 DNS 解析不精準(zhǔn)，影響用戶(hù)訪(fǎng)問(wèn)的體驗(yàn)；想要解決以上的問(wèn)題，行業(yè)比較通用的方案是使用 HTTPDNS。

在這樣的背景下，vivo 在2017年開(kāi)始 HTTPDNS 探索和使用；但是，在落地的過(guò)程中遇到以下幾個(gè)問(wèn)題：

• 一是 HTTPDNS 作為備用 DNS 的情況下無(wú)法解決域名誤封禁的問(wèn)題；
• 二是各業(yè)務(wù)沒(méi)有統(tǒng)一的接入方案，接入的成本比較高；
• 三是客戶(hù)端的網(wǎng)絡(luò)框架不統(tǒng)一，業(yè)務(wù)適配比較困難；
• 四是行業(yè)商業(yè)化 HTTPDNS 的成本比較高，業(yè)務(wù)無(wú)法大范圍使用；
• 五是缺乏統(tǒng)一的用戶(hù)全鏈路監(jiān)控，無(wú)法實(shí)時(shí)監(jiān)控端側(cè) DNS 解析情況。
• 為了解決以上落地過(guò)程中的難題，我們需要建設(shè) vivo HTTPDNS 端到端的一體化解決方案。

1.2 HTTPDNS 如何解決核心問(wèn)題

建設(shè)一套 HTTPDNS 一體化解決方案，解決以上核心問(wèn)題，助力業(yè)務(wù)的發(fā)展；我們主要從以下幾個(gè)方面切入：

• 第一是統(tǒng)一 SDK 能力建設(shè)，解決封禁問(wèn)題、降低業(yè)務(wù)接入成本、提升用戶(hù)體驗(yàn)；核心能力主要是域名解析優(yōu)化，業(yè)務(wù)建連優(yōu)化以及統(tǒng)一接入方案；
• 第二是 HTTPDNS 服務(wù)端能力建設(shè)，降低業(yè)務(wù)使用 HTTPDNS 的成本，減小 DNS 訪(fǎng)問(wèn)時(shí)延；核心能力是服務(wù)端的智能調(diào)度和多級(jí)緩存策略；
• 第三是全鏈路監(jiān)控能力的建設(shè)，實(shí)現(xiàn)用戶(hù)訪(fǎng)問(wèn)的統(tǒng)一監(jiān)控；核心能力是提供端到端的用戶(hù)訪(fǎng)問(wèn)全鏈路的監(jiān)控能力。

基于以上的建設(shè)思路，那下面看我們具體是如何實(shí)現(xiàn)的。

二、vivo HTTPDNS 平臺(tái)實(shí)踐

2.1 vivo HTTPDNS 技術(shù)架構(gòu)

vivo HTTPDNS 平臺(tái)為業(yè)務(wù)提供一體化的 HTTPDNS 解決方案，整體架構(gòu)主要包括四大模塊；分別是 HTTPDNS SDK，HTTPDNS 服務(wù)端、統(tǒng)一調(diào)度網(wǎng)關(guān)和全鏈路監(jiān)控。

• HTTPDNS SDK 主要提供 DNS 解析和業(yè)務(wù)建連優(yōu)化；
• HTTPDNS 服務(wù)端提供 HTTPDNS 高性能 API、緩存庫(kù)、代理網(wǎng)關(guān)等能力；
• HTTPDNS 調(diào)度網(wǎng)關(guān)提供 DNS 解析策略和 DNS 調(diào)度能力；
• 統(tǒng)一監(jiān)控提供客戶(hù)端監(jiān)控、服務(wù)端監(jiān)控、質(zhì)量監(jiān)控、地域監(jiān)控等能力。

基于 HTTPDNS 平臺(tái)能力，我們核心的流程是 vivo 手機(jī)應(yīng)用集成 HTTPDNS SDK，SDK 首先向 HTTPDNS 調(diào)度網(wǎng)關(guān)請(qǐng)求獲取 DNS 策略等配置；獲取配置后向首選 DNS 發(fā)起域名解析，當(dāng)首選 DNS 出現(xiàn)解析失敗、建連失敗、域名封禁、域名劫持等問(wèn)題時(shí)向備選 DNS 發(fā)起域名解析請(qǐng)求，獲取正確的解決結(jié)果，發(fā)起建連請(qǐng)求，同時(shí)也會(huì)對(duì)解析的結(jié)果進(jìn)行緩存與建連優(yōu)化。

2.2 HTTPDNS SDK 優(yōu)化

SDK 為我們承載 HTTPDNS 一體化解決方案的核心能力；在架構(gòu)上主要提供底層網(wǎng)絡(luò)協(xié)議的支持，支持 HTTP1.X、HTTP2.0 和 QUIC 傳輸協(xié)議，同時(shí)也支持 TLS1.1、TLS1.2 和 TLS1.3 等加密協(xié)議；同時(shí)，在 TLS 協(xié)議的基礎(chǔ)上支持 Session Ticket 等優(yōu)化策略；服務(wù)層提供 DNS 解析、DNS 緩存、業(yè)務(wù)建連、DNS 策略管控等功能；應(yīng)用層提供接口、下載、上傳等能力；同時(shí)也提供全鏈路的網(wǎng)絡(luò)監(jiān)控。

基于 SDK 的能力和使用場(chǎng)景，我們確定了 SDK 三個(gè)重點(diǎn)優(yōu)化方向：

• 一是域名解析優(yōu)化，通過(guò)解析策略?xún)?yōu)化和緩存優(yōu)化，提升 DNS 解析成功率和降低 DNS 解析時(shí)延；
• 二是業(yè)務(wù)建連優(yōu)化，通過(guò)網(wǎng)絡(luò)診斷、網(wǎng)速檢測(cè)、長(zhǎng)連接優(yōu)化、最佳路由、QUIC 建連競(jìng)速，提升業(yè)務(wù)訪(fǎng)問(wèn)的成功率和降低業(yè)務(wù)訪(fǎng)問(wèn)時(shí)延，提升我們 vivo 手機(jī)用戶(hù)的使用體驗(yàn)；
• 三是統(tǒng)一接入方案，通過(guò)調(diào)度網(wǎng)關(guān)和多網(wǎng)絡(luò)框架適配，降低業(yè)務(wù)接入的成本。

2.2.1 域名解析優(yōu)化

首先介紹在解析策略?xún)?yōu)化方面的探索；DNS 解析是用戶(hù)訪(fǎng)問(wèn) vivo 互聯(lián)網(wǎng)業(yè)務(wù)的第一步；傳統(tǒng)的 DNS 解析是使用運(yùn)營(yíng)商的 LocalDNS 進(jìn)行域名的解析，在這個(gè)過(guò)程中經(jīng)常會(huì)出現(xiàn)解析失敗或者解析的地址不精準(zhǔn)的問(wèn)題；針對(duì)解析失敗和解析地址不精準(zhǔn)的問(wèn)題，我們對(duì) DNS 解析的優(yōu)化主要分為以下三個(gè)階段：

• 第一個(gè)階段是重試解析策略，DNS 解析失敗使用備選 DNS 重試解析；
• 第二個(gè)階段是自適應(yīng)解析策略，支持自適應(yīng)的 DNS 解析失敗或者建連失敗的重試解析；
• 第三個(gè)階段是IP優(yōu)先/兜底策略，基于業(yè)務(wù)場(chǎng)景的IP優(yōu)先或者兜底的解析策略。

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

為了解決以上的問(wèn)題，我們上線(xiàn)了自適應(yīng)解析策略；自適應(yīng)解析策略就是在重試解析策略的基礎(chǔ)上增加建連失敗的場(chǎng)景下切換 DNS 方案重試解析和建連訪(fǎng)問(wèn)的策略；同時(shí)支持動(dòng)態(tài)配置 DNS 策略，可以動(dòng)態(tài)調(diào)整首選和備選 DNS，自適應(yīng)解析策略場(chǎng)景進(jìn)一步提升了用戶(hù)的訪(fǎng)問(wèn)成功率；重試解析策略和自適應(yīng)解析策略上線(xiàn)后，DNS 解析成功率提升2%。

自使用解析策略之后是否可以進(jìn)一步優(yōu)化呢？如果備選 DNS 解析或者建連失敗我們應(yīng)該如何處理？針對(duì)用戶(hù)訪(fǎng)問(wèn)時(shí)延要求比較高的場(chǎng)景是否可以?xún)?yōu)化掉 DNS 解析過(guò)程呢？

基于以上的問(wèn)題，我們對(duì)解析策略進(jìn)一步做了優(yōu)化，針對(duì)業(yè)務(wù)訪(fǎng)問(wèn)時(shí)延越短越好的冷啟動(dòng)場(chǎng)景我們使用IP優(yōu)先的策略，提前動(dòng)態(tài)下發(fā)IP地址給客戶(hù)端建連，優(yōu)化掉 DNS 解析過(guò)程，進(jìn)一步縮短用戶(hù)訪(fǎng)問(wèn)的時(shí)延；在成功率提升場(chǎng)景我們?cè)趥溥x DNS 解析失敗之后使用IP兜底的策略，動(dòng)態(tài)下發(fā)IP地址給業(yè)務(wù)建連，進(jìn)一步提升用戶(hù)訪(fǎng)問(wèn)的成功率。

基于以上的優(yōu)化方案，IP優(yōu)先場(chǎng)景 DNS 解析時(shí)間下降80%，IP兜底場(chǎng)景業(yè)務(wù)成功率進(jìn)一步提升0.2%~0.4%。

我們剛才介紹了解析策略的優(yōu)化，下面我們介紹在緩存策略?xún)?yōu)化方面的探索；緩存是提升用戶(hù)體驗(yàn)的核心策略，但是緩存如果使用不好，可能會(huì)出現(xiàn)負(fù)向的效果，我們?cè)诰彺娌呗詢(xún)?yōu)化方面也是做了一些嘗試。

• 第一個(gè)階段是使用固定緩存策略，直接將 DNS 解析IP地址進(jìn)行緩存，緩存時(shí)間也是提前設(shè)置的固定值；
• 第二個(gè)階段是動(dòng)態(tài)緩存策略，基于域名加網(wǎng)絡(luò)信息的緩存策略，不同的網(wǎng)絡(luò)緩存不同的地址，同時(shí)緩存時(shí)間支持動(dòng)態(tài)配置；
• 第三個(gè)階段是樂(lè)觀緩存的策略，對(duì)于解析的結(jié)果，如果緩存已經(jīng)過(guò)期，先將結(jié)果返回給客戶(hù)端發(fā)起建連，再異步進(jìn)行 DNS 解析，將異步解析的結(jié)果重新進(jìn)行緩存。

固定緩存策略的核心策略是 DNS 解析之后將解析的結(jié)果進(jìn)行緩存，下次客戶(hù)端解析直接使用緩存的地址發(fā)起建連，以達(dá)到減少 DNS 解析時(shí)延的優(yōu)化效果；緩存設(shè)置固定的過(guò)期時(shí)間，緩存過(guò)期之后進(jìn)行 DNS 解析，如果解析成功，則重新進(jìn)行緩存。
此策略主要存在以下幾個(gè)問(wèn)題：

• 第一是用戶(hù)切換網(wǎng)絡(luò)會(huì)導(dǎo)致緩存的結(jié)果出現(xiàn)跨網(wǎng)訪(fǎng)問(wèn)的情況；
• 第二是緩存時(shí)間固定，無(wú)法及時(shí)對(duì)緩存進(jìn)行干預(yù)，出現(xiàn)異常會(huì)延長(zhǎng)故障時(shí)間；
• 第三是無(wú)法針對(duì)異常IP緩存進(jìn)行優(yōu)化，導(dǎo)致異常的時(shí)間較長(zhǎng)。

基于以上的問(wèn)題和痛點(diǎn)，我們實(shí)現(xiàn)了動(dòng)態(tài)緩存策略；核心策略是針對(duì)緩存跨網(wǎng)、緩存時(shí)效性和異常IP緩存進(jìn)行優(yōu)化：

• 針對(duì)緩存跨網(wǎng)，緩存中記錄用戶(hù)網(wǎng)絡(luò)標(biāo)識(shí)信息，使用緩存時(shí)需要同時(shí)匹配域名加網(wǎng)絡(luò)標(biāo)識(shí)信息，避免出現(xiàn)緩存跨網(wǎng)的情況。
• 時(shí)效性?xún)?yōu)化是緩存設(shè)置過(guò)期時(shí)間，過(guò)期時(shí)間支持動(dòng)態(tài)可配置，提升了緩存的靈活性。
• 異常IP緩存優(yōu)化是在用戶(hù)建連異常是清空對(duì)應(yīng)的緩存，建連異常時(shí)切換 DNS 進(jìn)行重試解析。

基于以上的優(yōu)化策略，DNS 解析時(shí)延整體下降超過(guò)30%，優(yōu)化效果顯著。

在動(dòng)態(tài)緩存策略的基礎(chǔ)上，我們做了進(jìn)一步的優(yōu)化，提供了樂(lè)觀緩存的策略；一般情況下，緩存的結(jié)果過(guò)期之后都還是可以繼續(xù)使用的；對(duì)于解析的結(jié)果，如果緩存已經(jīng)過(guò)期，我們樂(lè)觀判斷緩存是有效的，先將緩存返回給客戶(hù)端建連，再異步發(fā)起 DNS 解析并重新緩存；此策略能夠進(jìn)一步降低客戶(hù)端的 DNS 解析時(shí)延，提升用戶(hù)訪(fǎng)問(wèn)體驗(yàn)。

以上就是我們?cè)谟蛎馕鰞?yōu)化方面針對(duì)域名解析策略和域名緩存邏輯做的探索和實(shí)踐。

2.2.2 業(yè)務(wù)建連優(yōu)化

下面我們介紹在業(yè)務(wù)建連方面的優(yōu)化，首先介紹網(wǎng)絡(luò)診斷的能力，網(wǎng)絡(luò)診斷的核心原理是通過(guò)網(wǎng)絡(luò)聯(lián)通質(zhì)量檢測(cè)模塊，提供網(wǎng)絡(luò)連通性、認(rèn)證 WiFi、信號(hào)強(qiáng)度、系統(tǒng)聯(lián)網(wǎng)策略、DNS、 ping 等檢測(cè)能力；診斷當(dāng)前用戶(hù)是否有網(wǎng)，網(wǎng)絡(luò)類(lèi)型，網(wǎng)絡(luò)強(qiáng)度，是否限制聯(lián)網(wǎng)和訪(fǎng)問(wèn)的域名是否可以 ping 通，為上層應(yīng)用建連訪(fǎng)問(wèn)優(yōu)化提供數(shù)據(jù)支撐。

網(wǎng)絡(luò)診斷主要使用的場(chǎng)景是為視頻播放、瀏覽器網(wǎng)頁(yè)訪(fǎng)問(wèn)提供網(wǎng)絡(luò)檢測(cè)功能；診斷出用戶(hù)有網(wǎng)但是無(wú)法連接的問(wèn)題原因；根據(jù)問(wèn)題原因，做出用戶(hù)提示與問(wèn)題修復(fù)，提升 vivo 手機(jī)終端用戶(hù)的使用體驗(yàn)。

建連優(yōu)化的第二能力是網(wǎng)速檢測(cè)，其核心原理是讀數(shù)據(jù)場(chǎng)景對(duì)各個(gè)請(qǐng)求進(jìn)行數(shù)據(jù)統(tǒng)計(jì)，計(jì)算全局網(wǎng)速以及單個(gè)請(qǐng)求的網(wǎng)速，以達(dá)到監(jiān)控網(wǎng)絡(luò)質(zhì)量的目的。例如接入方在該時(shí)間點(diǎn)想知道近x秒內(nèi)的全局速度；則可以逆序重組采集到的網(wǎng)絡(luò)質(zhì)量數(shù)據(jù)信息，將此時(shí)間段內(nèi)的多個(gè)請(qǐng)求的數(shù)據(jù)進(jìn)行分段求和，算出在x秒內(nèi)傳輸 y kb 的數(shù)據(jù)，用數(shù)據(jù)除以時(shí)間則為該時(shí)間段內(nèi)用戶(hù)的全局網(wǎng)絡(luò)速度。

網(wǎng)速檢測(cè)在視頻點(diǎn)播場(chǎng)景，可以根據(jù)檢測(cè)的網(wǎng)速對(duì)播放視頻的清晰度進(jìn)行智能切換，保證視頻播放的流暢度，減少視頻播放的卡頓率。

建連優(yōu)化的第三點(diǎn)是 DNS 最佳路由策略；核心邏輯是對(duì)多個(gè) DNS 策略解析的IP地址選擇最好的地址發(fā)起建連訪(fǎng)問(wèn)。主要的流程是 SDK 將運(yùn)營(yíng)商 LocalDNS、HTTPDNS、公共 DNS、IP直連等策略下的 DNS 解析結(jié)果進(jìn)行匯聚；獲取對(duì)應(yīng)網(wǎng)絡(luò)狀態(tài)下的IP地址，結(jié)合歷史行為庫(kù)中網(wǎng)絡(luò)ID相同的數(shù)據(jù)；按照訪(fǎng)問(wèn)成功率和訪(fǎng)問(wèn)耗時(shí)的智能算法對(duì)IP進(jìn)行排序，對(duì)排序后的IP地址依次建連。

使用最佳路由模型能夠提升短視頻播放的成功率和瀏覽器網(wǎng)頁(yè)打開(kāi)的成功率。

建連優(yōu)化的第四點(diǎn)是 HTTP2 長(zhǎng)連接優(yōu)化；HTTP2 中的連接復(fù)用可以提高網(wǎng)絡(luò)性能和減少延遲，但在實(shí)際應(yīng)用過(guò)程中，也發(fā)現(xiàn)了一些缺點(diǎn)，比如在長(zhǎng)時(shí)間不使用某條連接，此時(shí)這條連接就有一定的概率會(huì)被網(wǎng)絡(luò)鏈路中的設(shè)備丟棄，并且部分設(shè)備不會(huì)按照協(xié)議標(biāo)準(zhǔn)通知客戶(hù)端當(dāng)前連接已被關(guān)閉。這就會(huì)導(dǎo)致客戶(hù)端在下次請(qǐng)求時(shí)，依然會(huì)去復(fù)用連接，但此時(shí)由于中間鏈路或者服務(wù)端丟棄了當(dāng)前鏈接，因此會(huì)出現(xiàn)訪(fǎng)問(wèn)超時(shí)異常。

針對(duì)以上的問(wèn)題，我們做了以下優(yōu)化策略：

• 第一種是長(zhǎng)連接復(fù)用的被動(dòng)檢測(cè)，當(dāng)出現(xiàn)長(zhǎng)連接超時(shí)的異常時(shí)，SDK 會(huì)強(qiáng)制從緩存池中移除此連接，這樣業(yè)務(wù)重試時(shí)，SDK 就會(huì)新建連接，避免出現(xiàn)訪(fǎng)問(wèn)超時(shí)的異常。
• 第二種優(yōu)化策略是長(zhǎng)連接復(fù)用的主動(dòng)探測(cè)：在連接復(fù)用時(shí)，同步發(fā)起 ping 幀請(qǐng)求，并在2秒后去檢查 ping 的結(jié)果，如果沒(méi)有收到 ping 幀且當(dāng)前連接上近2s內(nèi)沒(méi)有數(shù)據(jù)傳輸，則主動(dòng)斷開(kāi)連接并在 sdk 內(nèi)部進(jìn)行重試；被動(dòng)檢測(cè)需要先產(chǎn)生一次超時(shí)異常才會(huì)命中相關(guān)策略，主動(dòng)探測(cè)也需要先花費(fèi)2秒進(jìn)行檢測(cè)。因此我們需要一種更加智能的方式來(lái)判斷連接是否復(fù)用，以減少異常對(duì)業(yè)務(wù)的時(shí)延影響。
• 第三種優(yōu)化策略是端側(cè)的智能預(yù)測(cè)，預(yù)測(cè)長(zhǎng)連接不可用的時(shí)間，提前做出是否新建長(zhǎng)連接的抉擇。

端側(cè)智能預(yù)測(cè)的核心策略是針對(duì)當(dāng)前生命周期，對(duì)用戶(hù)請(qǐng)求的相關(guān)歷史數(shù)據(jù)進(jìn)行收集，包括網(wǎng)絡(luò)類(lèi)型、請(qǐng)求時(shí)間、請(qǐng)求域名、連接空閑時(shí)間和異常信息等；根據(jù)歷史請(qǐng)求數(shù)據(jù)，不斷縮小可能出現(xiàn)復(fù)用超時(shí)問(wèn)題的數(shù)據(jù)區(qū)間；之后對(duì)收集到的數(shù)據(jù)進(jìn)行清洗，丟失異常數(shù)據(jù)和進(jìn)行數(shù)據(jù)特征提取，形成數(shù)據(jù)集；根據(jù)數(shù)據(jù)集中的相關(guān)數(shù)據(jù)進(jìn)行綜合判斷，形成是否復(fù)用當(dāng)前連接或者新建連接的結(jié)論。

建連優(yōu)化的第五點(diǎn)是 QUIC 建連競(jìng)速；SDK 支持 QUIC 建連競(jìng)速，當(dāng)開(kāi)啟 QUIC 建連競(jìng)速，用戶(hù)發(fā)起訪(fǎng)問(wèn)時(shí)，如果 QUIC 競(jìng)速勝出則使用 QUIC 建連，HTTP  競(jìng)速勝出則使用 HTTP 建連，從而提升端側(cè)訪(fǎng)問(wèn)的成功率。

QUIC 建連競(jìng)速在視頻播放場(chǎng)景，對(duì)播放失敗率、播放卡頓率、慢起播場(chǎng)景都有比較明顯的優(yōu)化；在弱網(wǎng)場(chǎng)景下，QUIC 協(xié)議的性能優(yōu)勢(shì)尤為明顯。

以上就是 vivo 在建連優(yōu)化策略方面做的探索和實(shí)踐。

2.2.3 統(tǒng)一接入方案

下面我們介紹統(tǒng)一接入方案方面的優(yōu)化，第一點(diǎn)是實(shí)現(xiàn)了HTTPDNS 調(diào)度網(wǎng)關(guān)，SDK 的所有配置都是通過(guò)調(diào)度網(wǎng)關(guān)進(jìn)行管理和下發(fā)，包括 DNS 解析策略、緩存策略，建連策略，都是通過(guò)配置網(wǎng)關(guān)進(jìn)行管理，SDK 的配置和策略變更客戶(hù)端不需要重新發(fā)版，調(diào)度網(wǎng)關(guān)極大的提升了 SDK 的靈活性；并且調(diào)度網(wǎng)關(guān)通過(guò)域名的方式訪(fǎng)問(wèn)，同時(shí)也避免IP被封禁的情況。

第二點(diǎn)是網(wǎng)絡(luò)框架適配，vivo 手機(jī)應(yīng)用使用多種網(wǎng)絡(luò)框架，包括 OkHttp、Volley、HttpURLConnection、Glide 等網(wǎng)絡(luò)框架，vivo HTTPDNS SDK 對(duì)這些網(wǎng)絡(luò)框架都做了適配，滿(mǎn)足各類(lèi)業(yè)務(wù)的接入需求，降低了業(yè)務(wù)接入的成本。

2.3 HTTPDNS 服務(wù)端優(yōu)化

下面我們介紹 vivo HTTPDNS 服務(wù)端的架構(gòu)，HTTPDNS 服務(wù)端主要提供高性能 API、緩存庫(kù)、代理網(wǎng)關(guān)等能力；高性能API提供智能解析、鑒權(quán)、緩存查詢(xún)等能力；緩存庫(kù)提供多級(jí)緩存、懶更新等能力；代理網(wǎng)關(guān)提供 EDNS、智能調(diào)度、IP探測(cè)等能力。通過(guò)這些能力給 vivo 用戶(hù)提供高可用，低時(shí)延的HTTPDNS 解析服務(wù)。同時(shí)，也提供 HTTPDNS 管理后臺(tái)，支持 DNS 管理、系統(tǒng)管理、調(diào)度策略管理、鑒權(quán)管理、接入管理等能力。

服務(wù)端最核心的能力主要分為智能調(diào)度和多級(jí)緩存，服務(wù)端智能調(diào)度是獲取多個(gè)合作方的解析結(jié)果，通過(guò)異步IP探測(cè)等策略，取最優(yōu)的結(jié)果進(jìn)行緩存，SDK 從服務(wù)端獲取最優(yōu)的IP地址進(jìn)行業(yè)務(wù)訪(fǎng)問(wèn)。多級(jí)緩存將緩存結(jié)果由同步刷新優(yōu)化為基于 TTL 過(guò)期時(shí)間的自動(dòng)異步刷新一級(jí)緩存和二級(jí)緩存，極大的提升服務(wù)端的性能，同時(shí)也降低了 HTTPDNS 的使用成本。

2.4 HTTPDNS 可視化監(jiān)控

vivo HTTPDNS 平臺(tái)提供全鏈路的可視化監(jiān)控能力；能夠監(jiān)控用戶(hù)從 DNS 解析到整個(gè)請(qǐng)求全部結(jié)束的所有階段的耗時(shí)與請(qǐng)求；根據(jù)監(jiān)控可以高效定位網(wǎng)絡(luò)請(qǐng)求的各個(gè)階段的異常；同時(shí)也提供省份運(yùn)營(yíng)商維度的區(qū)域性監(jiān)控和異常預(yù)警的能力；解決了業(yè)務(wù)訪(fǎng)問(wèn)鏈路無(wú)監(jiān)控的難點(diǎn)。根據(jù)省份運(yùn)營(yíng)商維度的區(qū)域性監(jiān)控，可以針對(duì)不同地區(qū)的網(wǎng)絡(luò)訪(fǎng)問(wèn)環(huán)境制定對(duì)應(yīng)的優(yōu)化方案，預(yù)警能力能夠及時(shí)發(fā)現(xiàn)異常并及時(shí)進(jìn)行優(yōu)化。

2.5 HTTPDNS 業(yè)務(wù)效果

經(jīng)過(guò)以上的優(yōu)化實(shí)踐，截止當(dāng)前，vivo HTTPDNS 平臺(tái)已經(jīng)覆蓋 vivo 手機(jī)100+的業(yè)務(wù)，HTTPDNS 的解析次數(shù)達(dá)到了15億次每天；客戶(hù)端的解析時(shí)延由平均180ms下降到115ms，下降幅度36%，優(yōu)化效果顯著；服務(wù)端解析成功率達(dá)到99.5%，給業(yè)務(wù)提供穩(wěn)定可靠的解析服務(wù)；服務(wù)端響應(yīng)時(shí)間約4ms，達(dá)到行業(yè)領(lǐng)先水平；服務(wù)端緩存命中率達(dá)到90%，降低 HTTPDNS 的成本的同時(shí)縮短 DNS 解析的響應(yīng)時(shí)間。

在成功率提升方面，DNS 解析成功率由優(yōu)化前的97%提升到優(yōu)化后的99.85%，基本解決了全部 DNS 相關(guān)的問(wèn)題；客戶(hù)端訪(fǎng)問(wèn)成功率也由優(yōu)化前的97%提升到優(yōu)化后的99%，優(yōu)化效果顯著，經(jīng)過(guò)優(yōu)化，vivo 終端應(yīng)用的用戶(hù)體驗(yàn)有非常明顯的提升。

在防劫持方面， 2023年2月 i音樂(lè)域名某地區(qū)被劫持，通過(guò)監(jiān)控發(fā)現(xiàn)域名被劫持到國(guó)外地址；vivo HTTPDNS 平臺(tái)監(jiān)控發(fā)現(xiàn)域名使用 HTTPDNS 解析正常，域名成功率和連通率均正常；CDN 監(jiān)控業(yè)務(wù)流量正常，未出現(xiàn)任何異常。

在域名誤封禁方面， 2023年4月 .com.cn 根域在某地區(qū)電信&移動(dòng)網(wǎng)絡(luò)下被誤封禁，DNS 解析地址返回127.0.0.1；vivo瀏覽器、短視頻等接入 vivo HTTPDNS 平臺(tái)業(yè)務(wù)未受到影響，提升了 vivo 服務(wù)的可用性、品牌形象和口碑。

以上就是 vivo HTTPDNS 平臺(tái)的探索和實(shí)踐，以及業(yè)務(wù)接入之后的具體表現(xiàn)。

三、vivo HTTPDNS 總結(jié)與展望

3.1 vivo HTTPDNS 建設(shè)總結(jié)

vivo HTTPDNS 平臺(tái)的諸多實(shí)踐，沒(méi)有全部詳細(xì)描述，業(yè)務(wù)的優(yōu)化方面也將持續(xù)建設(shè)。

• 在域名解析優(yōu)化方面，得益于DNS自適應(yīng)解析策略和IP優(yōu)先/兜底策略的優(yōu)化，DNS 解析成功率有顯著的提升。
• 在緩存優(yōu)化方面，動(dòng)態(tài)緩存和樂(lè)觀緩存策略進(jìn)一步降低 DNS 解析時(shí)間，優(yōu)化鏈路訪(fǎng)問(wèn)時(shí)延時(shí)延，整體 DNS 解析時(shí)延下降30%+。
• 建連優(yōu)化方面，依托于端側(cè)網(wǎng)速檢測(cè)、最佳路由、長(zhǎng)連接預(yù)測(cè)模型、QUIC 建連競(jìng)速等策略，客戶(hù)端成功率提升到2%。
• 統(tǒng)一調(diào)度網(wǎng)關(guān)作為 vivo HTTPDNS 平臺(tái)實(shí)踐 SDK 與服務(wù)端的橋梁，使得端到端的優(yōu)化策略得以串聯(lián)。
• 服務(wù)端智能調(diào)度提升 vivo HTTPDNS 的解析成功率，服務(wù)端解析成功率達(dá)到99.9%，進(jìn)一步助力端側(cè)業(yè)務(wù)的訪(fǎng)問(wèn)體驗(yàn)。
• 全鏈路監(jiān)控為 vivo HTTPDNS 平臺(tái)提供端到端的全鏈路監(jiān)控能力，為業(yè)務(wù)的發(fā)展提供數(shù)據(jù)支撐。

3.2 vivo HTTPDNS 未來(lái)展望

最后，是我們對(duì)未來(lái)的一些展望，未來(lái)我們將持續(xù)聚焦端側(cè)優(yōu)化的前沿技術(shù)；在網(wǎng)絡(luò)加速方面探索多通道加速和端側(cè)調(diào)度優(yōu)化方案；

在多通道加速方面探索雙移動(dòng)網(wǎng)絡(luò)、雙 WiFi 或者移動(dòng)網(wǎng)絡(luò)加 WiFi 的加速方案。

在端側(cè)調(diào)度方面利用端側(cè)就近調(diào)度、智能尋址和專(zhuān)用低時(shí)延網(wǎng)絡(luò)加速方案，進(jìn)一步提升端側(cè)用戶(hù)的體驗(yàn)。

體驗(yàn)優(yōu)化是 vivo 用戶(hù)導(dǎo)向最核心的體現(xiàn)，用戶(hù)訪(fǎng)問(wèn)成功率的提升需要我們不斷的投入和持續(xù)的優(yōu)化；我們將會(huì)與行業(yè)一起繼續(xù)探索體驗(yàn)優(yōu)化的新技術(shù)和新方案。