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

1、引言

自 2013 年 ALLIN 無(wú)線(xiàn)到今天，已經(jīng)走過(guò) 10 個(gè)年頭，淘寶終端統(tǒng)一網(wǎng)絡(luò)庫(kù) AWCN (Ali Wireless Connection Network) 從淘?xún)?nèi)孵化，一路過(guò)來(lá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)求性能，保障用戶(hù)的加載瀏覽體驗(yàn)、更好的支撐業(yè)務(wù)發(fā)展，是我們始終探索的命題。

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

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

2、本文作者

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

大淘寶終端平臺(tái)技術(shù)團(tuán)隊(duì)，主要負(fù)責(zé)淘寶移動(dòng)域中間件/原生技術(shù)挖掘/核心技術(shù)建設(shè)，包括不限于客戶(hù)端體驗(yàn)/框架及創(chuàng)新體驗(yàn)/廠商與系統(tǒng)技術(shù)/用戶(hù)增長(zhǎng)及移動(dòng)平臺(tái)等，支撐億萬(wàn)流量的移動(dòng)網(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ò)控制功能分開(kāi)，其目標(biāo)是創(chuàng)建可集中管理和可編程的網(wǎng)絡(luò)，核心理念是希望應(yīng)用軟件可以參與對(duì)網(wǎng)絡(luò)的控制管理，滿(mǎn)足上層業(yè)務(wù)需求，簡(jiǎn)化使用和運(yùn)維成本。

有一個(gè)較為形象的類(lèi)比，如果說(shuō)現(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)理念不謀而合。

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

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

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

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

1）網(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）等能力。

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

3）網(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)求加速。

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

5）網(wǎng)絡(luò)協(xié)議轉(zhuǎn)發(fā)：多個(gè)基礎(chǔ)協(xié)議和網(wǎng)絡(luò)框架的統(tǒng)一適配實(shí)現(xiàn)，兼容各類(lèi)請(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é)議。

6）網(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è)診斷、用戶(hù)網(wǎng)絡(luò)診斷/請(qǐng)求抓包等工具建設(shè)。

5、市面上的同類(lèi)方案分析

縱觀行業(yè)內(nèi)一些與之對(duì)標(biāo)的移動(dòng)網(wǎng)絡(luò)框架，如騰訊維納斯 WNS、微信 Mars（《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺(tái)組件庫(kù)Mars已正式開(kāi)源》）、Chromium cronet、Square Okhttp 等，AWCN 和它們?cè)谝恍┧悸飞峡梢哉f(shuō)是殊途同歸，通過(guò)提供更優(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)：

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

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

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

7、網(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ù)。過(guò)程中 IP 策略調(diào)度、連接管理、請(qǐng)求管理及廠商全局調(diào)度加速子模塊各承擔(dān)著不同的作用，筆者將逐一介紹闡述。

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

具體解讀就是：

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

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

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

4）廠商加速：負(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ò)能力之間的溝通樞紐。

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

8.1 概述

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

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

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

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

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

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

8.2 IP 選取及緩存汰換策略

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

• 1）服務(wù)端下發(fā)：根據(jù)單元化/運(yùn)營(yíng)商/就近接入/網(wǎng)絡(luò)協(xié)議棧等維度，下發(fā)一組可用的 IP 列表。同時(shí)具備通過(guò)端側(cè)跑馬算法，生成最優(yōu)的策略 IP；
• 2）端側(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)的，建連成功率高性能好的策略?xún)?yōu)先級(jí)提高。

緩存和汰換機(jī)制上（考慮到頻繁 AMDC 調(diào)度帶來(lái)服務(wù)壓力、異步請(qǐng)求 AMDC 帶來(lái)的生效率問(wèn)題，端側(cè)對(duì)策略進(jìn)行了緩存，根據(jù)用戶(hù)網(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ī)制）：

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

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

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

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

具體是：

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

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

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

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

數(shù)據(jù)上，圖片等 CDN 類(lèi)請(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)無(wú)法滿(mǎn)足日益復(fù)雜和精細(xì)的調(diào)度訴求，且無(wú)法在現(xiàn)有模型上持續(xù)長(zhǎng)期迭代時(shí)，就需要對(duì)協(xié)議進(jìn)行重構(gòu)升級(jí)。

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

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

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

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

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

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

9.1 連接建立

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

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

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

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

復(fù)合連接思路也因此來(lái)源于 IPv6 Happy Eyeballs 算法實(shí)現(xiàn)，詳見(jià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ù)合連接的兩個(gè)核心目標(biāo)：

• 1）雙棧環(huán)境體驗(yàn)：從 IPv6 和 IPv4 中為用戶(hù)選擇一個(gè)最快的鏈接，且保證優(yōu)先使用 IPv6；
• 2）減少后端壓力：避免同時(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%。

9.2 連接調(diào)度

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

具體是：

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

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

面向保活可用：

• 1）假連檢測(cè)；
• 2）動(dòng)態(tài)心跳。

動(dòng)態(tài)心跳具體是指：通過(guò)對(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ì)于用戶(hù)帶寬和功耗存在一定影響，因此針對(duì)此類(lèi)連接增加了空閑狀態(tài)的檢查，當(dāng)發(fā)現(xiàn)建連超過(guò)一定時(shí)間沒(méi)有數(shù)據(jù)包傳輸時(shí)會(huì)進(jìn)行連接的關(guān)閉回收，以減少資源占用，釋放有限帶寬。

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

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

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)保活實(shí)戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》

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

