本文由大淘寶終端平臺技術(shù)團(tuán)隊沈良煒(沛軒)分享，本文有修訂和改動。

1、引言

自 2013 年 ALLIN 無線到今天，已經(jīng)走過 10 個年頭，淘寶終端統(tǒng)一網(wǎng)絡(luò)庫 AWCN (Ali Wireless Connection Network) 從淘內(nèi)孵化，一路過來伴隨著淘寶業(yè)務(wù)的發(fā)展，經(jīng)歷集團(tuán) IPv6 戰(zhàn)役、協(xié)議升級演進(jìn)等，逐步沉淀為阿里集團(tuán)終端網(wǎng)絡(luò)通用解決方案，是兼具高性能、多協(xié)議、可容災(zāi)、可觀測的終端網(wǎng)絡(luò)基礎(chǔ)統(tǒng)一設(shè)施。

面對移動互聯(lián)網(wǎng)絡(luò)下復(fù)雜多變的網(wǎng)絡(luò)環(huán)境，如何提供更穩(wěn)定可靠的請求性能，保障用戶的加載瀏覽體驗、更好的支撐業(yè)務(wù)發(fā)展，是我們始終探索的命題。

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

* 推薦閱讀：《百度統(tǒng)一socket長連接組件從0到1的技術(shù)實踐》。

?

?技術(shù)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4470-1-1.html）

2、本文作者

本文由大淘寶終端平臺技術(shù)團(tuán)隊沈良煒（沛軒）分享。

大淘寶終端平臺技術(shù)團(tuán)隊，主要負(fù)責(zé)淘寶移動域中間件/原生技術(shù)挖掘/核心技術(shù)建設(shè)，包括不限于客戶端體驗/框架及創(chuàng)新體驗/廠商與系統(tǒng)技術(shù)/用戶增長及移動平臺等，支撐億萬流量的移動網(wǎng)絡(luò)接入。

3、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)用軟件可以參與對網(wǎng)絡(luò)的控制管理，滿足上層業(yè)務(wù)需求，簡化使用和運維成本。

有一個較為形象的類比，如果說現(xiàn)在的網(wǎng)絡(luò)系統(tǒng)是功能機(jī)，系統(tǒng)和硬件出廠時就被捆綁在一起，那么 SDN 就是 Android 系統(tǒng)，可以在很多手機(jī)設(shè)備上安裝&升級，同時還能安裝更多更強(qiáng)大的手機(jī) App（SDN 應(yīng)用層部署）。

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

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

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

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

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

1）網(wǎng)絡(luò)應(yīng)用：面向多種應(yīng)用場景衍生出的網(wǎng)絡(luò)組件，如統(tǒng)一 RPC 網(wǎng)關(guān)（MTOP）、消息 PUSH 通道（ACCS）、上傳（AUS）、下載（TBDownloader）、圖片加載（Phenix）、遠(yuǎn)程配置（Orange）等能力。

2）網(wǎng)絡(luò)北向接口：上層調(diào)用和內(nèi)部實現(xiàn)的橋梁，提供統(tǒng)一同步/異步對外 API 接口和無痕 Hook 方式，用于上層網(wǎng)絡(luò)應(yīng)用/業(yè)務(wù)場景接入調(diào)用網(wǎng)絡(luò)基礎(chǔ)能力。

3）網(wǎng)絡(luò)控制器：請求策略管控中心，架構(gòu)大腦，負(fù)責(zé)請求端到端鏈路的調(diào)度和優(yōu)化決策，有著舉足輕重的作用，控制器提供完備的網(wǎng)絡(luò)加速能力，從節(jié)點調(diào)度/連接選擇/請求管理多個環(huán)節(jié)進(jìn)行網(wǎng)絡(luò)請求加速。

