愛奇藝移動端網絡優化實踐分享：網絡請求成功率優化篇

本文原始內容由愛奇藝技術產品團隊原創分享，本次有修訂和改動。

一、引言

因爲移動網絡的複雜性特色，編寫高質量、體驗好的具有網絡通訊能力的移動端應用（尤爲是即時通信這類網絡質量高度敏感的應用）有很大的挑戰性。

咱們平時看到的移動網絡主要有以下三個典型特色：

1）移動狀態網絡信號不穩定，高時延、易抖動丟包、通道狹窄；

2）移動狀態網絡接入類型和接入點變化頻繁；

3）移動狀態用戶使用高頻化、碎片化、非WIFI流量敏感。

（▲ 上述文字，引用自《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」》）

正是因爲上述特色，移動端應用在進行網絡數據通訊時會面臨各類複雜多變的問題。

不管後面的技術有多複雜，但對於普通用戶使用APP來講，能順暢的完成網絡請求，是理所固然的事。換句話說，APP網絡請求成功率，重要性直接體如今它能直接決定APP服務的可用性，直接影響到數據通訊、視頻播放、廣告展示、支付便捷等服務質量。

本文將以愛奇藝的iOS端APP爲例，分享對移動網絡請求成功率優化方面的技術實踐之路。

本文已同步發佈於個人「即時通信技術圈」公衆號。

二、致使移動端網絡請求失敗的因素

想要優化移動端網絡請求成功率，先來了解移動端網絡請求全鏈條可能致使請求失敗的環節有哪些。

這些環節每每由如下兩類因素致使：

 

 

第一類：不可改善因素：

1）iOS系統對APP的網絡訪問權限控制、飛行模式或者無網絡鏈接。檢測和識別這三種狀況，經過適當方式提示用戶；

2）路由器故障。

第二類：能夠改善因素：

1）蜂窩/Wifi信號的強弱、鏈接擁堵的假鏈接狀態；

2）DNS故障（好比DNS劫持等）；

3）運營商局部節點故障；

4）自有運營負載均衡故障；

5）業務服務器故障：HTTP響應錯誤，對應APM的HTTP響應錯誤率；

6）業務邏輯錯誤：監控子類解析結果，對應APM的解析錯誤率監控。

對於不可改善因素：目前只能經過網絡診斷識別出故障類型，引導用戶手動去受權訪問網絡或者鏈接可用網絡。

其中，若是是路由器故障，能夠引導用戶重啓路由器或者切換4G。經過愛奇藝APP的數據監控，大體能夠看到用戶無網鏈接的時長佔比有3.8%左右，這說明提供好的無網提示變得十分重要，而從用戶使用蜂窩信號的弱信號(0格和1格信號)時長佔比有9%左右時長，也能夠看出移動端網絡環境的複雜性。

 

 

針對能夠改善的因素，解決方法可大體分爲三類：

1）網絡層錯誤，對應因素1到4。主要體現爲超時報錯；

2）HTTP響應錯誤，對應因素5。HTTP狀態碼爲400及以上；

3）解析錯誤，對應因素6。由基線網絡庫定義的重載接口進行監控。

爲了提升網絡請求成功率，首先須要創建監控體系，從而使得基線網絡庫可以經過網絡統計模塊向APM投遞各類維度的網絡請求數據。有了APM的數據統計後，纔能有效的發現致使端上網絡失敗的緣由，進而解決問題。

除此以外，因爲端上網絡請求數據巨大，存儲空間的限制使得APM只能採樣2%的用戶，所以針對重點業務的網絡請求（好比首頁）則進行了全量採集，從而對成功率的優化實現更客觀全面的評估。

三、在基線網絡庫這一層針對不一樣業務提供不一樣的補償思路

在優化以前，經過APM的歸類分析能夠得出：請求失敗的主要報錯是超時(-1001)的佔比達到九成，與此同時SSL錯誤，DNS解析錯誤佔比緊隨其後。根據這一數據統計，重試成爲最主要的請求成功率優化的措施。

