1. 引言

　　自 2013 年 ALLIN 無線到今天，已經(jīng)走過 10 個(gè)年頭，手淘終端統(tǒng)一網(wǎng)絡(luò)庫 AWCN (Ali Wireless Connection Network) 從淘內(nèi)孵化，一路過來伴隨著手淘業(yè)務(wù)的發(fā)展，經(jīng)歷集團(tuán) IPv6 戰(zhàn)役、協(xié)議升級(jí)演進(jìn)等，逐步沉淀為阿里集團(tuán)終端網(wǎng)絡(luò)通用解決方案，是兼具高性能、多協(xié)議、可容災(zāi)、可觀測(cè)的終端網(wǎng)絡(luò)基礎(chǔ)統(tǒng)一設(shè)施。面對(duì)移動(dòng)互聯(lián)網(wǎng)絡(luò)下復(fù)雜多變的網(wǎng)絡(luò)環(huán)境，如何提供更穩(wěn)定可靠的請(qǐng)求性能，保障用戶的加載瀏覽體驗(yàn)、更好的支撐業(yè)務(wù)發(fā)展，是我們始終探索的命題。

　　本文將介紹淘寶 APP 統(tǒng)一網(wǎng)絡(luò)庫演進(jìn)的過程，講述如何圍繞體驗(yàn)持續(xù)構(gòu)建南北向從監(jiān)測(cè)到加速一體化的終端網(wǎng)絡(luò)架構(gòu)，通過構(gòu)建 NPM 弱網(wǎng)診斷感知能力，落地原生多通道技術(shù)/多協(xié)議擇優(yōu)調(diào)度手段，貼合廠商附能網(wǎng)絡(luò)請(qǐng)求加速，實(shí)現(xiàn)去 SPDY 及規(guī)模化 IPv6/H3 協(xié)議簇的平滑過渡，為用戶提供弱網(wǎng)更好、好網(wǎng)更優(yōu)的 APP 加載瀏覽體驗(yàn)，支撐業(yè)務(wù)創(chuàng)造更多的可能性。

　　2. 終端架構(gòu)介紹

　　2.1 MobileSDN 理念

　　在介紹 AWCN 之前，筆者想先這里普及下 SDN 架構(gòu)的概念。

　　SDN（Software Defined Network，軟件定義網(wǎng)絡(luò)） 是一種將網(wǎng)絡(luò)資源抽象到虛擬化系統(tǒng)中的 IT 基礎(chǔ)架構(gòu)，SDN 將網(wǎng)絡(luò)轉(zhuǎn)發(fā)功能與網(wǎng)絡(luò)控制功能分開，其目標(biāo)是創(chuàng)建可集中管理和可編程的網(wǎng)絡(luò)，核心理念是 希望應(yīng)用軟件可以參與對(duì)網(wǎng)絡(luò)的控制管理，滿足上層業(yè)務(wù)需求，簡化使用和運(yùn)維成本。有一個(gè)較為形象的類比，如果說現(xiàn)在的網(wǎng)絡(luò)系統(tǒng)是功能機(jī)，系統(tǒng)和硬件出廠時(shí)就被捆綁在一起，那么 SDN 就是 Android 系統(tǒng)，可以在很多手機(jī)設(shè)備上安裝&升級(jí)，同時(shí)還能安裝更多更強(qiáng)大的手機(jī) App（SDN 應(yīng)用層部署）。

　　回到移動(dòng)應(yīng)用領(lǐng)域，我們的目標(biāo)是搭建統(tǒng)一的終端網(wǎng)絡(luò)解決方案，上層業(yè)務(wù)不需要關(guān)心內(nèi)部的協(xié)議如何轉(zhuǎn)發(fā)、請(qǐng)求超時(shí)降級(jí)等復(fù)雜邏輯，做到好用、易用、可觀測(cè)、體驗(yàn)好。顯然，這與傳統(tǒng) SDN 架構(gòu)理念不謀而合。

　　2.2 AWCN 終端網(wǎng)絡(luò)架構(gòu)

　　因此，圍繞以上理念和目標(biāo)，我們進(jìn)一步構(gòu)建起南北向從監(jiān)測(cè)到加速一體化的 MobileSDN 架構(gòu)，以減少業(yè)務(wù)的接入/運(yùn)維成本，提升用戶的瀏覽體驗(yàn)。

　　圖：AWCN Mobile-SDN 架構(gòu)

　　從 MobileSDN 架構(gòu)展開來，接下來簡要介紹下各分層模塊承擔(dān)的角色與其中作用。

