愛奇藝iOS移動端網絡優化實踐 | 請求成功率優化篇

移動應用APP的網絡優化三大重點方向即成功率、耗時與流量。其中，APP成功率即網絡請求成功率，他的重要性直接體現於它能直接決定APP服務的可用性，直接影響到視頻播放、廣告展示、支付便捷等服務質量。本文將介紹愛奇藝APP對網絡請求成功率優化的實踐之路。

致使請求失敗的因素

       想要優化請求成功率先來了解移動端網絡請求全鏈條可能致使請求失敗的環節有哪些，這些環節每每由如下兩類因素致使：

第一類，不可改善因素

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

2. 路由器故障。

第二類，能夠改善因素

1. 蜂窩/Wifi信號的強弱、鏈接擁堵的假鏈接狀態。
2. 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%。

重試類型	成功率	備註
無重試	98.26%	-
HTTP重試	99.42%	原始URL是HTTPs會被改成HTTP，減小SSL握手帶來的失敗可能。同時確保HTTP1.1協議
超級管道重試	99.55%	超級管道是IP直連的HTTP請求，減小了DNS解析和SLL握手帶來的失敗可能。同時確保HTTP1.1協議。
2  * 超級管道重試 + HTTP重試	99.76%	兩次超級管道,確保超級管道的異地容災能力被激活，HTTP重試是對超級管道的兜底策略。

網絡請求成功率因素

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

1.H2 vs HTTP1.1：推薦的請求策略是首次請求走H2，當失敗重試時走HTTP1.1。

H2對HTTP1.1最大改進是共用一個TCP鏈接，其在網絡順暢時，爲H2帶來了速度上的優點。但當網絡變壞時，TCP包的絕對順序編號會致使一個包的丟失而堵住後面全部的請求。這樣單TCP鏈接反而擴大了擁堵，增大了請求失敗的可能性。

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

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

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

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

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

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

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

H2和HTTP1.1都是基於TCP鏈接的，接口數據體積越小，須要傳輸的TCP包越少，傳輸失敗的機率也就下降了。目前愛奇藝APP正在從gzip轉向壓縮率更高的br。

提升魯棒性並防止故障措施

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

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假鏈接的時能夠走蜂窩流量，iOS9開始支持Multipath特性。

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

3. 智能調度併發
   更精準更靈敏的弱網識別，弱網下對關鍵核心業務進行傾斜。

4. HTTPDNS的push能力

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

 

也許你還想了解2020愛奇藝卡通人物檢測識別挑戰賽，點擊「閱讀原文」，前往大賽通道！

掃一掃下方二維碼，更多精彩內容陪伴你！

本文分享自微信公衆號 - 愛奇藝技術產品團隊（iQIYI-TP）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。