4）網(wǎng)絡(luò)南向接口：控制面與基礎(chǔ)協(xié)議轉(zhuǎn)發(fā)的橋梁，對協(xié)議及數(shù)據(jù)進(jìn)行了通用抽象，以應(yīng)對不同系統(tǒng)框架/不同協(xié)議的統(tǒng)一處理。

5）網(wǎng)絡(luò)協(xié)議轉(zhuǎn)發(fā)：多個基礎(chǔ)協(xié)議和網(wǎng)絡(luò)框架的統(tǒng)一適配實現(xiàn)，兼容各類請求場景下的最優(yōu)選擇調(diào)度，支持標(biāo)準(zhǔn) HTTP/1.1、HTTP/2、HTTP/3，以及集團(tuán)自研的 HTTP/2+SSSL 和 H3-XQUIC 協(xié)議。

6）網(wǎng)絡(luò)性能管理：網(wǎng)絡(luò)數(shù)據(jù)及性能觀測中心，NPM（Network Performance Management），負(fù)責(zé)設(shè)備網(wǎng)絡(luò)狀態(tài)/質(zhì)量/信號強(qiáng)度的感知、業(yè)務(wù)請求數(shù)據(jù)的統(tǒng)計上報、PING/TRACE/NSLookup 等網(wǎng)絡(luò)時延探測診斷、用戶網(wǎng)絡(luò)診斷/請求抓包等工具建設(shè)。

5、市面上的同類方案分析

縱觀行業(yè)內(nèi)一些與之對標(biāo)的移動網(wǎng)絡(luò)框架，如騰訊維納斯 WNS、微信 Mars（《如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》）、Chromium cronet、Square Okhttp 等，AWCN 和它們在一些思路上可以說是殊途同歸，通過提供更優(yōu)的 IP 策略調(diào)度、多協(xié)議連接管理策略及請求超時等控制加速請求，建設(shè)網(wǎng)絡(luò)診斷、網(wǎng)絡(luò)質(zhì)量監(jiān)控等手段加強(qiáng)網(wǎng)絡(luò)可觀測能力。

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

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

（圖片引用自《如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》）

6、淘寶統(tǒng)一網(wǎng)絡(luò)庫的應(yīng)用情況

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

作為移動網(wǎng)絡(luò)解決方案，網(wǎng)絡(luò)請求的體驗是重中之重。

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

7、網(wǎng)絡(luò)加速體系概覽

前面提到：網(wǎng)絡(luò)控制器是作為整體架構(gòu)上的大腦，承擔(dān)著請求端到端鏈路的調(diào)度和優(yōu)化決策，相當(dāng)于掌舵手和發(fā)動機(jī)的角色。

一次完整的請求網(wǎng)絡(luò)傳輸大致可以分為以下鏈路：即DNS->建連->發(fā)送數(shù)據(jù)->等待首包響應(yīng)->接收數(shù)據(jù)。過程中 IP 策略調(diào)度、連接管理、請求管理及廠商全局調(diào)度加速子模塊各承擔(dān)著不同的作用，筆者將逐一介紹闡述。

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

具體解讀就是：

1）IP 策略調(diào)度：負(fù)責(zé) IP/節(jié)點的選擇和調(diào)度，職責(zé)是選擇最優(yōu)的 IP 策略，減少 DNS 帶來的耗時，同時具備切流容災(zāi)的能力；

2）連接及協(xié)議管理：負(fù)責(zé)連接池生命周期的管理和各類協(xié)議的選擇，職責(zé)是連接擇優(yōu)且高可用；

3）請求管理：負(fù)責(zé)請求的調(diào)度，涵蓋超時、降級、重試恢復(fù)等流程控制，職責(zé)是讓請求更快的被執(zhí)行；

4）廠商加速：負(fù)責(zé)對接各大廠商系統(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ò)下請求調(diào)度的策略決策，是自研與廠商原生網(wǎng)絡(luò)能力之間的溝通樞紐。

8、網(wǎng)絡(luò)加速體系之IP策略調(diào)度

8.1 概述