　　網(wǎng)絡(luò)應(yīng)用：面向多種應(yīng)用場(chǎng)景衍生出的網(wǎng)絡(luò)組件，如統(tǒng)一 RPC 網(wǎng)關(guān)（MTOP）、消息 PUSH 通道（ACCS）、上傳（AUS）、下載（TBDownloader）、圖片加載（Phenix）、遠(yuǎn)程配置（Orange）等能力；網(wǎng)絡(luò)北向接口：上層調(diào)用和內(nèi)部實(shí)現(xiàn)的橋梁，提供統(tǒng)一同步/異步對(duì)外 API 接口和無痕 Hook 方式，用于上層網(wǎng)絡(luò)應(yīng)用/業(yè)務(wù)場(chǎng)景接入調(diào)用網(wǎng)絡(luò)基礎(chǔ)能力；網(wǎng)絡(luò)控制器：請(qǐng)求策略管控中心，架構(gòu)大腦，負(fù)責(zé)請(qǐng)求端到端鏈路的調(diào)度和優(yōu)化決策，有著舉足輕重的作用，控制器提供完備的網(wǎng)絡(luò)加速能力，從節(jié)點(diǎn)調(diào)度/連接選擇/請(qǐng)求管理多個(gè)環(huán)節(jié)進(jìn)行網(wǎng)絡(luò)請(qǐng)求加速；網(wǎng)絡(luò)南向接口：控制面與基礎(chǔ)協(xié)議轉(zhuǎn)發(fā)的橋梁，對(duì)協(xié)議及數(shù)據(jù)進(jìn)行了通用抽象，以應(yīng)對(duì)不同系統(tǒng)框架/不同協(xié)議的統(tǒng)一處理；網(wǎng)絡(luò)協(xié)議轉(zhuǎn)發(fā)：多個(gè)基礎(chǔ)協(xié)議和網(wǎng)絡(luò)框架的統(tǒng)一適配實(shí)現(xiàn)，兼容各類請(qǐng)求場(chǎng)景下的最優(yōu)選擇調(diào)度，支持標(biāo)準(zhǔn) HTTP/1.1、HTTP/2、HTTP/3，以及集團(tuán)自研的 HTTP/2+SSSL 和 H3-XQUIC 協(xié)議；網(wǎng)絡(luò)性能管理：網(wǎng)絡(luò)數(shù)據(jù)及性能觀測(cè)中心，NPM（Network Performance Management），負(fù)責(zé)設(shè)備網(wǎng)絡(luò)狀態(tài)/質(zhì)量/信號(hào)強(qiáng)度的感知、業(yè)務(wù)請(qǐng)求數(shù)據(jù)的統(tǒng)計(jì)上報(bào)、PING/TRACE/NSLookup 等網(wǎng)絡(luò)時(shí)延探測(cè)診斷、用戶網(wǎng)絡(luò)診斷/請(qǐng)求抓包等工具建設(shè)。

　　2.3 行業(yè)分析

　　縱觀行業(yè)內(nèi)一些與之對(duì)標(biāo)的移動(dòng)網(wǎng)絡(luò)框架，如騰訊維納斯 WNS、微信 Mars、Chromium cornet、Square Okhttp 等，AWCN 和它們?cè)谝恍┧悸飞峡梢哉f是殊途同歸，通過提供更優(yōu)的 IP 策略調(diào)度、多協(xié)議連接管理策略及請(qǐng)求超時(shí)等控制加速請(qǐng)求，建設(shè)網(wǎng)絡(luò)診斷、網(wǎng)絡(luò)質(zhì)量監(jiān)控等手段加強(qiáng)網(wǎng)絡(luò)可觀測(cè)能力。

　　微信 Mars：STN 負(fù)責(zé)請(qǐng)求任務(wù)管理/IP 排序/網(wǎng)絡(luò)策略等能力優(yōu)化請(qǐng)求體驗(yàn)，SDT 為網(wǎng)絡(luò)診斷模塊，一定程度上與 AWCN 中網(wǎng)絡(luò)控制器、網(wǎng)絡(luò)性能管理兩塊部分承擔(dān)角色相近。

　　圖：微信 Mars 基礎(chǔ)架構(gòu)

　　2.4 規(guī)模總覽

　　淘寶統(tǒng)一網(wǎng)絡(luò)庫作為基礎(chǔ)組件在集團(tuán)內(nèi)被廣泛應(yīng)用，集團(tuán)內(nèi)涵蓋千級(jí)以上規(guī)模應(yīng)用支撐，包含且不限于手淘、閑魚、優(yōu)酷、天貓、Lazada、高德、UC瀏覽器、餓了么等 APP，同時(shí)通過阿里云 EMAS、友盟對(duì)三方應(yīng)用開放接入，如海底撈/杭州銀行等企業(yè)應(yīng)用。

　　作為移動(dòng)網(wǎng)絡(luò)解決方案，網(wǎng)絡(luò)請(qǐng)求的體驗(yàn)是重中之重，因此，筆者將重點(diǎn)講述網(wǎng)絡(luò)控制器如何圍繞請(qǐng)求構(gòu)建完整鏈路上的加速技術(shù)，介紹如何從節(jié)點(diǎn)調(diào)度/連接選擇/請(qǐng)求管理/系統(tǒng)調(diào)度進(jìn)行業(yè)務(wù)網(wǎng)絡(luò)體驗(yàn)優(yōu)化，確保請(qǐng)求在各類復(fù)雜網(wǎng)絡(luò)狀況下高可用。

　　3. 網(wǎng)絡(luò)加速體系詳解

　　前面提到，網(wǎng)絡(luò)控制器是作為整體架構(gòu)上的大腦，承擔(dān)著請(qǐng)求端到端鏈路的調(diào)度和優(yōu)化決策，相當(dāng)于掌舵手和發(fā)動(dòng)機(jī)的角色。一次完整的請(qǐng)求網(wǎng)絡(luò)傳輸大致可以分為以下鏈路，即DNS->建連->發(fā)送數(shù)據(jù)->等待首包響應(yīng)->接收數(shù)據(jù)，過程中 IP 策略調(diào)度、連接管理、請(qǐng)求管理及廠商全局調(diào)度加速子模塊各承擔(dān)著不同的作用，筆者將逐一介紹闡述。

　　圖：各模塊在一次調(diào)用過程的作用域