《移動(dòng)端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》

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

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

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

《萬(wàn)字長(zhǎng)文：手把手教你實(shí)現(xiàn)一套高效的IM長(zhǎng)連接自適應(yīng)心跳保活機(jī)制》

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

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

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

具體是：

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

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

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

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

具體做法是：

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

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

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

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

H3 規(guī)模化過(guò)程中的體驗(yàn)保障：

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

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

近年來(lái)，國(guó)內(nèi)幾家廠商前后對(duì)上層應(yīng)用開(kāi)放了系統(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è)施，一直以來(lái)我們都專(zhuān)精于應(yīng)用策略及協(xié)議上，致力如何更好的調(diào)度、管理連接/協(xié)議讓請(qǐng)求更快。

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

• 1）一方面，不同廠商的限制和表現(xiàn)異同常讓我們對(duì)各廠商做一些 hack 和兼容性的事情；
• 2）另一面，用戶(hù)的網(wǎng)絡(luò)資源有限，手淘作為單一應(yīng)用，能調(diào)配和控制的資源有限。

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

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

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

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

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

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

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

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

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

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

一般來(lái)說(shuō)我們把用戶(hù)網(wǎng)絡(luò)波動(dòng)、信號(hào)強(qiáng)度弱、時(shí)延 RT 大稱(chēng)之為弱網(wǎng)環(huán)境。

對(duì)于用戶(hù)來(lái)說(shuō)，最大的體感就是各類(lèi)頁(yè)面打開(kāi)慢、加載久、圖片空窗等問(wèn)題，請(qǐng)求耗時(shí)久/異常是直接原因。

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

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

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

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

具體是：

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

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

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

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

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

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

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

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

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

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

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

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

經(jīng)常有一些線(xiàn)上用戶(hù)反饋網(wǎng)絡(luò)類(lèi)的輿情：

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

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

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

比如：

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

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

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

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

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

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

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

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

但在用戶(hù) WIFI 信號(hào)差&弱網(wǎng)環(huán)境下，我們反而要謹(jǐn)慎重試，一方面重試會(huì)加重系統(tǒng)上的負(fù)載，另一方面重試會(huì)導(dǎo)致請(qǐng)求重新開(kāi)始，對(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í)等一類(lèi)錯(cuò)誤，提升請(qǐng)求的成功率。

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

14.2 規(guī)模化方案

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

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

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

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

14.4 原生 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 流量。

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

• 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)依賴(lài) AMDC，必須通過(guò) AMDC 配置明確支持 h2+sssl 方式的域名下發(fā)后才能支持；
• 3）非標(biāo)協(xié)議的兼容性存在小概率問(wèn)題，個(gè)別運(yùn)營(yíng)商針對(duì)非標(biāo)協(xié)議會(huì)進(jìn)行劫持處理導(dǎo)致請(qǐng)求失敗降級(jí)到短連。

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

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

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

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

因此，靈魂三問(wèn)：

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

14.6 源碼突破

通過(guò)對(duì)系統(tǒng)源碼的分析，我們發(fā)現(xiàn) Android 系統(tǒng) 5.0 之后，系統(tǒng) API HttpUrlconnection 底層已經(jīng)通過(guò) okhttp 進(jìn)行托管實(shí)現(xiàn)，也就是說(shuō) Android 系統(tǒng)本身支持通過(guò) okhttp 訪(fǎng)問(wèn)不需要額外引入三方庫(kù)進(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，仍可以通過(guò)反射的方式進(jìn)行，為了更友好的編碼實(shí)現(xiàn)，在編譯期通過(guò)空實(shí)現(xiàn)依賴(lài)的方式進(jìn)行顯式的調(diào)用，同時(shí)確保在使用前對(duì)設(shè)備 okhttp 的環(huán)境及兼容性做好檢查。

Android Okhttp crash：

灰度過(guò)程我們發(fā)現(xiàn)一些因?yàn)?Okhttp 導(dǎo)致的 IndexOutOfBoundsException 穩(wěn)定性問(wèn)題，bug 來(lái)源于特定場(chǎng)景下沒(méi)有拿到證書(shū)列表且未對(duì)容器判空導(dǎo)致，詳細(xì)記錄在：https://github.com/square/okhttp/issues/4208。官方在版本 3.12.2+上修復(fù)，但 android 源碼仍使用 2.x 版本導(dǎo)致無(wú)法修復(fù)。

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

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

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

1）若存在三方 okhttp 依賴(lài)，會(huì)自動(dòng)橋接到三方實(shí)現(xiàn)上，體驗(yàn)高版本 okhttp 的穩(wěn)定性；

2）對(duì)于手淘這種不依賴(lài)三方 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。

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

截至目前，日改善卡頓請(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%。

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

16.1 概述

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

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

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

準(zhǔn)確掌握用戶(hù)的網(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)度反饋。

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

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

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

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

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

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

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

我們發(fā)現(xiàn)淘寶多業(yè)務(wù)在弱網(wǎng)交互下表現(xiàn)不一，存在著無(wú)法刷新重試、空白無(wú)提示、阻塞無(wú)法操作等問(wè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ù)性，并改善用戶(hù)在弱網(wǎng)下的預(yù)期和感受。

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

17、參考資料

[1] RFC 6555

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

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

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

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

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

[7] 微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)保活實(shí)戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》

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

[9] 移動(dòng)端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》

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

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

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

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

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

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

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

[17] 美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半》

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

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

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

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

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