1. 引言
自 2013 年 ALLIN 無線到今天，已經走過 10 個年頭，手淘終端統一網絡庫 AWCN (Ali Wireless Connection Network) 從淘内孵化，一路過來伴随着手淘業務的發展，經曆集團 IPv6 戰役、協定更新演進等，逐漸沉澱為阿裡集團終端網絡通用解決方案，是兼具高性能、多協定、可容災、可觀測的終端網絡基礎統一設施。面對移動網際網路絡下複雜多變的網絡環境，如何提供更穩定可靠的請求性能，保障使用者的加載浏覽體驗、更好的支撐業務發展，是我們始終探索的命題。
本文将介紹淘寶 APP 統一網絡庫演進的過程，講述如何圍繞體驗持續建構南北向從監測到加速一體化的終端網絡架構，通過建構 NPM 弱網診斷感覺能力，落地原生多通道技術/多協定擇優排程手段，貼合廠商附能網絡請求加速，實作去 SPDY 及規模化 IPv6/H3 協定簇的平滑過渡，為使用者提供弱網更好、好網更優的 APP 加載浏覽體驗，支撐業務創造更多的可能性。
2. 終端架構介紹
2.1 MobileSDN 理念
在介紹 AWCN 之前，筆者想先這裡普及下 SDN 架構的概念。
SDN（Software Defined Network，軟體定義網絡） 是一種将網絡資源抽象到虛拟化系統中的 IT 基礎架構，SDN 将網絡轉發功能與網絡控制功能分開，其目标是建立可集中管理和可程式設計的網絡，核心理念是 希望應用軟體可以參與對網絡的控制管理，滿足上層業務需求，簡化使用和運維成本。有一個較為形象的類比，如果說現在的網絡系統是功能機，系統和硬體出廠時就被捆綁在一起，那麼 SDN 就是 Android 系統，可以在很多手機裝置上安裝&更新，同時還能安裝更多更強大的手機 App（SDN 應用層部署）。
回到移動應用領域，我們的目标是搭建統一的終端網絡解決方案，上層業務不需要關心内部的協定如何轉發、請求逾時降級等複雜邏輯，做到好用、易用、可觀測、體驗好。顯然，這與傳統 SDN 架構理念不謀而合。
2.2 AWCN 終端網絡架構
是以，圍繞以上理念和目标，我們進一步建構起南北向從監測到加速一體化的 MobileSDN 架構，以減少業務的接入/運維成本，提升使用者的浏覽體驗。
圖：AWCN Mobile-SDN 架構
從 MobileSDN 架構展開來，接下來簡要介紹下各分層子產品承擔的角色與其中作用。
- 網絡應用：面向多種應用場景衍生出的網絡元件，如統一 RPC 網關（MTOP）、消息 PUSH 通道（ACCS）、上傳（AUS）、下載下傳（TBDownloader）、圖檔加載（Phenix）、遠端配置（Orange）等能力；
- 網絡北向接口：上層調用和内部實作的橋梁，提供統一同步/異步對外 API 接口和無痕 Hook 方式，用于上層網絡應用/業務場景接入調用網絡基礎能力；
- 網絡控制器：請求政策管控中心，架構大腦，負責請求端到端鍊路的排程和優化決策，有着舉足輕重的作用，控制器提供完備的網絡加速能力，從節點排程/連接配接選擇/請求管理多個環節進行網絡請求加速；
- 網絡南向接口：控制面與基礎協定轉發的橋梁，對協定及資料進行了通用抽象，以應對不同系統架構/不同協定的統一處理；
- 網絡協定轉發：多個基礎協定和網絡架構的統一适配實作，相容各類請求場景下的最優選擇排程，支援标準 HTTP/1.1、HTTP/2、HTTP/3，以及集團自研的 HTTP/2+SSSL 和 H3-XQUIC 協定；
- 網絡性能管理：網絡資料及性能觀測中心，NPM（Network Performance Management），負責裝置網絡狀态/品質/信号強度的感覺、業務請求資料的統計上報、PING/TRACE/NSLookup 等網絡時延探測診斷、使用者網絡診斷/請求抓包等工具建設。
2.3 行業分析
縱觀行業内一些與之對标的移動網絡架構，如騰訊維納斯 WNS、微信 Mars、Chromium cornet、Square Okhttp 等，AWCN 和它們在一些思路上可以說是殊途同歸，通過提供更優的 IP 政策排程、多協定連接配接管理政策及請求逾時等控制加速請求，建設網絡診斷、網絡品質監控等手段加強網絡可觀測能力。
- 微信 Mars：STN 負責請求任務管理/IP 排序/網絡政策等能力優化請求體驗，SDT 為網絡診斷子產品，一定程度上與 AWCN 中網絡控制器、網絡性能管理兩塊部分承擔角色相近。
圖：微信 Mars 基礎架構
2.4 規模總覽
淘寶統一網絡庫作為基礎元件在集團内被廣泛應用，集團内涵蓋千級以上規模應用支撐，包含且不限于手淘、閑魚、優酷、天貓、Lazada、高德、UC浏覽器、餓了麼等 APP，同時通過阿裡雲 EMAS、友盟對三方應用開放接入，如海底撈/杭州銀行等企業應用。
作為移動網絡解決方案，網絡請求的體驗是重中之重，是以，筆者将重點講述網絡控制器如何圍繞請求建構完整鍊路上的加速技術，介紹如何從節點排程/連接配接選擇/請求管理/系統排程進行業務網絡體驗優化，確定請求在各類複雜網絡狀況下高可用。
3. 網絡加速體系詳解
前面提到，網絡控制器是作為整體架構上的大腦，承擔着請求端到端鍊路的排程和優化決策，相當于掌舵手和發動機的角色。一次完整的請求網絡傳輸大緻可以分為以下鍊路，即DNS->建連->發送資料->等待首包響應->接收資料，過程中 IP 政策排程、連接配接管理、請求管理及廠商全局排程加速子子產品各承擔着不同的作用，筆者将逐一介紹闡述。
圖：各子產品在一次調用過程的作用域
- IP 政策排程：負責 IP/節點的選擇和排程，職責是選擇最優的 IP 政策，減少 DNS 帶來的耗時，同時具備切流容災的能力；
- 連接配接及協定管理：負責連接配接池生命周期的管理和各類協定的選擇，職責是連接配接擇優且高可用；
- 請求管理：負責請求的排程，涵蓋逾時、降級、重試恢複等流程控制，職責是讓請求更快的被執行；
- 廠商加速：負責對接各大廠商系統側的網絡能力，結合系統賦予的網絡加速能力（如更精準的網絡品質狀态/雙頻 WiFi 聚合加速/流加速等），進一步優化複雜網絡下請求排程的政策決策，是自研與廠商原生網絡能力之間的溝通樞紐。
3.1 IP 政策排程：減少 DNS 耗時，選擇更優 IP
衆所周知，傳統的 LocalDNS 方式存在各類隐患問題，如：解析慢/失敗率高、更新不及時、域名劫持、缺少精準流量排程及容災能力，AMDC（Ali Mobile Dispatch Center）是阿裡自建的無線域名解析排程服務，在手淘和集團絕大多數應用中廣泛應用。
依托 HTTPDNS 實作無線排程功能就夠了嗎？遠沒有那麼理想化，如何在端側處理好 IP 政策的選取/容災/安全性/服務 QPS 壓力等環節，都至關重要。
IP 選取及緩存汰換政策
IP 選擇機制上，基于服務下發+端側動态排序的機制運作
- 服務端下發：根據單元化/營運商/就近接入/網絡協定棧等次元，下發一組可用的 IP 清單。同時具備通過端側跑馬算法，生成最優的政策 IP。
- 端側動态排序：根據端側 IP 政策使用記錄（成功&失敗&耗時等次元）進行優先級排序，建連錯誤次數多的政策在排序優先級上進行降級操作，與之相對應的，建連成功率高性能好的政策優先級提高。
緩存和汰換機制上，考慮到頻繁 AMDC 排程帶來服務壓力、異步請求 AMDC 帶來的生效率問題，端側對政策進行了緩存，根據使用者網絡粒度進行獨立存儲，應用啟動和網絡事件切換情況下加載所需的政策記錄；根據前面所提及的建連記錄動态排序能力，自然也産生了對應的淘汰替換機制。
- 淘汰機制：同一 IP 在 5min 中連續失敗 xx 次，進入禁用淘汰的情況
- 更新機制：域名粒度攜帶 TTL（Time To Live）下發，超過 TTL 的域名進行異步更新，同時更新機制按照域名的優先級也擁有不同的模式。
新态勢下的挑戰及更新
CASE 1：高版本裝置對于 WiFi 網絡唯一辨別的擷取限制
前面提及的端側緩存政策基于使用者網絡粒度做獨立存儲，對于 WiFi 網絡環境 BSSID 是端側的辨別主鍵，但随着系統更新帶來的一系列使用者權限收斂：
- Android 8 及以上版本開始，需要使用者授權定位等權限，才可以拿到 Wi-Fi SSID/BSSID 等相關資訊，否則傳回 02:00:00:00:00:00 預設值
- iOS 14 起，必須接入 network extension，否則無論通過任何手段都無法擷取到 wifi 相關資訊，對接 NE 成本太高。
這意味着現有網絡存儲結構不再具備唯一辨別使用者網絡的能力，無法正常擷取 BSSID 資訊的這些裝置上存在着政策混用，甚至跨營運商的問題，進而導緻請求性能變慢/出現異常，線上約有 20%+的使用者受潛在影響。是以，對于端側無法直接擷取 BSSID 的裝置，引入新的存儲主 key，即使用者無線接入點 AccessPoint 資訊，流程涉及 AMDC 端到端協同更新，大緻流程如圖所示。
圖：WIFI 存儲更新改造流程
資料上，圖檔等 CDN 類請求平均耗時優化 4.439%，耗時分位 P90 優化1.932%，P99 優化 2.230%，P999 優化 2.668% 。
CASE 2: 應對更複雜協定/更精細化排程訴求下的協定演進
當現有協定結構無法滿足日益複雜和精細的排程訴求，且無法在現有模型上持續長期疊代時，就需要對協定進行重構更新。我們在移動網絡虛拟化項目中切實遇到如上的問題，協定重構對于端上來說，是對整個存儲資料模型的改變，這意味着更新新協定的使用者可能無法繼續使用舊版本存儲政策，直接丢棄老協定存儲是最簡單有效的手段，但這會導緻更新後一段時間内使用者出現降級 LocalDNS 的問題，這對我們不能容忍。
重新實作一個協定不難，難的是如何確定新老協定平穩更新過渡，避免請求出現 LocalDNS 降級。是以，方案的關鍵在于如何對新老協定做資料遷移，其中涉及更新鍊路和降級鍊路(如穩定性問題功能回退場景)。
圖：AMDC 存儲資料遷移
3.2 連接配接管理：更快建連，保障連接配接高可用
連接配接建立
除了正常的串行建連和并發建連方式，我們提供了熱域名預建和複合連接配接的方式，應對各種複雜的場景。
熱域名預建機制：啟動場景下的關鍵請求加速
圖：熱域名預建
複合連接配接機制：IPv6 規模化背景下的體驗保障
當手淘作為 IPv6 示範性應用跑在最前面時，我們發現國記憶體在部分雙棧網絡 IPv6 品質差甚至不通的情況，Android 的輿情回報尤為突出，原因在于 iOS 系統側實作了 Happy Eyeballs 機制確定快速 rollback 回 IPv4 鍊路，而 Android 裝置沒有。
複合連接配接思路也是以來源于 IPv6 Happy Eyeballs 算法實作，詳見RFC 6555[1]。
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.
圖：雙棧複合連接配接
複合連接配接的兩個核心目标：
- 雙棧環境體驗：從 IPv6 和 IPv4 中為使用者選擇一個最快的連結，且保證優先使用 IPv6
- 減少後端壓力：避免同時對兩位址發起請求，造成網絡破壞；
資料上，針對 MTOP 和圖檔請求，雙棧情況下其建連性能平均耗時降低 22.12%，99 分位性能降低 60.19%，請求資料平均耗時降低了1.23%，P99 分位耗時降低 6.077%。
連接配接排程
按照不同的通道應用場景，連接配接可以區分為兩種形态，保活連接配接與正常連接配接。
- 保活連接配接：需要時刻保證連接配接存活，随時可用，适用于上下行推拉結合的場景，如消息；
- 正常連接配接：不需要時刻保活，空閑及時回收減少資源占用，适用于僅主動上行調用的場景，如 RPC。
針對建立好的連接配接，不同形态的維護管理方式也不同。
面向保活可用：假連檢測，動态心跳
通過對連接配接的多場景可用性檢測，增強連接配接品質的感覺，當出現連接配接異常時能夠快速的恢複重建。
檢測的手段基本為心跳 PING 包方式，分位定時心跳（前背景間隔不同）、分場景心跳（切換前台、業務上行逾時等）。
面向空閑回收：閑時狀态檢查，及時關閉
對于不需要主動下行推送的場景，建連時刻保持對于使用者帶寬和功耗存在一定影響，是以針對此類連接配接增加了空閑狀态的檢查，當發現建連超過一定時間沒有資料包傳輸時會進行連接配接的關閉回收，以減少資源占用，釋放有限帶寬。
3.3 請求管理：彈性逾時控制，請求補償恢複
動态逾時
- 精細控制：在請求各個鍊路上，具有獨立逾時控制，每個階段精細化控制，快速感覺逾時情況；
- 動态調配：針對 不同域名請求/網絡類型/不同品質 的環境下動态逾時時長處理。
圖：請求各階段逾時控制
多路競争&擇優選用
對于請求逾時或慢的場景，AWCN 會通過多種方式進行擇優選用和請求補償，確定鍊路最優，保障體驗：
- 傳輸協定：營運商對于 HTTP/3（UDP）的網絡品質保證遠不及 TCP，常常遇到各類 UDP 穿透性、請求逾時等問題，是以必要時需快速決策，切回 HTTP/2、HTTP/1.1 的 TCP 傳輸鍊路；
- 底層架構：自研傳輸庫(TNET)帶來的好處是協定的自建和調優，但也是以導緻協定非标(如 HTTP/2+SSSL 私有加密協定)，營運商攔截丢包、端到端鍊路穩定性等問題，必要時決策回退至系統原生庫；
- 網絡通道：以往對于使用者網絡不通導緻的問題，優化的手段有限，但随着系統開放多通道選擇的能力之後，上層也擁有了切換網絡通道的能力，當檢測 WiFi 不通環境下，會将請求切換至蜂窩網絡通道恢複。
以傳輸協定擇優選用為例，對于 H3 協定在手淘的規模化過程使用者體驗不受損，AWCN 網絡庫建立起完善的擇優選用和補償兜底機制。
圖：H3 規模化過程中的體驗保障
3.4 廠商加速：擁抱原生，系統級排程加速
近年來，國内幾家廠商前後對上層應用開放了系統級的網絡優化能力，包括網絡帶寬排程、資料流加速、QoE 狀态回報、弱網預測、雙 WiFi 聚合能力等，從系統側排程提升請求性能。
廠商能力融合的思考與決策
作為淘寶終端網絡基礎設施，一直以來我們都專精于應用政策及協定上，緻力如何更好的排程、管理連接配接/協定讓請求更快。随着國内廠商的發展，我們發現，脫離廠商的自研之路并不順暢：
- 一方面，不同廠商的限制和表現異同常讓我們對各廠商做一些 hack 和相容性的事情；
- 另一方面，使用者的網絡資源有限，手淘作為單一應用，能調配和控制的資源有限。如何擴大我們的排程域得以讓我們的應用内請求更好，是我們常在思考的事情。
是以我們選擇擁抱廠商，通過系統賦予的排程加速能力，深度合作，為應用提供更好的網絡體驗。
為了屏蔽不同廠商之間的能力差異和接入方式不同，AWCN 提供廠商加速子產品的通用能力抽象，通過運作期對不同裝置和廠商能力的解決，動态組織支援的系統能力清單。
圖：廠商加速接入架構
目前，我們已經和 OPPO 完成接入和上線工作，協同廠商側緊鑼密鼓的放量驗證中。
4. 手淘弱網破障實踐
4.1 名額定義：明确弱網/卡頓請求
過往我們基于網絡請求 1s 法則作為優化的名額衡量，目前業務請求秒出率超過 95%，當網絡體驗進入深水區，弱網/長尾等卡頓負向請求成為我們關注和突破重點。
圖：網絡請求 1s 法則
弱網作為廣義的概念，有多方面的原因，一般來說我們把使用者網絡波動、信号強度弱、時延 RT 大稱之為弱網環境。對于使用者來說，最大的體感就是各類頁面打開慢、加載久、圖檔空窗等問題，請求耗時久/異常是直接原因。我們從請求端到端全鍊路進行逐一分析，除了網絡傳輸、後端服務處理耗時，也存在一些業務本地處理/回調等執行的耗時。
圖：請求全鍊路階段
通過梳理完整請求的調用鍊路，我們在思考如何通過名額化的方式衡量出這部分對業務/使用者體驗有損的請求，在明确目前線上相關負向卡頓請求的規模的前提下，再進行進一步的優化及效果觀測。
是以，基于使用者/業務視角，将請求全鍊路階段内出現異常報錯、耗時長尾定義為卡頓請求：
- 異常報錯：失敗的請求，無論何種原因失敗，網絡逾時、服務端未傳回等；
- 耗時長尾：響應超過 xx 秒未傳回、沒有結束的請求。
4.2 診斷體系：更快識别、定位各類複雜網絡問題
經常有一些線上使用者回報網絡類的輿情：
- 為什麼 WIFI 下通路慢，切換到 4G 網絡就恢複了？
- 我的網絡沒問題，為什麼手淘等淘系應用加載慢，其他 APP 正常？
- 為什麼 xx 頁面加載很慢，其他頁面沒問題？
- 。。。
其中導緻的原因很多，如使用者路由器的配置、淘系域名被營商 IP 封禁、業務調用鍊路逾時等，為了更好的定位/分析各類網絡類問題， 我們針對移動網際網路下使用者網絡類體驗問題的複雜性，進一步建設 NPM 診斷技術體系，加強相關技術和資料的應用。
- 領域模型：使用者體驗問題的技術面窮舉拆解、沉澱；
- 能力建構：診斷原子能力及工具鍊，運維提效；
- 規模應用：多元使用者網絡資料，IPv6/MTU/UDP 大盤。
圖：多場景網絡體驗類問題診斷體系
4.3 弱網技術：複雜網絡下的網絡體驗
針對移動複雜網絡環境，除了前面網絡加速體系所提到的相關能力之外，這裡筆者将重點對典型弱網靶向性優化技術展開。
4.3.1 網絡多通道：手淘規模化應用
當請求沒有響應/接收慢的情況下，一般會觸發逾時機制進行請求重放。但在使用者 WIFI 信号差&弱網環境下，我們反而要謹慎重試，一方面重試會加重系統上的負載，另一方面重試會導緻請求重新開始，對弱網傳輸慢的情況不友好，反而加劇卡慢的情況。
是以，在尋求更友好的方式上，我們發現系統提供了一種多通道傳輸的能力，即允許裝置在 WIFI 環境下将請求切換蜂窩網卡的能力，網絡應用層可以利用該技術，減少請求的逾時等一類錯誤，提升請求的成功率。
圖：系統官方文檔
規模化方案
除了正常的技術應用，因為涉及到使用者在 WIFI 網絡下的流量損耗，我們遵從使用者隐私等合規前提下，提供多通道能力生效的使用者提示和功能授權。
圖：多通道整體規模化方案
優化資料
目前多通道技術在手淘核心浏覽鍊路上已規模化應用，嚴格按照AB 實驗得出資料，雙十一期間雙端日對請求逾時率減少 30%以上。
4.3.2 原生 HTTP/2：突破系統限制，實作 H2 協定支援
相對于 HTTP/1.1 協定，HTTP/2、HTTP/3 的協定性能優勢不言而喻，HTTP/2 協定在手淘和集團内早已支援多年，HTTP/3 協定同樣在持續規模擴量中，但目前手淘内仍然存有 10%左右 HTTP1.1 流量。
通過分析，主要有以下原因導緻：
1.HTTP/2 協定非标準化實作，加密方式為私有 slight-ssl，域名支援需服務端部署，未明确知曉是否支援的域名隻能走 HTTP/1.1 協定；
2.鑒于非标的影響，請求鍊路上需要強依賴 AMDC，必須通過 AMDC 配置明确支援 h2+sssl 方式的域名下發後才能支援；
3.非标協定的相容性存在小機率問題，個别營運商針對非标協定會進行劫持處理導緻請求失敗降級到短連。
過往很多業務回報，為什麼域名在 chrome 浏覽器上通路支援 HTTP/2，而手淘裡是仍然是 HTTP/1.1 的原因就在于此。那麼，如何在不需要服務端部署、不強依賴 AMDC 的前提下，讓請求實作長連加速？标準 HTTP2 的實作是必經之路。
如何支援标準 HTTP/2？
iOS 通過更新 URLSession 系統調用方式，可低成本的遷移到 H2/H3 協定上，但對于 Android 來說，系統側提供的 HttpUrlconnection 僅支援到 HTTP/1.1 協定。是以，靈魂三問：
- 标準協定的完整實作，必然要加入人力投入開發，穩定性驗證和上線是一個較長的周期，如何減少支援的成本？考慮引入穩定的能力實作，如 Okhttp。
- 穩定庫引入必定會增加包大小，這對目前嚴控包大小的現狀有較大沖突，如何解決？需盡可能不增加包大小的情況下支援。
- 既要考慮成本和穩定性驗證等規模化問題，又要避免給手淘包大小過大的增幅。既要馬兒跑，又要馬兒不吃草。如何實作？
源碼突破
通過對系統源碼的分析，我們發現 Android 系統 5.0 之後，系統 API HttpUrlconnection 底層已經通過 okhttp 進行托管實作，也就是說 Android 系統本身支援通過 okhttp 通路不需要額外引入三方庫進行，隻要找到可以 hook 的點。
圖：Android 網絡托管 Okhttp 代理
進一步分析源代碼，我們找到了 okhttp 在 android 系統側的位置和包名，即com.android.okhttp下。
圖：Android Okhttp 源碼實作
雖然是隐藏 API，仍可以通過反射的方式進行，為了更友好的編碼實作，在編譯期通過空實作依賴的方式進行顯式的調用，同時確定在使用前對裝置 okhttp 的環境及相容性做好檢查。
遭遇系統 bug
圖：Android Okhttp crash
灰階過程我們發現一些因為 Okhttp 導緻的 IndexOutOfBoundsException 穩定性問題，bug 來源于特定場景下沒有拿到證書清單且未對容器判空導緻，詳細記錄在：https://github.com/square/okhttp/issues/4208。
官方在版本 3.12.2+上修複，但 android 源碼仍使用 2.x 版本導緻無法修複。
圖：okhttp 導緻 IndexOutOfBoundsException 代碼
為了規避系統側問題，我們摒棄 okhttp 提供異步調用的 api，改為同步調用+異常捕獲+上層轉異步的方式進行處理。
此外，針對不同應用，若存在三方 okhttp 依賴，會自動橋接到三方實作上，體驗高版本 okhttp 的穩定性；對于手淘這種不依賴三方 okhttp 的應用，再橋接到系統版本實作。
優化資料
标準 H2 更新率先在 Feeds 接口域名覆寫，農場整體輿情月環比下降 23%，請求耗時優化 21.4%，成功率提升 0.3pt。
4.4 小結
截至目前，日改善卡頓請求(網絡錯誤/耗時>x 秒) PV 10 億+ ，達成全年目标 10 億(統計口徑嚴格按照 AB 實驗桶對比計算)，MOTP 請求逾時率較去年 4 月優化了近50%。
5. 後續方向與展望
對于移動網絡體驗的探索是無止境的，今年我們圍繞弱網和體驗加速做了一些工作，有些内容因為篇幅和側重點考慮是以沒有進一步展開講述，後期再通過另外專題文章進行側重講解。
但即便如此，面對億萬使用者各類複雜多變的環境，仍存在着加載慢、卡頓、空白的聲音，作為淘寶和集團統一的終端基礎網絡設施，如何讓使用者浏覽體驗再更上一層樓，我們要做的還很多。
5.1 更精準的網絡狀态感覺
準确掌握使用者的網絡狀态是一切手段的前提，以往我們圍繞 NPM 搭建診斷體系，對端到端鍊路的連通性和品質進行檢測，在實時性、準确度和可用性仍有提升空間。
- 結合廠商系統側更精準可靠的網絡品質回報：依托提供 QoE 網絡品質能力，提供更實時的 WiFi/蜂窩網絡信号品質和強度回報;
- 提供使用者更友好的網絡感覺手段：當使用者出現“潛在”的網絡問題，我們希望大部分情況使用者可以自行知道哪裡出問題、怎麼解決。
圖：使用者網絡診斷感覺
5.2 更動态智能的排程加速能力
針對不同網絡類型和品質的環境，我們希望建設更适應性更動态智能的排程能力，基于不同場景做更适合有效的加速能力應用，一成不變，固化的優化政策無法在所有的環境下發揮更優的效果。前面提到，當我們能夠更精準感覺，甚至預測使用者網絡的變化，我們能夠做的事情就更多。
圖：預測弱網環境的動态調優
5.3 更一緻的弱網互動體驗
我們發現手淘多業務在弱網互動下表現不一，存在着無法重新整理重試、空白無提示、阻塞無法操作等問題，是以除了技術側的能力強化，會進一步聯合多方沉澱弱網體驗規範，協同業務優化弱網場景下的表現與體驗、提升互動性和可恢複性，并改善使用者在弱網下的預期和感受。
圖：手淘弱網互動表現不一
參考資料
[1]
RFC 6555: https://www.rfc-editor.org/rfc/rfc6555
作者:沈良炜(沛軒)
來源:微信公衆号:阿裡巴巴終端技術
出處:https://mp.weixin.qq.com/s/YomDksoRv_Chuw7oHBzzFA