　　IP 策略調(diào)度：負(fù)責(zé) IP/節(jié)點(diǎn)的選擇和調(diào)度，職責(zé)是選擇最優(yōu)的 IP 策略，減少 DNS 帶來的耗時(shí)，同時(shí)具備切流容災(zāi)的能力；連接及協(xié)議管理：負(fù)責(zé)連接池生命周期的管理和各類協(xié)議的選擇，職責(zé)是連接擇優(yōu)且高可用；請(qǐng)求管理：負(fù)責(zé)請(qǐng)求的調(diào)度，涵蓋超時(shí)、降級(jí)、重試恢復(fù)等流程控制，職責(zé)是讓請(qǐng)求更快的被執(zhí)行；廠商加速：負(fù)責(zé)對(duì)接各大廠商系統(tǒng)側(cè)的網(wǎng)絡(luò)能力，結(jié)合系統(tǒng)賦予的網(wǎng)絡(luò)加速能力（如更精準(zhǔn)的網(wǎng)絡(luò)質(zhì)量狀態(tài)/雙頻 WiFi 聚合加速/流加速等），進(jìn)一步優(yōu)化復(fù)雜網(wǎng)絡(luò)下請(qǐng)求調(diào)度的策略決策，是自研與廠商原生網(wǎng)絡(luò)能力之間的溝通樞紐。

　　3.1 IP 策略調(diào)度：減少 DNS 耗時(shí)，選擇更優(yōu) IP

　　眾所周知，傳統(tǒng)的 LocalDNS 方式存在各類隱患問題，如：解析慢/失敗率高、更新不及時(shí)、域名劫持、缺少精準(zhǔn)流量調(diào)度及容災(zāi)能力，AMDC（Ali Mobile Dispatch Center）是阿里自建的無線域名解析調(diào)度服務(wù)，在手淘和集團(tuán)絕大多數(shù)應(yīng)用中廣泛應(yīng)用。

　　依托 HTTPDNS 實(shí)現(xiàn)無線調(diào)度功能就夠了嗎？遠(yuǎn)沒有那么理想化，如何在端側(cè)處理好 IP 策略的選取/容災(zāi)/安全性/服務(wù) QPS 壓力等環(huán)節(jié)，都至關(guān)重要。

　　IP 選取及緩存汰換策略

　　IP 選擇機(jī)制上，基于服務(wù)下發(fā)+端側(cè)動(dòng)態(tài)排序的機(jī)制運(yùn)行

　　服務(wù)端下發(fā)：根據(jù)單元化/運(yùn)營商/就近接入/網(wǎng)絡(luò)協(xié)議棧等維度，下發(fā)一組可用的 IP 列表。同時(shí)具備通過端側(cè)跑馬算法，生成最優(yōu)的策略 IP。端側(cè)動(dòng)態(tài)排序：根據(jù)端側(cè) IP 策略使用記錄（成功&失敗&耗時(shí)等維度）進(jìn)行優(yōu)先級(jí)排序，建連錯(cuò)誤次數(shù)多的策略在排序優(yōu)先級(jí)上進(jìn)行降權(quán)操作，與之相對(duì)應(yīng)的，建連成功率高性能好的策略優(yōu)先級(jí)提高。

　　緩存和汰換機(jī)制上，考慮到頻繁 AMDC 調(diào)度帶來服務(wù)壓力、異步請(qǐng)求 AMDC 帶來的生效率問題，端側(cè)對(duì)策略進(jìn)行了緩存，根據(jù)用戶網(wǎng)絡(luò)粒度進(jìn)行獨(dú)立存儲(chǔ)，應(yīng)用啟動(dòng)和網(wǎng)絡(luò)事件切換情況下加載所需的策略記錄；根據(jù)前面所提及的建連記錄動(dòng)態(tài)排序能力，自然也產(chǎn)生了對(duì)應(yīng)的淘汰替換機(jī)制。

　　淘汰機(jī)制：同一 IP 在 5min 中連續(xù)失敗 xx 次，進(jìn)入禁用淘汰的情況更新機(jī)制：域名粒度攜帶 TTL（Time To Live）下發(fā)，超過 TTL 的域名進(jìn)行異步更新，同時(shí)更新機(jī)制按照域名的優(yōu)先級(jí)也擁有不同的模式。

　　新態(tài)勢(shì)下的挑戰(zhàn)及升級(jí)

　　CASE 1：高版本設(shè)備對(duì)于 WiFi 網(wǎng)絡(luò)唯一標(biāo)識(shí)的獲取限制

　　前面提及的端側(cè)緩存策略基于用戶網(wǎng)絡(luò)粒度做獨(dú)立存儲(chǔ)，對(duì)于 WiFi 網(wǎng)絡(luò)環(huán)境 BSSID 是端側(cè)的標(biāo)識(shí)主鍵，但隨著系統(tǒng)升級(jí)帶來的一系列用戶權(quán)限收斂：

　　Android 8 及以上版本開始，需要用戶授權(quán)定位等權(quán)限，才可以拿到 Wi-Fi SSID/BSSID 等相關(guān)信息，否則返回 02:00:00:00:00:00 默認(rèn)值iOS 14 起，必須接入 network extension，否則無論通過任何手段都無法獲取到 wifi 相關(guān)信息，對(duì)接 NE 成本太高。

　　這意味著現(xiàn)有網(wǎng)絡(luò)存儲(chǔ)結(jié)構(gòu)不再具備唯一標(biāo)識(shí)用戶網(wǎng)絡(luò)的能力，無法正常獲取 BSSID 信息的這些設(shè)備上存在著策略混用，甚至跨運(yùn)營商的問題，從而導(dǎo)致請(qǐng)求性能變慢/出現(xiàn)異常，線上約有 20%+的用戶受潛在影響。因此，對(duì)于端側(cè)無法直接獲取 BSSID 的設(shè)備，引入新的存儲(chǔ)主 key，即用戶無線接入點(diǎn) AccessPoint 信息，流程涉及 AMDC 端到端協(xié)同升級(jí)，大致流程如圖所示。