IP策略調(diào)度的目的是減少 DNS 耗時，選擇更優(yōu) IP。

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

PS：關(guān)于HttpDNS的技術(shù)文章可詳讀：

《全面了解移動端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》

《百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(一)：DNS優(yōu)化篇》

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

8.2 IP 選取及緩存汰換策略

IP 選擇機(jī)制上（基于服務(wù)下發(fā)+端側(cè)動態(tài)排序的機(jī)制運行）：

• 1）服務(wù)端下發(fā)：根據(jù)單元化/運營商/就近接入/網(wǎng)絡(luò)協(xié)議棧等維度，下發(fā)一組可用的 IP 列表。同時具備通過端側(cè)跑馬算法，生成最優(yōu)的策略 IP；

• 2）端側(cè)動態(tài)排序：根據(jù)端側(cè) IP 策略使用記錄（成功&失敗&耗時等維度）進(jìn)行優(yōu)先級排序，建連錯誤次數(shù)多的策略在排序優(yōu)先級上進(jìn)行降權(quán)操作，與之相對應(yīng)的，建連成功率高性能好的策略優(yōu)先級提高。

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

• 1）淘汰機(jī)制：同一 IP 在 5min 中連續(xù)失敗 xx 次，進(jìn)入禁用淘汰的情況；

• 2）更新機(jī)制：域名粒度攜帶 TTL（Time To Live）下發(fā)，超過 TTL 的域名進(jìn)行異步更新，同時更新機(jī)制按照域名的優(yōu)先級也擁有不同的模式。

8.3 新態(tài)勢下的挑戰(zhàn)及升級

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

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

具體是：

• 1）Android 8 及以上版本開始，需要用戶授權(quán)定位等權(quán)限，才可以拿到 Wi-Fi SSID/BSSID 等相關(guān)信息，否則返回 02:00:00:00:00:00 默認(rèn)值；

• 2）iOS 14 起，必須接入 network extension，否則無論通過任何手段都無法獲取到 wifi 相關(guān)信息，對接 NE 成本太高。

這意味著現(xiàn)有網(wǎng)絡(luò)存儲結(jié)構(gòu)不再具備唯一標(biāo)識用戶網(wǎng)絡(luò)的能力，無法正常獲取 BSSID 信息的這些設(shè)備上存在著策略混用，甚至跨運營商的問題，從而導(dǎo)致請求性能變慢/出現(xiàn)異常，線上約有 20%+的用戶受潛在影響。

因此，對于端側(cè)無法直接獲取 BSSID 的設(shè)備，引入新的存儲主 key，即用戶無線接入點 AccessPoint 信息，流程涉及 AMDC 端到端協(xié)同升級，大致流程如下圖所示。

WIFI 存儲升級改造流程：

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

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

當(dāng)現(xiàn)有協(xié)議結(jié)構(gòu)無法滿足日益復(fù)雜和精細(xì)的調(diào)度訴求，且無法在現(xiàn)有模型上持續(xù)長期迭代時，就需要對協(xié)議進(jìn)行重構(gòu)升級。

我們在移動網(wǎng)絡(luò)虛擬化項目中切實遇到如上的問題，協(xié)議重構(gòu)對于端上來說，是對整個存儲數(shù)據(jù)模型的改變，這意味著升級新協(xié)議的用戶可能無法繼續(xù)使用舊版本存儲策略，直接丟棄老協(xié)議存儲是最簡單有效的手段，但這會導(dǎo)致升級后一段時間內(nèi)用戶出現(xiàn)降級 LocalDNS 的問題，這對我們不能容忍。

重新實現(xiàn)一個協(xié)議不難，難的是如何確保新老協(xié)議平穩(wěn)升級過渡，避免請求出現(xiàn) LocalDNS 降級。

因此，方案的關(guān)鍵在于如何對新老協(xié)議做數(shù)據(jù)遷移，其中涉及升級鏈路和降級鏈路（如穩(wěn)定性問題功能回退場景）。

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

