移動應用APP的網絡優化三大重點方向即成功率、耗時與流量。其中，APP成功率即網絡請求成功率，他的重要性直接體現於它能直接決定APP服務的可用性，直接影響到視頻播放、廣告展現、支付便捷等服務質量。本文將介紹愛奇藝APP對網絡請求成功率優化的實踐之路。
導致請求失敗的因素
想要優化請求成功率先來了解移動端網絡請求全鏈條可能導致請求失敗的環節有哪些，這些環節往往由以下兩類因素導致：
第一類，不可改善因素
- iOS系統對APP的網絡訪問權限控制、飛行模式或者無網絡連接。檢測和識別這三種情況，通過適當方式提示用戶。
- 路由器故障。
第二類，可以改善因素
- 蜂窩/Wifi信號的強弱、連接擁堵的假連接狀態。
- DNS故障。
- 運營商局部節點故障。
- 自有運營負載均衡故障。
- 業務服務器故障。HTTP響應錯誤，對應APM的HTTP響應錯誤率。
- 業務邏輯錯誤。監控子類解析結果，對應APM的解析錯誤率監控。
對於不可改善因素，目前只能通過網絡診斷識別出故障類型，引導用戶手動去授權訪問網絡或者連接可用網絡。其中，如果是路由器故障，可以引導用戶重啟路由器或者切換4G。通過愛奇藝APP的數據監控，大致可以看到用戶無網連接的時長佔比有3.8%左右，這說明提供好的無網提示變得十分重要，而從用戶使用蜂窩信號的弱信號(0格和1格信號)時長佔比有9%左右時長，也可以看出移動端網絡環境的複雜性。
針對可以改善的因素可大致分為三類：
- 網絡層錯誤，對應因素1到4。主要體現為超時報錯；
- HTTP響應錯誤，對應因素5。HTTP狀態碼為400及以上；
- 解析錯誤，對應因素6。由基線網絡庫定義的重載接口進行監控。
為了提高網絡請求成功率，首先需要建立監控體系，從而使得基線網絡庫能夠通過網絡統計模塊向APM投遞各種維度的網絡請求數據。有了APM的數據統計後，才能有效的發現導致端上網絡失敗的原因，進而解決問題。除此之外，由於端上網絡請求數據巨大，存儲空間的限制使得APM只能採樣2%的用戶，因此針對重點業務的網絡請求（比如首頁）則進行了全量採集，從而對成功率的優化實現更客觀全面的評估。
基線網絡庫針對不同業務手段
在優化之前，通過APM的歸類分析可以得出：請求失敗的主要報錯是超時(-1001)的佔比達到九成，與此同時SSL錯誤，DNS解析錯誤佔比緊隨其後。根據這一數據統計，重試成為最主要的請求成功率優化的措施。經過不斷探索和實踐總結，基線網絡庫針對不同業務需求提供了四種不同的重試手段：
- IP直連重試，通過配置直連IP數來控制重試次數
Scheme不變，Host改為直接使用IP(消除域名解析風險)。由於此舉需要各個業務線自己提供直連的IP，目前接入的業務主要是登錄等強制要求HTTPS連接的業務。 - 超級管道重試，可以配置1~3次重試
公司自研基於HTTP的網關代理服務(類似於遠程charles代理)。Host改為代理IP(消除域名解析風險)，Scheme改為HTTP(消除SSL風險，h2降級為HTTP1.1)。由於該措施需要付出流量成本，目前接入的業務都是關鍵核心業務，比如首頁等。 - HTTP重試，可以配置1~3次重試
Scheme修改為HTTP(消除SSL風險，h2降級為HTTP1.1)，其他不變。鑑於其為普惠性重試手段，目前接入非關鍵核心的一般業務。 - 原url重試，可以配置1~3次重試
Scheme和host等都不變，通常意義上理解的重試，單純的再請求一次。此舉目前不是推薦重試手段，由業務方自主決定。
除了單個重試手段可以重試多次，基礎網絡庫也支持多種重試手段的組合，四種重試手段的優先次序為IP直連重試>超級管道重試>HTTP重試>原URL重試。扣除無網情況，首頁推薦頁CARD接口成功率通過組合重試在2020第一季度末達到了99.76%。
網絡請求成功率因素
除了重試，還有以下因素對網絡請求成功率有直接影響：
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基礎網絡庫的構成如下：
- 統一網絡庫提供一個網絡接口層，所有業務接口都對接使用網絡接口層。
- 統一網絡庫提供一個網絡封裝層， 對接了iOS系統網絡層NSURLSession、ASIHTTPRequest(基於CFNetwork)、和公司自研的長連接網關。
- 網絡統計模塊：將從業務調用開始到回調給業務方的各個環節的耗時及狀態值，變成統計數據，上傳到APM匯合。
- 網絡診斷模塊：對關鍵業務進行診斷，包括dns解析，ping，tcpconnect，trace等工具對具體IP進行分析，分析結果上傳到APM匯合。
- 弱網檢測模塊：通過借鑑Facebook的弱網檢測是基於網速擬合的網絡等級分級，分為網絡情況非常差(2G或者無網)、網絡情況較差(3G)、網絡情況一般、網絡情況較好、網絡情況非常好五個等級。
- HTTPDNS模塊：有效的解決了運營商劫持問題。
- 超級管道重試：基於HTTP的網關代理，具有異地容災代理能力。
- ipv4/ipv6模塊：識別端上是ipv4 only環境、v4/v6雙棧還是ipv6 only環境。
- 複合連接模塊：可以在server IP緩存池選出最佳IP，手段包括目標IP連接競速，IP歷史請求統計數據排序。
- 網絡日誌模塊：記錄了最近發生的失敗網絡請求詳細數據和網絡診斷數據。隨反饋一併提交，可以便捷的排查線上網絡問題。
目標與優化措施
為了持續優化網絡成功率，下一步目標是扣除無網情況，重點業務成功率達到99.9%。後續考慮的優化措施如下：
- Multipath
當Wifi假連接的時可以走蜂窩流量，iOS9開始支持Multipath特性。 - QUIC
QUIC是基於UDP的，由於運營商對UDP有針對性的丟包，實測QUIC並沒有體現出優勢。然而，考慮到libcurl在2019已提供完整QUIC能力，NSURLSession不久也會支持QUIC。隨著運營商對UDP包的干擾減少，QUIC的優勢將得到體現。 - 智能調度併發
更精準更靈敏的弱網識別，弱網下對關鍵核心業務進行傾斜。 - HTTPDNS的push能力
HTTPDNS打通APM的質量監控體系後，通過push及時下線故障IP。
也許你還想了解2020愛奇藝卡通人物檢測識別挑戰賽！