　　圖：WIFI 存儲(chǔ)升級(jí)改造流程

　　數(shù)據(jù)上，圖片等 CDN 類請(qǐng)求平均耗時(shí)優(yōu)化 4.439%，耗時(shí)分位 P90 優(yōu)化1.932%，P99 優(yōu)化 2.230%，P999 優(yōu)化 2.668% 。

　　CASE 2: 應(yīng)對(duì)更復(fù)雜協(xié)議/更精細(xì)化調(diào)度訴求下的協(xié)議演進(jìn)

　　當(dāng)現(xiàn)有協(xié)議結(jié)構(gòu)無法滿足日益復(fù)雜和精細(xì)的調(diào)度訴求，且無法在現(xiàn)有模型上持續(xù)長期迭代時(shí)，就需要對(duì)協(xié)議進(jìn)行重構(gòu)升級(jí)。我們?cè)谝苿?dòng)網(wǎng)絡(luò)虛擬化項(xiàng)目中切實(shí)遇到如上的問題，協(xié)議重構(gòu)對(duì)于端上來說，是對(duì)整個(gè)存儲(chǔ)數(shù)據(jù)模型的改變，這意味著升級(jí)新協(xié)議的用戶可能無法繼續(xù)使用舊版本存儲(chǔ)策略，直接丟棄老協(xié)議存儲(chǔ)是最簡單有效的手段，但這會(huì)導(dǎo)致升級(jí)后一段時(shí)間內(nèi)用戶出現(xiàn)降級(jí) LocalDNS 的問題，這對(duì)我們不能容忍。

　　重新實(shí)現(xiàn)一個(gè)協(xié)議不難，難的是如何確保新老協(xié)議平穩(wěn)升級(jí)過渡，避免請(qǐng)求出現(xiàn) LocalDNS 降級(jí)。因此，方案的關(guān)鍵在于如何對(duì)新老協(xié)議做數(shù)據(jù)遷移，其中涉及升級(jí)鏈路和降級(jí)鏈路(如穩(wěn)定性問題功能回退場(chǎng)景)。

　　圖：AMDC 存儲(chǔ)數(shù)據(jù)遷移

　　3.2 連接管理：更快建連，保障連接高可用

　　連接建立

　　除了常規(guī)的串行建連和并發(fā)建連方式，我們提供了熱域名預(yù)建和復(fù)合連接的方式，應(yīng)對(duì)各種復(fù)雜的場(chǎng)景。

　　熱域名預(yù)建機(jī)制：啟動(dòng)場(chǎng)景下的關(guān)鍵請(qǐng)求加速

　　圖：熱域名預(yù)建

　　復(fù)合連接機(jī)制：IPv6 規(guī)模化背景下的體驗(yàn)保障

　　當(dāng)手淘作為 IPv6 示范性應(yīng)用跑在最前面時(shí)，我們發(fā)現(xiàn)國內(nèi)存在部分雙棧網(wǎng)絡(luò) IPv6 質(zhì)量差甚至不通的情況，Android 的輿情反饋尤為突出，原因在于 iOS 系統(tǒng)側(cè)實(shí)現(xiàn)了 Happy Eyeballs 機(jī)制確保快速 rollback 回 IPv4 鏈路，而 Android 設(shè)備沒有。

　　復(fù)合連接思路也因此來源于 IPv6 Happy Eyeballs 算法實(shí)現(xiàn)，詳見RFC 6555[1]。

　　When a servers IPv4 path and protocol are working, but the servers IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual-stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm.

　　圖：雙棧復(fù)合連接

　　復(fù)合連接的兩個(gè)核心目標(biāo)：

　　雙棧環(huán)境體驗(yàn)：從 IPv6 和 IPv4 中為用戶選擇一個(gè)最快的鏈接，且保證優(yōu)先使用 IPv6減少后端壓力：避免同時(shí)對(duì)兩地址發(fā)起請(qǐng)求，造成網(wǎng)絡(luò)破壞；

　　數(shù)據(jù)上，針對(duì) MTOP 和圖片請(qǐng)求，雙棧情況下其建連性能平均耗時(shí)降低 22.12%，99 分位性能降低 60.19%，請(qǐng)求數(shù)據(jù)平均耗時(shí)降低了1.23%，P99 分位耗時(shí)降低 6.077%。

　　連接調(diào)度

　　按照不同的通道應(yīng)用場(chǎng)景，連接可以區(qū)分為兩種形態(tài)，?；钸B接與常規(guī)連接。

　　保活連接：需要時(shí)刻保證連接存活，隨時(shí)可用，適用于上下行推拉結(jié)合的場(chǎng)景，如消息；常規(guī)連接：不需要時(shí)刻?；?，空閑及時(shí)回收減少資源占用，適用于僅主動(dòng)上行調(diào)用的場(chǎng)景，如 RPC。

　　針對(duì)建立好的連接，不同形態(tài)的維護(hù)管理方式也不同。

　　面向?；羁捎茫杭龠B檢測(cè)，動(dòng)態(tài)心跳

　　通過對(duì)連接的多場(chǎng)景可用性檢測(cè)，增強(qiáng)連接質(zhì)量的感知，當(dāng)出現(xiàn)連接異常時(shí)能夠快速的恢復(fù)重建。

　　檢測(cè)的手段基本為心跳 PING 包方式，分位定時(shí)心跳（前后臺(tái)間隔不同）、分場(chǎng)景心跳（切換前臺(tái)、業(yè)務(wù)上行超時(shí)等）。

　　面向空閑回收：閑時(shí)狀態(tài)檢查，及時(shí)關(guān)閉