9、網(wǎng)絡(luò)加速體系之連接管理

連接管理的目的是更快建連，保障連接高可用。

9.1 連接建立

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

熱域名預(yù)建機(jī)制（啟動場景下的關(guān)鍵請求加速）：

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

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

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

When a server's IPv4 path and protocol are working, but the server's 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ù)合連接的兩個核心目標(biāo)：

• 1）雙棧環(huán)境體驗：從 IPv6 和 IPv4 中為用戶選擇一個最快的鏈接，且保證優(yōu)先使用 IPv6；

• 2）減少后端壓力：避免同時對兩地址發(fā)起請求，造成網(wǎng)絡(luò)破壞。

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

9.2 連接調(diào)度

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

具體是：

• 1）?；钸B接：需要時刻保證連接存活，隨時可用，適用于上下行推拉結(jié)合的場景，如消息；

• 2）常規(guī)連接：不需要時刻?；?，空閑及時回收減少資源占用，適用于僅主動上行調(diào)用的場景，如 RPC。

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

面向?；羁捎茫?/strong>

• 1）假連檢測；

• 2）動態(tài)心跳。

動態(tài)心跳具體是指：通過對連接的多場景可用性檢測，增強(qiáng)連接質(zhì)量的感知，當(dāng)出現(xiàn)連接異常時能夠快速的恢復(fù)重建。

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

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

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

PS：之前分享很多有關(guān)IM長接的心跳技術(shù)文章，技術(shù)原理都差不多，可以一并閱讀：

《一文讀懂即時通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機(jī)制：作用、原理、實現(xiàn)思路等》

