1. 引言

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

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

　　2. 終端架構介紹

　　2.1 MobileSDN 理念

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

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

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

　　2.2 AWCN 終端網絡架構

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

　　圖：AWCN Mobile-SDN 架構

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

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

　　2.3 行業(yè)分析

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

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

　　圖：微信 Mars 基礎架構

　　2.4 規(guī)?？傆[

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

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

　　3. 網絡加速體系詳解

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

　　圖：各模塊在一次調用過程的作用域

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

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

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

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

　　IP 選取及緩存汰換策略

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

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

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

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

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

　　CASE 1：高版本設備對于 WiFi 網絡唯一標識的獲取限制

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

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

　　這意味著現有網絡存儲結構不再具備唯一標識用戶網絡的能力，無法正常獲取 BSSID 信息的這些設備上存在著策略混用，甚至跨運營商的問題，從而導致請求性能變慢/出現異常，線上約有 20%+的用戶受潛在影響。因此，對于端側無法直接獲取 BSSID 的設備，引入新的存儲主 key，即用戶無線接入點 AccessPoint 信息，流程涉及 AMDC 端到端協(xié)同升級，大致流程如圖所示。

　　圖：WIFI 存儲升級改造流程

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

　　CASE 2: 應對更復雜協(xié)議/更精細化調度訴求下的協(xié)議演進

　　當現有協(xié)議結構無法滿足日益復雜和精細的調度訴求，且無法在現有模型上持續(xù)長期迭代時，就需要對協(xié)議進行重構升級。我們在移動網絡虛擬化項目中切實遇到如上的問題，協(xié)議重構對于端上來說，是對整個存儲數據模型的改變，這意味著升級新協(xié)議的用戶可能無法繼續(xù)使用舊版本存儲策略，直接丟棄老協(xié)議存儲是最簡單有效的手段，但這會導致升級后一段時間內用戶出現降級 LocalDNS 的問題，這對我們不能容忍。

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

　　圖：AMDC 存儲數據遷移

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

　　連接建立

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

　　熱域名預建機制：啟動場景下的關鍵請求加速

　　圖：熱域名預建

　　復合連接機制：IPv6 規(guī)?；尘跋碌捏w驗保障

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

　　復合連接思路也因此來源于 IPv6 Happy Eyeballs 算法實現，詳見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.

　　圖：雙棧復合連接

　　復合連接的兩個核心目標：

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

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

　　連接調度

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

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

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

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

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

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

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

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

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

　　動態(tài)超時

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

　　圖：請求各階段超時控制

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

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

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

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

　　圖：H3 規(guī)模化過程中的體驗保障

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

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

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

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

　　一方面，不同廠商的限制和表現異同常讓我們對各廠商做一些 hack 和兼容性的事情；另一方面，用戶的網絡資源有限，手淘作為單一應用，能調配和控制的資源有限。如何擴大我們的調度域得以讓我們的應用內請求更好，是我們常在思考的事情。

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

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

　　圖：廠商加速接入架構

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

　　4. 手淘弱網破障實踐

　　4.1 指標定義：明確弱網/卡頓請求

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

　　圖：網絡請求 1s 法則

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

　　圖：請求全鏈路階段

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

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

　　異常報錯：失敗的請求，無論何種原因失敗，網絡超時、服務端未返回等；耗時長尾：響應超過 xx 秒未返回、沒有結束的請求。

　　4.2 診斷體系：更快識別、定位各類復雜網絡問題

　　經常有一些線上用戶反饋網絡類的輿情：

　　為什么 WIFI 下訪問慢，切換到 4G 網絡就恢復了？我的網絡沒問題，為什么手淘等淘系應用加載慢，其他 APP 正常？為什么 xx 頁面加載很慢，其他頁面沒問題？。。。

　　其中導致的原因很多，如用戶路由器的配置、淘系域名被營商 IP 封禁、業(yè)務調用鏈路超時等，為了更好的定位/分析各類網絡類問題， 我們針對移動互聯網下用戶網絡類體驗問題的復雜性，進一步建設 NPM 診斷技術體系，加強相關技術和數據的應用。

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

　　圖：多場景網絡體驗類問題診斷體系

　　4.3 弱網技術：復雜網絡下的網絡體驗

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

　　4.3.1 網絡多通道：手淘規(guī)?；瘧?/p>

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

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

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

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

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

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

　　優(yōu)化數據

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

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

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

　　通過分析，主要有以下原因導致：

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

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

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

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

　　如何支持標準 HTTP/2？

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

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

　　源碼突破

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

　　圖：Android 網絡托管 Okhttp 代理

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

　　圖：Android Okhttp 源碼實現

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

　　遭遇系統(tǒng) bug

　　圖：Android Okhttp crash

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

　　官方在版本 3.12.2+上修復，但 android 源碼仍使用 2.x 版本導致無法修復。

　　圖：okhttp 導致 IndexOutOfBoundsException 代碼

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

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

　　優(yōu)化數據

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

　　4.4 小結

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

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

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

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

　　5.1 更精準的網絡狀態(tài)感知

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

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

　　圖：用戶網絡診斷感知

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

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

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

　　5.3 更一致的弱網交互體驗

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

　　圖：手淘弱網交互表現不一

　　參考資料

　　[1]

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

　　作者:沈良煒(沛軒)

　　來源:微信公眾號:阿里巴巴終端技術

　　出處

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

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