　　對(duì)于不需要主動(dòng)下行推送的場(chǎng)景，建連時(shí)刻保持對(duì)于用戶帶寬和功耗存在一定影響，因此針對(duì)此類連接增加了空閑狀態(tài)的檢查，當(dāng)發(fā)現(xiàn)建連超過一定時(shí)間沒有數(shù)據(jù)包傳輸時(shí)會(huì)進(jìn)行連接的關(guān)閉回收，以減少資源占用，釋放有限帶寬。

　　3.3 請(qǐng)求管理：彈性超時(shí)控制，請(qǐng)求補(bǔ)償恢復(fù)

　　動(dòng)態(tài)超時(shí)

　　精細(xì)控制：在請(qǐng)求各個(gè)鏈路上，具有獨(dú)立超時(shí)控制，每個(gè)階段精細(xì)化控制，快速感知超時(shí)情況；動(dòng)態(tài)調(diào)配：針對(duì) 不同域名請(qǐng)求/網(wǎng)絡(luò)類型/不同質(zhì)量 的環(huán)境下動(dòng)態(tài)超時(shí)時(shí)長處理。

　　圖：請(qǐng)求各階段超時(shí)控制

　　多路競(jìng)爭(zhēng)&擇優(yōu)選用

　　對(duì)于請(qǐng)求超時(shí)或慢的場(chǎng)景，AWCN 會(huì)通過多種方式進(jìn)行擇優(yōu)選用和請(qǐng)求補(bǔ)償，確保鏈路最優(yōu)，保障體驗(yàn)：

　　傳輸協(xié)議：運(yùn)營商對(duì)于 HTTP/3（UDP）的網(wǎng)絡(luò)質(zhì)量保證遠(yuǎn)不及 TCP，常常遇到各類 UDP 穿透性、請(qǐng)求超時(shí)等問題，因此必要時(shí)需快速?zèng)Q策，切回 HTTP/2、HTTP/1.1 的 TCP 傳輸鏈路；底層框架：自研傳輸庫(TNET)帶來的好處是協(xié)議的自建和調(diào)優(yōu)，但也因此導(dǎo)致協(xié)議非標(biāo)(如 HTTP/2+SSSL 私有加密協(xié)議)，運(yùn)營商攔截丟包、端到端鏈路穩(wěn)定性等問題，必要時(shí)決策回退至系統(tǒng)原生庫；網(wǎng)絡(luò)通道：以往對(duì)于用戶網(wǎng)絡(luò)不通導(dǎo)致的問題，優(yōu)化的手段有限，但隨著系統(tǒng)開放多通道選擇的能力之后，上層也擁有了切換網(wǎng)絡(luò)通道的能力，當(dāng)檢測(cè) WiFi 不通環(huán)境下，會(huì)將請(qǐng)求切換至蜂窩網(wǎng)絡(luò)通道恢復(fù)。

　　以傳輸協(xié)議擇優(yōu)選用為例，對(duì)于 H3 協(xié)議在手淘的規(guī)?；^程用戶體驗(yàn)不受損，AWCN 網(wǎng)絡(luò)庫建立起完善的擇優(yōu)選用和補(bǔ)償兜底機(jī)制。

　　圖：H3 規(guī)?；^程中的體驗(yàn)保障

　　3.4 廠商加速：擁抱原生，系統(tǒng)級(jí)調(diào)度加速

　　近年來，國內(nèi)幾家廠商前后對(duì)上層應(yīng)用開放了系統(tǒng)級(jí)的網(wǎng)絡(luò)優(yōu)化能力，包括網(wǎng)絡(luò)帶寬調(diào)度、數(shù)據(jù)流加速、QoE 狀態(tài)反饋、弱網(wǎng)預(yù)測(cè)、雙 WiFi 聚合能力等，從系統(tǒng)側(cè)調(diào)度提升請(qǐng)求性能。

　　廠商能力融合的思考與決策

　　作為淘寶終端網(wǎng)絡(luò)基礎(chǔ)設(shè)施，一直以來我們都專精于應(yīng)用策略及協(xié)議上，致力如何更好的調(diào)度、管理連接/協(xié)議讓請(qǐng)求更快。隨著國內(nèi)廠商的發(fā)展，我們發(fā)現(xiàn)，脫離廠商的自研之路并不順暢：

　　一方面，不同廠商的限制和表現(xiàn)異同常讓我們對(duì)各廠商做一些 hack 和兼容性的事情；另一方面，用戶的網(wǎng)絡(luò)資源有限，手淘作為單一應(yīng)用，能調(diào)配和控制的資源有限。如何擴(kuò)大我們的調(diào)度域得以讓我們的應(yīng)用內(nèi)請(qǐng)求更好，是我們常在思考的事情。

　　因此我們選擇擁抱廠商，通過系統(tǒng)賦予的調(diào)度加速能力，深度合作，為應(yīng)用提供更好的網(wǎng)絡(luò)體驗(yàn)。

　　為了屏蔽不同廠商之間的能力差異和接入方式不同，AWCN 提供廠商加速模塊的通用能力抽象，通過運(yùn)行期對(duì)不同設(shè)備和廠商能力的解決，動(dòng)態(tài)組織支持的系統(tǒng)能力列表。

　　圖：廠商加速接入架構(gòu)

　　目前，我們已經(jīng)和 OPPO 完成接入和上線工作，協(xié)同廠商側(cè)緊鑼密鼓的放量驗(yàn)證中。

　　4. 手淘弱網(wǎng)破障實(shí)踐

　　4.1 指標(biāo)定義：明確弱網(wǎng)/卡頓請(qǐng)求