《微信團(tuán)隊原創(chuàng)分享：Android版微信后臺?；顚崙?zhàn)分享(網(wǎng)絡(luò)?；钇?》

《移動端IM實踐：實現(xiàn)Android版微信的智能心跳機(jī)制》

《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》

《融云技術(shù)分享：融云安卓端IM產(chǎn)品的網(wǎng)絡(luò)鏈路保活技術(shù)實踐》

《一種Android端IM智能心跳算法的設(shè)計與實現(xiàn)探討（含樣例代碼）》

《跟著源碼學(xué)IM(五)：正確理解IM長連接、心跳及重連機(jī)制，并動手實現(xiàn)》

《萬字長文：手把手教你實現(xiàn)一套高效的IM長連接自適應(yīng)心跳?；顧C(jī)制》

10、 網(wǎng)絡(luò)加速體系之請求管理

請求管理的目的是彈性超時控制，請求補(bǔ)償恢復(fù)。

10.1 動態(tài)超時

具體是：

• 1）精細(xì)控制：在請求各個鏈路上，具有獨立超時控制，每個階段精細(xì)化控制，快速感知超時情況；

• 2）動態(tài)調(diào)配：針對 不同域名請求/網(wǎng)絡(luò)類型/不同質(zhì)量 的環(huán)境下動態(tài)超時時長處理。

請求各階段超時控制：

10.2 多路競爭 & 擇優(yōu)選用

對于請求超時或慢的場景，AWCN 會通過多種方式進(jìn)行擇優(yōu)選用和請求補(bǔ)償，確保鏈路最優(yōu)，保障體驗。

具體做法是：

1）傳輸協(xié)議：運營商對于 HTTP/3（UDP）的網(wǎng)絡(luò)質(zhì)量保證遠(yuǎn)不及 TCP，常常遇到各類 UDP 穿透性、請求超時等問題，因此必要時需快速決策，切回 HTTP/2、HTTP/1.1 的 TCP 傳輸鏈路；

2）底層框架：自研傳輸庫(TNET)帶來的好處是協(xié)議的自建和調(diào)優(yōu)，但也因此導(dǎo)致協(xié)議非標(biāo)(如 HTTP/2+SSSL 私有加密協(xié)議)，運營商攔截丟包、端到端鏈路穩(wěn)定性等問題，必要時決策回退至系統(tǒng)原生庫；

3）網(wǎng)絡(luò)通道：以往對于用戶網(wǎng)絡(luò)不通導(dǎo)致的問題，優(yōu)化的手段有限，但隨著系統(tǒng)開放多通道選擇的能力之后，上層也擁有了切換網(wǎng)絡(luò)通道的能力，當(dāng)檢測 WiFi 不通環(huán)境下，會將請求切換至蜂窩網(wǎng)絡(luò)通道恢復(fù)。

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

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

11、網(wǎng)絡(luò)加速體系之廠商加速

廠商加速的目的是擁抱原生，系統(tǒng)級調(diào)度加速。

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

以下是廠商能力融合的思考與決策。

作為淘寶終端網(wǎng)絡(luò)基礎(chǔ)設(shè)施，一直以來我們都專精于應(yīng)用策略及協(xié)議上，致力如何更好的調(diào)度、管理連接/協(xié)議讓請求更快。

隨著國內(nèi)廠商的發(fā)展，我們發(fā)現(xiàn)，脫離廠商的自研之路并不順暢：

• 1）一方面，不同廠商的限制和表現(xiàn)異同常讓我們對各廠商做一些 hack 和兼容性的事情；

• 2）另一面，用戶的網(wǎng)絡(luò)資源有限，手淘作為單一應(yīng)用，能調(diào)配和控制的資源有限。

如何擴(kuò)大我們的調(diào)度域得以讓我們的應(yīng)用內(nèi)請求更好，是我們常在思考的事情。

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

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

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

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

12、弱網(wǎng)優(yōu)化指標(biāo)定義

弱網(wǎng)優(yōu)化指標(biāo)定義的目的是明確弱網(wǎng)/卡頓請求。

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

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

弱網(wǎng)作為廣義的概念，有多方面的原因。

一般來說我們把用戶網(wǎng)絡(luò)波動、信號強(qiáng)度弱、時延 RT 大稱之為弱網(wǎng)環(huán)境。

對于用戶來說，最大的體感就是各類頁面打開慢、加載久、圖片空窗等問題，請求耗時久/異常是直接原因。

我們從請求端到端全鏈路進(jìn)行逐一分析，除了網(wǎng)絡(luò)傳輸、后端服務(wù)處理耗時，也存在一些業(yè)務(wù)本地處理/回調(diào)等執(zhí)行的耗時。

請求全鏈路階段：

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

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

具體是：

• 1）異常報錯：失敗的請求，無論何種原因失敗，網(wǎng)絡(luò)超時、服務(wù)端未返回等；

• 2）耗時長尾：響應(yīng)超過 xx 秒未返回、沒有結(jié)束的請求。

PS：關(guān)于弱網(wǎng)的技術(shù)文章可以深入詳讀：

《現(xiàn)代移動端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應(yīng)、安全保障》

《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”》

《移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

《美圖App的移動端DNS優(yōu)化實踐：HTTPS請求耗時減小近半》

《百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(三)：移動端弱網(wǎng)優(yōu)化篇》

《愛奇藝移動端網(wǎng)絡(luò)優(yōu)化實踐分享：網(wǎng)絡(luò)請求成功率優(yōu)化篇》

《美團(tuán)點評的移動端網(wǎng)絡(luò)優(yōu)化實踐：大幅提升連接成功率、速度等》

《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十四)：高鐵上無線上網(wǎng)有多難？一文即懂！》

13、弱網(wǎng)優(yōu)化診斷體系

弱網(wǎng)優(yōu)化診斷體系的目的是更快識別、定位各類復(fù)雜網(wǎng)絡(luò)問題。

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

• 1）為什么 WIFI 下訪問慢，切換到 4G 網(wǎng)絡(luò)就恢復(fù)了？

• 2）我的網(wǎng)絡(luò)沒問題，為什么手淘等淘系應(yīng)用加載慢，其他 APP 正常？