通過不斷探索和實踐總結，基線網絡庫針對不一樣業務需求提供了四種不一樣的重試手段。

1）IP直連重試，經過配置直連IP數來控制重試次數：

Scheme不變，Host改成直接使用IP(消除域名解析風險)。因爲此舉須要各個業務線本身提供直連的IP，目前接入的業務主要是登陸等強制要求HTTPS鏈接的業務。

2）超級管道重試，能夠配置1~3次重試：

公司自研基於HTTP的網關代理服務(相似於遠程charles代理)。Host改成代理IP(消除域名解析風險)，Scheme改成HTTP(消除SSL風險，h2降級爲HTTP1.1)。因爲該措施須要付出流量成本，目前接入的業務都是關鍵核心業務，好比首頁等。

3）HTTP重試，能夠配置1~3次重試：

Scheme修改成HTTP(消除SSL風險，h2降級爲HTTP1.1)，其餘不變。鑑於其爲普惠性重試手段，目前接入非關鍵核心的通常業務。

4）原url重試，能夠配置1~3次重試：

Scheme和host等都不變，一般意義上理解的重試，單純的再請求一次。此舉目前不是推薦重試手段，由業務方自主決定。

 

除了單個重試手段能夠重試屢次，基礎網絡庫也支持多種重試手段的組合，四種重試手段的優先次序爲：IP直連重試 > 超級管道重試 > HTTP重試 > 原URL重試。扣除無網狀況，首頁推薦頁CARD接口成功率經過組合重試在2020第一季度末達到了99.76%。

四、其它影響移動端網絡請求成功率的因素

除了重試，還有如下因素對網絡請求成功率有直接影響。

1）HTTP/2 vs HTTP/1.1：推薦的請求策略是首次請求走H2，當失敗重試時走HTTP/1.1：

HTTP/2對HTTP/1.1最大改進是共用一個TCP鏈接（詳見《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》），其在網絡順暢時，爲HTTP/2帶來了速度上的優點。但當網絡變壞時，TCP包的絕對順序編號會致使一個包的丟失而堵住後面全部的請求。這樣單TCP鏈接反而擴大了擁堵，增大了請求失敗的可能性。

NSURLSession是HTTP協議自適應的，不能控制請求使用HTTP/2或者HTTP/1.1。不過因爲業界事實上的標準要求HTTP/2必須是HTTPs的，這樣經過將URL Scheme改成HTTP能夠間接降級到HTTP/1.1。

2）適當的超時設置是一個重要影響因素：

NSURLSession的超時其實是TCP的包間超時，並非總體請求耗時的超時。

 

推薦的超時設置策略是：首次請求的超時能夠小一點，而重試的超時應該大一些。

3）接口請求過於密集併發可能下降請求成功率：

好比播放記錄的upload接口在加上屢次重試後，成功率仍然只有98.2%。APM監控此接口在IPv4環境失敗率只有0.47%，而IPv6失敗率高達7.07%。經過端上優化請求策略，下降接口的併發密度後，IPv6環境和IPv4環境同時提升到99.85%的成功率。

4）接口數據體積越小，請求成功率越高：

HTTP/2和HTTP/1.1都是基於TCP鏈接的，接口數據體積越小，須要傳輸的TCP包越少，傳輸失敗的機率也就下降了。目前愛奇藝APP正在從gzip轉向壓縮率更高的br（指的是Brotli壓縮算法，詳見：《啓用 Brotli 壓縮算法，對比 Gzip 壓縮 CDN 流量再減小 20%》）。

五、提升魯棒性並防止故障的優化措施

在通過各類優化措施提升網絡成功率後，咱們還經過下面幾個措施成功的防止線上故障形成的成功率瞬時降低，提升了網絡請求的魯棒性。

1）超級管道自己的魯棒性：

下面案例顯示使用了超級管道重試的接口錯誤率只有3.95%，而沒有使用超級管道重試的接口錯誤率高達28.96%。這個案例的時間點尚未使用異地容災IP，在疊加異地容災IP以後，錯誤率曲線幾乎能夠抹平。

 

 

