1. 引言

　　自 2013 年 ALLIN 無線到今天，已經(jīng)走過 10 個年頭，手淘終端統(tǒng)一網(wǎng)絡(luò)庫 AWCN (Ali Wireless Connection Network) 從淘內(nèi)孵化，一路過來伴隨著手淘業(yè)務(wù)的發(fā)展，經(jīng)歷集團 IPv6 戰(zhàn)役、協(xié)議升級演進等，逐步沉淀為阿里集團終端網(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ò)庫演進的過程，講述如何圍繞體驗持續(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)造更多的可能性。

　　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ò)控制功能分開，其目標是創(chuàng)建可集中管理和可編程的網(wǎng)絡(luò)，核心理念是 希望應(yīng)用軟件可以參與對網(wǎng)絡(luò)的控制管理，滿足上層業(yè)務(wù)需求，簡化使用和運維成本。有一個較為形象的類比，如果說現(xiàn)在的網(wǎng)絡(luò)系統(tǒng)是功能機，系統(tǒng)和硬件出廠時就被捆綁在一起，那么 SDN 就是 Android 系統(tǒng)，可以在很多手機設(shè)備上安裝&升級，同時還能安裝更多更強大的手機 App（SDN 應(yīng)用層部署）。

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

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

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

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

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

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

　　2.3 行業(yè)分析

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

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

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

　　2.4 規(guī)?？傆[

　　淘寶統(tǒng)一網(wǎng)絡(luò)庫作為基礎(chǔ)組件在集團內(nèi)被廣泛應(yīng)用，集團內(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)度進行業(yè)務(wù)網(wǎng)絡(luò)體驗優(yōu)化，確保請求在各類復(fù)雜網(wǎng)絡(luò)狀況下高可用。

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

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

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

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

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

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

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

　　IP 選取及緩存汰換策略

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

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

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

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

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

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

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

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

　　這意味著現(xiàn)有網(wǎng)絡(luò)存儲結(jié)構(gòu)不再具備唯一標識用戶網(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é)議/更精細化調(diào)度訴求下的協(xié)議演進

　　當現(xiàn)有協(xié)議結(jié)構(gòu)無法滿足日益復(fù)雜和精細的調(diào)度訴求，且無法在現(xiàn)有模型上持續(xù)長期迭代時，就需要對協(xié)議進行重構(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ù)遷移

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

　　連接建立

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

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

　　圖：熱域名預(yù)建

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

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

　　復(fù)合連接思路也因此來源于 IPv6 Happy Eyeballs 算法實現(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ù)合連接的兩個核心目標：

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

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

　　連接調(diào)度

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

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

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

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

　　通過對連接的多場景可用性檢測，增強連接質(zhì)量的感知，當出現(xiàn)連接異常時能夠快速的恢復(fù)重建。

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

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

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

　　3.3 請求管理：彈性超時控制，請求補償恢復(fù)

　　動態(tài)超時

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

　　圖：請求各階段超時控制

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

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

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

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

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

　　3.4 廠商加速：擁抱原生，系統(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)，脫離廠商的自研之路并不順暢：

　　一方面，不同廠商的限制和表現(xiàn)異同常讓我們對各廠商做一些 hack 和兼容性的事情；另一方面，用戶的網(wǎng)絡(luò)資源有限，手淘作為單一應(yīng)用，能調(diào)配和控制的資源有限。如何擴大我們的調(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è)緊鑼密鼓的放量驗證中。

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

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

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

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

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

　　圖：請求全鏈路階段

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

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

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

　　4.2 診斷體系：更快識別、定位各類復(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)用鏈路超時等，為了更好的定位/分析各類網(wǎng)絡(luò)類問題， 我們針對移動互聯(lián)網(wǎng)下用戶網(wǎng)絡(luò)類體驗問題的復(fù)雜性，進一步建設(shè) NPM 診斷技術(shù)體系，加強相關(guān)技術(shù)和數(shù)據(jù)的應(yīng)用。

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

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

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

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

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

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

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

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

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

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

　　圖：多通道整體規(guī)?；桨?/p>

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

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

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

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

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

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

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

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

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

　　如何支持標準 HTTP/2？

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

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

　　源碼突破

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

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

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

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

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

　　遭遇系統(tǒng) bug

　　圖：Android Okhttp crash

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

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

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

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

　　4.4 小結(jié)

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

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

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

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

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

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

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

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

　　5.2 更動態(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)的效果。前面提到，當我們能夠更精準感知，甚至預(yù)測用戶網(wǎng)絡(luò)的變化，我們能夠做的事情就更多。

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

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

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

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

　　參考資料

　　[1]

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

　　作者:沈良煒(沛軒)

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

　　出處

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

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