1、引言
由於行動網路的複雜性特點，編寫高品質、體驗好的具備網路通訊能力的移動端應用（尤其是即時通訊這類網路品質高度敏感的應用）有很大的挑戰性。
我們平時看到的行動網路主要有如下三個典型特點：
1）移動狀態網路訊號不穩定，高時延、易抖動丟包、通道狹窄；
2）移動狀態網路接入型別和接入點變化頻繁；
3）移動狀態使用者使用高頻化、碎片化、非WIFI流量敏感。
（▲ 上述文字，引用自《移動端IM開發者必讀(一)：通俗易懂，理解行動網路的“弱”和“慢”》）
正是由於上述特點，移動端應用在進行網路資料通訊時會面臨各種複雜多變的問題。
無論後面的技術有多複雜，但對於普通使用者使用APP來說，能順暢的完成網路請求，是理所當然的事。換句話說，APP網路請求成功率，重要性直接體現在它能直接決定APP服務的可用性，直接影響到資料通訊、視訊播放、廣告展現、支付便捷等服務品質。
本文將以愛奇藝的iOS端APP為例，分享對行動網路請求成功率優化方面的技術實踐之路。
（本文已同步釋出於：http://www.52im.net/thread-2981-1-1.html）
2、相關文章3、導致移動端網路請求失敗的因素《現代移動端網路短連線的優化手段總結：請求速度、弱網適應、安全保障》
《移動端IM開發者必讀(一)：通俗易懂，理解行動網路的“弱”和“慢”》（* 必讀好文）
《移動端IM開發者必讀(二)：史上最全移動弱網路優化方法總結》
《全面了解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《百度APP移動端網路深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網路深度優化實踐分享(二)：網路連線優化篇》
《百度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%的使用者，因此針對重點業務的網路請求（比如首頁）則進行了全量採集，從而對成功率的優化實現更客觀全面的評估。
4、在基線網路庫這一層針對不同業務提供不同的補償思路在優化之前，通過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%。
5、其它影響移動端網路請求成功率的因素除了重試，還有以下因素對網路請求成功率有直接影響。
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%》）。
6、提高魯棒性並防止故障的優化措施在經過各種優化措施提高網路成功率後，我們還通過下面幾個措施成功的防止線上故障造成的成功率瞬時下降，提高了網路請求的魯棒性。
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）網路日誌模組：記錄了最近發生的失敗網路請求詳細資料和網路診斷資料。隨反饋一併提交，可以便捷的排查線上網路問題。
7、未來的目標與可能的優化措施為了持續優化網路成功率，下一步目標是扣除無網情況，重點業務成功率達到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協議感興趣，可以讀一讀下面這些文章：
《網路程式設計懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》
《技術掃盲：新一代基於UDP的低延時網路傳輸層協議——QUIC詳解》
《讓網際網路更快：新一代QUIC協議在騰訊的技術實踐分享》
《七牛雲技術分享：使用QUIC協議實現實時視訊直播0卡頓！》
3）智慧排程併發：
更精準更靈敏的弱網識別，弱網下對關鍵核心業務進行傾斜。
4）HTTPDNS的push能力：
HTTPDNS打通APM的品質監控體系後，通過push及時下線故障IP。
關於移動端DNS問題上的優化，業內已經有了很多總結，有興趣可以深入研究：
《全面了解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《百度APP移動端網路深度優化實踐分享(一)：DNS優化篇》
《移動端網路優化之HTTP請求的DNS優化》
附錄：更多網路通訊方面的技術資料《TCP/IP詳解 - 第11章·UDP：使用者資料報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連線的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協議（上）：理論基礎》
《通俗易懂-深入理解TCP協議（下）：RTT、滑動視窗、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《理論聯絡實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網路通訊協議關係圖（中文珍藏版）》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解(基本原理篇)》
《P2P技術詳解(三)：P2P中的NAT穿越(打洞)方案詳解(進階分析篇)》
《P2P技術詳解(四)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《高效能網路程式設計(一)：單臺伺服器併發TCP連線數到底可以有多少》
《高效能網路程式設計(二)：上一個10年，著名的C10K併發連線問題》
《高效能網路程式設計(三)：下一個10年，是時候考慮C10M併發問題了》
《高效能網路程式設計(四)：從C10K到C10M高效能網路應用的理論探索》
《高效能網路程式設計(五)：一文讀懂高效能網路程式設計中的I/O模型》
《高效能網路程式設計(六)：一文讀懂高效能網路程式設計中的執行緒模型》
《Java的BIO和NIO很難懂？用程式碼實踐給你看，再不懂我轉行！》
《不為人知的網路程式設計(一)：淺析TCP協議中的疑難雜症(上篇)》
《不為人知的網路程式設計(二)：淺析TCP協議中的疑難雜症(下篇)》
《不為人知的網路程式設計(三)：關閉TCP連線時為什麼會TIME_WAIT、CLOSE_WAIT》
《不為人知的網路程式設計(四)：深入研究分析TCP的異常關閉》
《不為人知的網路程式設計(五)：UDP的連線性和負載均衡》
《不為人知的網路程式設計(六)：深入地理解UDP協議並用好它》
《不為人知的網路程式設計(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網路程式設計(八)：從資料傳輸層深度解密HTTP》
《不為人知的網路程式設計(九)：理論聯絡實際，全方位深入理解DNS》
《網路程式設計懶人入門(一)：快速理解網路通訊協議（上篇）》
《網路程式設計懶人入門(二)：快速理解網路通訊協議（下篇）》
《網路程式設計懶人入門(三)：快速理解TCP協議一篇就夠》
《網路程式設計懶人入門(四)：快速理解TCP和UDP的差異》
《網路程式設計懶人入門(五)：快速理解為什麼說UDP有時比TCP更有優勢》
《網路程式設計懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網路程式設計懶人入門(七)：深入淺出，全面理解HTTP協議》
《網路程式設計懶人入門(八)：手把手教你寫基於TCP的Socket長連線》
《網路程式設計懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《網路程式設計懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》
《網路程式設計懶人入門(十一)：一文讀懂什麼是IPv6》
《技術掃盲：新一代基於UDP的低延時網路傳輸層協議——QUIC詳解》
《讓網際網路更快：新一代QUIC協議在騰訊的技術實踐分享》
《現代移動端網路短連線的優化手段總結：請求速度、弱網適應、安全保障》
《聊聊iOS中網路程式設計長連線的那些事》
《移動端IM開發者必讀(一)：通俗易懂，理解行動網路的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網路優化方法總結》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網路程式設計入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網路程式設計入門(二)：我們在讀寫Socket時，究竟在讀寫什麼？》
《腦殘式網路程式設計入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網路程式設計入門(四)：快速理解HTTP/2的伺服器推送(Server Push)》
《腦殘式網路程式設計入門(五)：每天都在用的Ping命令，它到底是什麼？》
《腦殘式網路程式設計入門(六)：什麼是公網IP和內網IP？NAT轉換又是什麼鬼？》
《腦殘式網路程式設計入門(七)：面視必備，史上最通俗計算機網路分層詳解》
《腦殘式網路程式設計入門(八)：你真的了解127.0.0.1和0.0.0.0的區別？》
《以網遊服務端的網路接入層設計為例，理解實時通訊的技術挑戰》
《邁向高階：優秀Android程式設計師必知必會的網路基礎》
《全面了解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《Android程式設計師必知必會的網路通訊傳輸層協議——UDP和TCP》
《IM開發者的零基礎通訊技術入門(一)：通訊交換技術的百年發展史(上)》
《IM開發者的零基礎通訊技術入門(二)：通訊交換技術的百年發展史(下)》
《IM開發者的零基礎通訊技術入門(三)：國人通訊方式的百年變遷》
《IM開發者的零基礎通訊技術入門(四)：手機的演進，史上最全移動終端發展史》
《IM開發者的零基礎通訊技術入門(五)：1G到5G，30年移動通訊技術演進史》
《IM開發者的零基礎通訊技術入門(六)：移動終端的接頭人——“基站”技術》
《IM開發者的零基礎通訊技術入門(七)：移動終端的千里馬——“電磁波”》
《IM開發者的零基礎通訊技術入門(八)：零基礎，史上最強“天線”原理掃盲》
《IM開發者的零基礎通訊技術入門(九)：無線通訊網路的中樞——“核心網”》
《IM開發者的零基礎通訊技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通訊技術入門(十一)：為什麼WiFi訊號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十二)：上網絡卡頓？網路掉線？一文即懂！》
《IM開發者的零基礎通訊技術入門(十三)：為什麼手機訊號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《IM開發者的零基礎通訊技術入門(十五)：理解定位技術，一篇就夠》
《百度APP移動端網路深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網路深度優化實踐分享(二)：網路連線優化篇》
《百度APP移動端網路深度優化實踐分享(三)：移動端弱網優化篇》
《技術大牛陳碩的分享：由淺入深，網路程式設計學習經驗乾貨總結》
《可能會搞砸你的面試：你知道一個TCP連線上能發起多少個HTTP請求嗎？》
《知乎技術分享：知乎千萬級併發的高效能長連線閘道器技術實踐》
《5G時代已經到來，TCP/IP老矣，尚能飯否？》
《愛奇藝行動網路優化實踐分享：網路請求成功率優化篇(iOS端)》
>> 更多同類文章 ……
（本文已同步釋出於：http://www.52im.net/thread-2981-1-1.html）