　　過往我們基于網(wǎng)絡(luò)請(qǐng)求 1s 法則作為優(yōu)化的指標(biāo)衡量，目前業(yè)務(wù)請(qǐng)求秒出率超過 95%，當(dāng)網(wǎng)絡(luò)體驗(yàn)進(jìn)入深水區(qū)，弱網(wǎng)/長尾等卡頓負(fù)向請(qǐng)求成為我們關(guān)注和突破重點(diǎn)。

　　圖：網(wǎng)絡(luò)請(qǐng)求 1s 法則

　　弱網(wǎng)作為廣義的概念，有多方面的原因，一般來說我們把用戶網(wǎng)絡(luò)波動(dòng)、信號(hào)強(qiáng)度弱、時(shí)延 RT 大稱之為弱網(wǎng)環(huán)境。對(duì)于用戶來說，最大的體感就是各類頁面打開慢、加載久、圖片空窗等問題，請(qǐng)求耗時(shí)久/異常是直接原因。我們從請(qǐng)求端到端全鏈路進(jìn)行逐一分析，除了網(wǎng)絡(luò)傳輸、后端服務(wù)處理耗時(shí)，也存在一些業(yè)務(wù)本地處理/回調(diào)等執(zhí)行的耗時(shí)。

　　圖：請(qǐng)求全鏈路階段

　　通過梳理完整請(qǐng)求的調(diào)用鏈路，我們?cè)谒伎既绾瓮ㄟ^指標(biāo)化的方式衡量出這部分對(duì)業(yè)務(wù)/用戶體驗(yàn)有損的請(qǐng)求，在明確目前線上相關(guān)負(fù)向卡頓請(qǐng)求的規(guī)模的前提下，再進(jìn)行進(jìn)一步的優(yōu)化及效果觀測(cè)。

　　因此，基于用戶/業(yè)務(wù)視角，將請(qǐng)求全鏈路階段內(nèi)出現(xiàn)異常報(bào)錯(cuò)、耗時(shí)長尾定義為卡頓請(qǐng)求：

　　異常報(bào)錯(cuò)：失敗的請(qǐng)求，無論何種原因失敗，網(wǎng)絡(luò)超時(shí)、服務(wù)端未返回等；耗時(shí)長尾：響應(yīng)超過 xx 秒未返回、沒有結(jié)束的請(qǐng)求。

　　4.2 診斷體系：更快識(shí)別、定位各類復(fù)雜網(wǎng)絡(luò)問題

　　經(jīng)常有一些線上用戶反饋網(wǎng)絡(luò)類的輿情：

　　為什么 WIFI 下訪問慢，切換到 4G 網(wǎng)絡(luò)就恢復(fù)了？我的網(wǎng)絡(luò)沒問題，為什么手淘等淘系應(yīng)用加載慢，其他 APP 正常？為什么 xx 頁面加載很慢，其他頁面沒問題？。。。

　　其中導(dǎo)致的原因很多，如用戶路由器的配置、淘系域名被營商 IP 封禁、業(yè)務(wù)調(diào)用鏈路超時(shí)等，為了更好的定位/分析各類網(wǎng)絡(luò)類問題， 我們針對(duì)移動(dòng)互聯(lián)網(wǎng)下用戶網(wǎng)絡(luò)類體驗(yàn)問題的復(fù)雜性，進(jìn)一步建設(shè) NPM 診斷技術(shù)體系，加強(qiáng)相關(guān)技術(shù)和數(shù)據(jù)的應(yīng)用。

　　領(lǐng)域模型：用戶體驗(yàn)問題的技術(shù)面窮舉拆解、沉淀；能力構(gòu)建：診斷原子能力及工具鏈，運(yùn)維提效；規(guī)模應(yīng)用：多維用戶網(wǎng)絡(luò)數(shù)據(jù)，IPv6/MTU/UDP 大盤。

　　圖：多場(chǎng)景網(wǎng)絡(luò)體驗(yàn)類問題診斷體系

　　4.3 弱網(wǎng)技術(shù)：復(fù)雜網(wǎng)絡(luò)下的網(wǎng)絡(luò)體驗(yàn)

　　針對(duì)移動(dòng)復(fù)雜網(wǎng)絡(luò)環(huán)境，除了前面網(wǎng)絡(luò)加速體系所提到的相關(guān)能力之外，這里筆者將重點(diǎn)對(duì)典型弱網(wǎng)靶向性優(yōu)化技術(shù)展開。

　　4.3.1 網(wǎng)絡(luò)多通道：手淘規(guī)?；瘧?yīng)用

　　當(dāng)請(qǐng)求沒有響應(yīng)/接收慢的情況下，一般會(huì)觸發(fā)超時(shí)機(jī)制進(jìn)行請(qǐng)求重放。但在用戶 WIFI 信號(hào)差&弱網(wǎng)環(huán)境下，我們反而要謹(jǐn)慎重試，一方面重試會(huì)加重系統(tǒng)上的負(fù)載，另一方面重試會(huì)導(dǎo)致請(qǐng)求重新開始，對(duì)弱網(wǎng)傳輸慢的情況不友好，反而加劇卡慢的情況。

　　因此，在尋求更友好的方式上，我們發(fā)現(xiàn)系統(tǒng)提供了一種多通道傳輸?shù)哪芰Γ丛试S設(shè)備在 WIFI 環(huán)境下將請(qǐng)求切換蜂窩網(wǎng)卡的能力，網(wǎng)絡(luò)應(yīng)用層可以利用該技術(shù)，減少請(qǐng)求的超時(shí)等一類錯(cuò)誤，提升請(qǐng)求的成功率。

　　圖：系統(tǒng)官方文檔

　　規(guī)?；桨?/p>