• 3）為什么 xx 頁面加載很慢，其他頁面沒問題？

• 4）......

其中導(dǎo)致的原因很多，如用戶路由器的配置、淘系域名被營商 IP 封禁、業(yè)務(wù)調(diào)用鏈路超時等。

為了更好的定位/分析各類網(wǎng)絡(luò)類問題， 我們針對移動互聯(lián)網(wǎng)下用戶網(wǎng)絡(luò)類體驗問題的復(fù)雜性，進(jìn)一步建設(shè) NPM 診斷技術(shù)體系，加強(qiáng)相關(guān)技術(shù)和數(shù)據(jù)的應(yīng)用。

比如：

1）領(lǐng)域模型：用戶體驗問題的技術(shù)面窮舉拆解、沉淀；

2）能力構(gòu)建：診斷原子能力及工具鏈，運維提效；

3）規(guī)模應(yīng)用：多維用戶網(wǎng)絡(luò)數(shù)據(jù)，IPv6/MTU/UDP 大盤。

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

14、弱網(wǎng)優(yōu)化技術(shù)實踐

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

14.1 網(wǎng)絡(luò)多通道

當(dāng)請求沒有響應(yīng)/接收慢的情況下，一般會觸發(fā)超時機(jī)制進(jìn)行請求重放。

但在用戶 WIFI 信號差&弱網(wǎng)環(huán)境下，我們反而要謹(jǐn)慎重試，一方面重試會加重系統(tǒng)上的負(fù)載，另一方面重試會導(dǎo)致請求重新開始，對弱網(wǎng)傳輸慢的情況不友好，反而加劇卡慢的情況。

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

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

14.2 規(guī)模化方案

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

多通道整體規(guī)?；桨福?/strong>

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

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

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

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

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

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

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

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

過往很多業(yè)務(wù)反饋，為什么域名在 chrome 瀏覽器上訪問支持 HTTP/2，而手淘里是仍然是 HTTP/1.1 的原因就在于此。

那么，如何在不需要服務(wù)端部署、不強(qiáng)依賴 AMDC 的前提下，讓請求實現(xiàn)長連加速？標(biāo)準(zhǔn) HTTP2 的實現(xiàn)是必經(jīng)之路。

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

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

因此，靈魂三問：

• 1）標(biāo)準(zhǔn)協(xié)議的完整實現(xiàn)，必然要加入人力投入開發(fā)，穩(wěn)定性驗證和上線是一個較長的周期，如何減少支持的成本？考慮引入穩(wěn)定的能力實現(xiàn)，如 Okhttp；

• 2）穩(wěn)定庫引入必定會增加包大小，這對目前嚴(yán)控包大小的現(xiàn)狀有較大沖突，如何解決？需盡可能不增加包大小的情況下支持；

• 3）既要考慮成本和穩(wěn)定性驗證等規(guī)?；瘑栴}，又要避免給手淘包大小過大的增幅。既要馬兒跑，又要馬兒不吃草。如何實現(xiàn)？

14.6 源碼突破

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

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

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

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

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

Android Okhttp crash：

灰度過程我們發(fā)現(xiàn)一些因為 Okhttp 導(dǎo)致的?IndexOutOfBoundsException?穩(wěn)定性問題，bug 來源于特定場景下沒有拿到證書列表且未對容器判空導(dǎo)致，詳細(xì)記錄在：https://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)行處理。

此外，針對不同應(yīng)用：

1）若存在三方 okhttp 依賴，會自動橋接到三方實現(xiàn)上，體驗高版本 okhttp 的穩(wěn)定性；

2）對于手淘這種不依賴三方 okhttp 的應(yīng)用，再橋接到系統(tǒng)版本實現(xiàn)。

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

15、手淘弱網(wǎng)優(yōu)化效果

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

16、后續(xù)方向與展望

16.1 概述

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

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

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

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