2）HTTP重試和原URL重試在v4v6雙棧環境下，優先IPv4：

因爲IPv6仍在建設中，有些接口在IPv6的表現弱於IPv4，那麼能夠指定重試走IPv4。

3）TLS1.3– 1RTT的節省：

TLS1.3將SSL握手2個RTT降爲1個RTT，下降了SSL握手失敗的機率。iOS12.2開始，NSURLSession支持TLS1.3。只須要服務器升級支持TLS1.3便可，端上無須改動。

4）IP複合鏈接競速：

使用TCP鏈接測速，目的是剔除壞IP，選擇最優IP，從而提升請求的成功機率。

經上述措施的持續優化，愛奇藝APP在2020Q1末，扣除無網狀況後，業務成功率達到了99.7%，而網絡層成功率達到了99.77%。

▲ 業務成功率 = 網絡層成功率+HTTP響應成功率+解析成功率

在完成優化後，愛奇藝APP基礎網絡庫的構成以下：

 

如上圖所示，基礎網絡庫各模板的功能做用以下：

1）統一網絡庫：提供一個網絡接口層，全部業務接口都對接使用網絡接口層；

2）統一網絡庫：提供一個網絡封裝層，對接了iOS系統網絡層NSURLSession、ASIHTTPRequest(基於CFNetwork)、和公司自研的長鏈接網關；

3）網絡統計模塊：將從業務調用開始到回調給業務方的各個環節的耗時及狀態值，變成統計數據，上傳到APM匯合；

4）網絡診斷模塊：對關鍵業務進行診斷，包括dns解析，ping，tcpconnect，trace等工具對具體IP進行分析，分析結果上傳到APM匯合；

5）弱網檢測模塊：經過借鑑Facebook的弱網檢測是基於網速擬合的網絡等級分級，分爲網絡狀況很是差(2G或者無網)、網絡狀況較差(3G)、網絡狀況通常、網絡狀況較好、網絡狀況很是好五個等級；

6）HTTPDNS模塊：有效的解決了運營商劫持問題；

7）超級管道重試：基於HTTP的網關代理，具備異地容災代理能力；

8）ipv4/ipv6模塊：識別端上是ipv4 only環境、v4/v6雙棧仍是ipv6 only環境；

9）複合鏈接模塊：能夠在server IP緩存池選出最佳IP，手段包括目標IP鏈接競速，IP歷史請求統計數據排序；

10）網絡日誌模塊：記錄了最近發生的失敗網絡請求詳細數據和網絡診斷數據。隨反饋一併提交，能夠便捷的排查線上網絡問題。

六、將來的目標與可能的優化措施

爲了持續優化網絡成功率，下一步目標是扣除無網狀況，重點業務成功率達到99.9%。後續考慮的優化措施以下。

1）Multipath：

當Wifi假鏈接的時能夠走蜂窩流量，iOS 7開始支持Multipath特性（詳見：《揭開 iOS 7 之 Multipath TCP 的面紗》）。

2）QUIC：

QUIC是基於UDP的，因爲運營商對UDP有針對性的丟包，實測QUIC並無體現出優點。然而，考慮到libcurl在2019已提供完整QUIC能力，NSURLSession不久也會支持QUIC。隨着運營商對UDP包的干擾減小，QUIC的優點將獲得體現。

若是對QUIC協議感興趣，能夠讀一讀下面這些文章：

3）智能調度併發：

更精準更靈敏的弱網識別，弱網下對關鍵核心業務進行傾斜。

4）HTTPDNS的push能力：

HTTPDNS打通APM的質量監控體系後，經過push及時下線故障IP。

（本文已同步發佈於：http://www.52im.net/thread-2981-1-1.html）

七、參考資料

[1] 現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障

[2] 移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」

[3] 移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結

[4] 全面瞭解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等

[5] 美圖App的移動端DNS優化實踐：HTTPS請求耗時減少近半

[6] 百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇

[7] 百度APP移動端網絡深度優化實踐分享(二)：網絡鏈接優化篇

[8] 百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