　　除了常規(guī)的技術(shù)應(yīng)用，因?yàn)樯婕暗接脩粼?WIFI 網(wǎng)絡(luò)下的流量損耗，我們遵從用戶隱私等合規(guī)前提下，提供多通道能力生效的用戶提示和功能授權(quán)。

　　圖：多通道整體規(guī)模化方案

　　優(yōu)化數(shù)據(jù)

　　目前多通道技術(shù)在手淘核心瀏覽鏈路上已規(guī)?；瘧?yīng)用，嚴(yán)格按照AB 實(shí)驗(yàn)得出數(shù)據(jù)，雙十一期間雙端日對(duì)請(qǐng)求超時(shí)率減少 30%以上。

　　4.3.2 原生 HTTP/2：突破系統(tǒng)限制，實(shí)現(xiàn) H2 協(xié)議支持

　　相對(duì)于 HTTP/1.1 協(xié)議，HTTP/2、HTTP/3 的協(xié)議性能優(yōu)勢(shì)不言而喻，HTTP/2 協(xié)議在手淘和集團(tuán)內(nèi)早已支持多年，HTTP/3 協(xié)議同樣在持續(xù)規(guī)模擴(kuò)量中，但目前手淘內(nèi)仍然存有 10%左右 HTTP1.1 流量。

　　通過分析，主要有以下原因?qū)е拢?/p>

　　1.HTTP/2 協(xié)議非標(biāo)準(zhǔn)化實(shí)現(xiàn)，加密方式為私有 slight-ssl，域名支持需服務(wù)端部署，未明確知曉是否支持的域名只能走 HTTP/1.1 協(xié)議；

　　2.鑒于非標(biāo)的影響，請(qǐng)求鏈路上需要強(qiáng)依賴 AMDC，必須通過 AMDC 配置明確支持 h2+sssl 方式的域名下發(fā)后才能支持；

　　3.非標(biāo)協(xié)議的兼容性存在小概率問題，個(gè)別運(yùn)營商針對(duì)非標(biāo)協(xié)議會(huì)進(jìn)行劫持處理導(dǎo)致請(qǐng)求失敗降級(jí)到短連。

　　過往很多業(yè)務(wù)反饋，為什么域名在 chrome 瀏覽器上訪問支持 HTTP/2，而手淘里是仍然是 HTTP/1.1 的原因就在于此。那么，如何在不需要服務(wù)端部署、不強(qiáng)依賴 AMDC 的前提下，讓請(qǐng)求實(shí)現(xiàn)長連加速？標(biāo)準(zhǔn) HTTP2 的實(shí)現(xiàn)是必經(jīng)之路。

　　如何支持標(biāo)準(zhǔn) HTTP/2？

　　iOS 通過升級(jí) URLSession 系統(tǒng)調(diào)用方式，可低成本的遷移到 H2/H3 協(xié)議上，但對(duì)于 Android 來說，系統(tǒng)側(cè)提供的 HttpUrlconnection 僅支持到 HTTP/1.1 協(xié)議。因此，靈魂三問：

　　標(biāo)準(zhǔn)協(xié)議的完整實(shí)現(xiàn)，必然要加入人力投入開發(fā)，穩(wěn)定性驗(yàn)證和上線是一個(gè)較長的周期，如何減少支持的成本？考慮引入穩(wěn)定的能力實(shí)現(xiàn)，如 Okhttp。穩(wěn)定庫引入必定會(huì)增加包大小，這對(duì)目前嚴(yán)控包大小的現(xiàn)狀有較大沖突，如何解決？需盡可能不增加包大小的情況下支持。既要考慮成本和穩(wěn)定性驗(yàn)證等規(guī)?；瘑栴}，又要避免給手淘包大小過大的增幅。既要馬兒跑，又要馬兒不吃草。如何實(shí)現(xiàn)？

　　源碼突破

　　通過對(duì)系統(tǒng)源碼的分析，我們發(fā)現(xiàn) Android 系統(tǒng) 5.0 之后，系統(tǒng) API HttpUrlconnection 底層已經(jīng)通過 okhttp 進(jìn)行托管實(shí)現(xiàn)，也就是說 Android 系統(tǒng)本身支持通過 okhttp 訪問不需要額外引入三方庫進(jìn)行，只要找到可以 hook 的點(diǎn)。

　　圖：Android 網(wǎng)絡(luò)托管 Okhttp 代理

　　進(jìn)一步分析源代碼，我們找到了 okhttp 在 android 系統(tǒng)側(cè)的位置和包名，即com.android.okhttp下。

　　圖：Android Okhttp 源碼實(shí)現(xiàn)

　　雖然是隱藏 API，仍可以通過反射的方式進(jìn)行，為了更友好的編碼實(shí)現(xiàn)，在編譯期通過空實(shí)現(xiàn)依賴的方式進(jìn)行顯式的調(diào)用，同時(shí)確保在使用前對(duì)設(shè)備 okhttp 的環(huán)境及兼容性做好檢查。

　　遭遇系統(tǒng) bug

　　圖：Android Okhttp crash

　　灰度過程我們發(fā)現(xiàn)一些因?yàn)?Okhttp 導(dǎo)致的 IndexOutOfBoundsException 穩(wěn)定性問題，bug 來源于特定場(chǎng)景下沒有拿到證書列表且未對(duì)容器判空導(dǎo)致，詳細(xì)記錄在：http://github.com/square/okhttp/issues/4208。

　　官方在版本 3.12.2+上修復(fù)，但 android 源碼仍使用 2.x 版本導(dǎo)致無法修復(fù)。

　　圖：okhttp 導(dǎo)致 IndexOutOfBoundsException 代碼