結(jié)合廠商系統(tǒng)側(cè)更精準(zhǔn)可靠的網(wǎng)絡(luò)質(zhì)量反饋：依托提供 QoE 網(wǎng)絡(luò)質(zhì)量能力，提供更實時的 WiFi/蜂窩網(wǎng)絡(luò)信號質(zhì)量和強(qiáng)度反饋。

提供用戶更友好的網(wǎng)絡(luò)感知手段：當(dāng)用戶出現(xiàn)“潛在”的網(wǎng)絡(luò)問題，我們希望大部分情況用戶可以自行知道哪里出問題、怎么解決。

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

16.3 更動態(tài)智能的調(diào)度加速能力

針對不同網(wǎng)絡(luò)類型和質(zhì)量的環(huán)境，我們希望建設(shè)更適應(yīng)性更動態(tài)智能的調(diào)度能力，基于不同場景做更適合有效的加速能力應(yīng)用，一成不變，固化的優(yōu)化策略無法在所有的環(huán)境下發(fā)揮更優(yōu)的效果。

前面提到，當(dāng)我們能夠更精準(zhǔn)感知，甚至預(yù)測用戶網(wǎng)絡(luò)的變化，我們能夠做的事情就更多。

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

16.4 更一致的弱網(wǎng)交互體驗

我們發(fā)現(xiàn)淘寶多業(yè)務(wù)在弱網(wǎng)交互下表現(xiàn)不一，存在著無法刷新重試、空白無提示、阻塞無法操作等問題。

因此除了技術(shù)側(cè)的能力強(qiáng)化，會進(jìn)一步聯(lián)合多方沉淀弱網(wǎng)體驗規(guī)范，協(xié)同業(yè)務(wù)優(yōu)化弱網(wǎng)場景下的表現(xiàn)與體驗、提升交互性和可恢復(fù)性，并改善用戶在弱網(wǎng)下的預(yù)期和感受。

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

17、參考資料

[1]?RFC 6555

[2]?全面了解移動端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》

[3]?百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(一)：DNS優(yōu)化篇》

[4]?如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源

[5]?從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計思路

[6]?一文讀懂即時通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機(jī)制：作用、原理、實現(xiàn)思路等》

[7]?微信團(tuán)隊原創(chuàng)分享：Android版微信后臺?；顚崙?zhàn)分享(網(wǎng)絡(luò)?；钇?》

[8]?移動端IM實踐：實現(xiàn)Android版微信的智能心跳機(jī)制》

[9]?移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》

[10]?融云技術(shù)分享：融云安卓端IM產(chǎn)品的網(wǎng)絡(luò)鏈路?；罴夹g(shù)實踐》

[11]?一種Android端IM智能心跳算法的設(shè)計與實現(xiàn)探討（含樣例代碼）》

[12]?跟著源碼學(xué)IM(五)：正確理解IM長連接、心跳及重連機(jī)制，并動手實現(xiàn)》

[13]?萬字長文：手把手教你實現(xiàn)一套高效的IM長連接自適應(yīng)心跳保活機(jī)制》

[14]?現(xiàn)代移動端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應(yīng)、安全保障》

[15]?移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”》

[16]?移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

[17]?美圖App的移動端DNS優(yōu)化實踐：HTTPS請求耗時減小近半》

[18]?百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(三)：移動端弱網(wǎng)優(yōu)化篇》

[19]?愛奇藝移動端網(wǎng)絡(luò)優(yōu)化實踐分享：網(wǎng)絡(luò)請求成功率優(yōu)化篇》

[20]?美團(tuán)點評的移動端網(wǎng)絡(luò)優(yōu)化實踐：大幅提升連接成功率、速度等》

[21]?IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十四)：高鐵上無線上網(wǎng)有多難？一文即懂！》

（本文已同步發(fā)布于：http://www.52im.net/thread-4470-1-1.html）

標(biāo)簽：