　　為了規(guī)避系統(tǒng)側(cè)問題，我們摒棄 okhttp 提供異步調(diào)用的 api，改為同步調(diào)用+異常捕獲+上層轉(zhuǎn)異步的方式進(jìn)行處理。

　　此外，針對(duì)不同應(yīng)用，若存在三方 okhttp 依賴，會(huì)自動(dòng)橋接到三方實(shí)現(xiàn)上，體驗(yàn)高版本 okhttp 的穩(wěn)定性；對(duì)于手淘這種不依賴三方 okhttp 的應(yīng)用，再橋接到系統(tǒng)版本實(shí)現(xiàn)。

　　優(yōu)化數(shù)據(jù)

　　標(biāo)準(zhǔn) H2 升級(jí)率先在 Feeds 接口域名覆蓋，農(nóng)場(chǎng)整體輿情月環(huán)比下降 23%，請(qǐng)求耗時(shí)優(yōu)化 21.4%，成功率提升 0.3pt。

　　4.4 小結(jié)

　　截至目前，日改善卡頓請(qǐng)求(網(wǎng)絡(luò)錯(cuò)誤/耗時(shí)>x 秒) PV 10 億+ ，達(dá)成全年目標(biāo) 10 億(統(tǒng)計(jì)口徑嚴(yán)格按照 AB 實(shí)驗(yàn)桶對(duì)比計(jì)算)，MOTP 請(qǐng)求超時(shí)率較去年 4 月優(yōu)化了近50%。

　　5. 后續(xù)方向與展望

　　對(duì)于移動(dòng)網(wǎng)絡(luò)體驗(yàn)的探索是無止境的，今年我們圍繞弱網(wǎng)和體驗(yàn)加速做了一些工作，有些內(nèi)容因?yàn)槠蛡?cè)重點(diǎn)考慮所以沒有進(jìn)一步展開講述，后期再通過另外專題文章進(jìn)行側(cè)重講解。

　　但即便如此，面對(duì)億萬用戶各類復(fù)雜多變的環(huán)境，仍存在著加載慢、卡頓、空白的聲音，作為淘寶和集團(tuán)統(tǒng)一的終端基礎(chǔ)網(wǎng)絡(luò)設(shè)施，如何讓用戶瀏覽體驗(yàn)再更上一層樓，我們要做的還很多。

　　5.1 更精準(zhǔn)的網(wǎng)絡(luò)狀態(tài)感知

　　準(zhǔn)確掌握用戶的網(wǎng)絡(luò)狀態(tài)是一切手段的前提，以往我們圍繞 NPM 搭建診斷體系，對(duì)端到端鏈路的連通性和質(zhì)量進(jìn)行檢測(cè)，在實(shí)時(shí)性、準(zhǔn)確度和可用性仍有提升空間。

　　結(jié)合廠商系統(tǒng)側(cè)更精準(zhǔn)可靠的網(wǎng)絡(luò)質(zhì)量反饋：依托提供 QoE 網(wǎng)絡(luò)質(zhì)量能力，提供更實(shí)時(shí)的 WiFi/蜂窩網(wǎng)絡(luò)信號(hào)質(zhì)量和強(qiáng)度反饋;提供用戶更友好的網(wǎng)絡(luò)感知手段：當(dāng)用戶出現(xiàn)“潛在”的網(wǎng)絡(luò)問題，我們希望大部分情況用戶可以自行知道哪里出問題、怎么解決。

　　圖：用戶網(wǎng)絡(luò)診斷感知

　　5.2 更動(dòng)態(tài)智能的調(diào)度加速能力

　　針對(duì)不同網(wǎng)絡(luò)類型和質(zhì)量的環(huán)境，我們希望建設(shè)更適應(yīng)性更動(dòng)態(tài)智能的調(diào)度能力，基于不同場(chǎng)景做更適合有效的加速能力應(yīng)用，一成不變，固化的優(yōu)化策略無法在所有的環(huán)境下發(fā)揮更優(yōu)的效果。前面提到，當(dāng)我們能夠更精準(zhǔn)感知，甚至預(yù)測(cè)用戶網(wǎng)絡(luò)的變化，我們能夠做的事情就更多。

　　圖：預(yù)測(cè)弱網(wǎng)環(huán)境的動(dòng)態(tài)調(diào)優(yōu)

　　5.3 更一致的弱網(wǎng)交互體驗(yàn)

　　我們發(fā)現(xiàn)手淘多業(yè)務(wù)在弱網(wǎng)交互下表現(xiàn)不一，存在著無法刷新重試、空白無提示、阻塞無法操作等問題，因此除了技術(shù)側(cè)的能力強(qiáng)化，會(huì)進(jìn)一步聯(lián)合多方沉淀弱網(wǎng)體驗(yàn)規(guī)范，協(xié)同業(yè)務(wù)優(yōu)化弱網(wǎng)場(chǎng)景下的表現(xiàn)與體驗(yàn)、提升交互性和可恢復(fù)性，并改善用戶在弱網(wǎng)下的預(yù)期和感受。

　　圖：手淘弱網(wǎng)交互表現(xiàn)不一

　　參考資料

　　[1]

　　RFC 6555: http://www.rfc-editor.org/rfc/rfc6555

　　作者:沈良煒(沛軒)

　　來源:微信公眾號(hào):阿里巴巴終端技術(shù)

　　出處

　　:http://mp.weixin.qq.com/s/YomDksoRv_Chuw7oHBzzFA

  今天的分享就到這里了，想了解更多關(guān)于淘寶代運(yùn)營公司、福建淘寶代運(yùn)營等內(nèi)容，敬請(qǐng)關(guān)注火蝠電商官網(wǎng)。