本文原始內(nèi)容由愛奇藝技術產(chǎn)品團隊原創(chuàng)分享，本次有修訂和改動。
1、引言
由于移動網(wǎng)絡的復雜性特點，編寫高質(zhì)量、體驗好的具備網(wǎng)絡通信能力的移動端應用（尤其是即時通訊這類網(wǎng)絡質(zhì)量高度敏感的應用）有很大的挑戰(zhàn)性。
我們平時看到的移動網(wǎng)絡主要有如下三個典型特點：
1）移動狀態(tài)網(wǎng)絡信號不穩(wěn)定，高時延、易抖動丟包、通道狹窄；
2）移動狀態(tài)網(wǎng)絡接入類型和接入點變化頻繁；
3）移動狀態(tài)用戶使用高頻化、碎片化、非WIFI流量敏感。
（▲ 上述文字，引用自《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡的“弱”和“慢”》）
正是由于上述特點，移動端應用在進行網(wǎng)絡數(shù)據(jù)通信時會面臨各種復雜多變的問題。
無論后面的技術有多復雜，但對于普通用戶使用APP來說，能順暢的完成網(wǎng)絡請求，是理所當然的事。換句話說，APP網(wǎng)絡請求成功率，重要性直接體現(xiàn)在它能直接決定APP服務的可用性，直接影響到數(shù)據(jù)通信、視頻播放、廣告展現(xiàn)、支付便捷等服務質(zhì)量。
本文將以愛奇藝的iOS端APP為例，分享對移動網(wǎng)絡請求成功率優(yōu)化方面的技術實踐之路。
本文將同時發(fā)布于“即時通訊技術圈”公眾號，歡迎關注：
（本文已同步發(fā)布于：http://www.52im.net/thread-2981-1-1.html）
2、相關文章
《現(xiàn)代移動端網(wǎng)絡短連接的優(yōu)化手段總結：請求速度、弱網(wǎng)適應、安全保障》
《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡的“弱”和“慢”》（* 必讀好文）
《移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡優(yōu)化方法總結》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優(yōu)化實踐：HTTPS請求耗時減小近半》
《百度APP移動端網(wǎng)絡深度優(yōu)化實踐分享(一)：DNS優(yōu)化篇》
《百度APP移動端網(wǎng)絡深度優(yōu)化實踐分享(二)：網(wǎng)絡連接優(yōu)化篇》
《百度APP移動端網(wǎng)絡深度優(yōu)化實踐分享(三)：移動端弱網(wǎng)優(yōu)化篇》
3、導致移動端網(wǎng)絡請求失敗的因素
想要優(yōu)化移動端網(wǎng)絡請求成功率，先來了解移動端網(wǎng)絡請求全鏈條可能導致請求失敗的環(huán)節(jié)有哪些。
這些環(huán)節(jié)往往由以下兩類因素導致：
第一類：不可改善因素：
1）iOS系統(tǒng)對APP的網(wǎng)絡訪問權限控制、飛行模式或者無網(wǎng)絡連接。檢測和識別這三種情況，通過適當方式提示用戶；
2）路由器故障。
第二類：可以改善因素：
1）蜂窩/Wifi信號的強弱、連接擁堵的假連接狀態(tài)；
2）DNS故障（比如DNS劫持等）；
3）運營商局部節(jié)點故障；
4）自有運營負載均衡故障；
5）業(yè)務服務器故障：HTTP響應錯誤，對應APM的HTTP響應錯誤率；
6）業(yè)務邏輯錯誤：監(jiān)控子類解析結果，對應APM的解析錯誤率監(jiān)控。
對于不可改善因素：目前只能通過網(wǎng)絡診斷識別出故障類型，引導用戶手動去授權訪問網(wǎng)絡或者連接可用網(wǎng)絡。
其中，如果是路由器故障，可以引導用戶重啟路由器或者切換4G。通過愛奇藝APP的數(shù)據(jù)監(jiān)控，大致可以看到用戶無網(wǎng)連接的時長占比有3.8%左右，這說明提供好的無網(wǎng)提示變得十分重要，而從用戶使用蜂窩信號的弱信號(0格和1格信號)時長占比有9%左右時長，也可以看出移動端網(wǎng)絡環(huán)境的復雜性。
針對可以改善的因素，解決方法可大致分為三類：
1）網(wǎng)絡層錯誤，對應因素1到4。主要體現(xiàn)為超時報錯；
2）HTTP響應錯誤，對應因素5。HTTP狀態(tài)碼為400及以上；
3）解析錯誤，對應因素6。由基線網(wǎng)絡庫定義的重載接口進行監(jiān)控。
為了提高網(wǎng)絡請求成功率，首先需要建立監(jiān)控體系，從而使得基線網(wǎng)絡庫能夠通過網(wǎng)絡統(tǒng)計模塊向APM投遞各種維度的網(wǎng)絡請求數(shù)據(jù)。有了APM的數(shù)據(jù)統(tǒng)計后，才能有效的發(fā)現(xiàn)導致端上網(wǎng)絡失敗的原因，進而解決問題。
除此之外，由于端上網(wǎng)絡請求數(shù)據(jù)巨大，存儲空間的限制使得APM只能采樣2%的用戶，因此針對重點業(yè)務的網(wǎng)絡請求（比如首頁）則進行了全量采集，從而對成功率的優(yōu)化實現(xiàn)更客觀全面的評估。
4、在基線網(wǎng)絡庫這一層針對不同業(yè)務提供不同的補償思路
在優(yōu)化之前，通過APM的歸類分析可以得出：請求失敗的主要報錯是超時(-1001)的占比達到九成，與此同時SSL錯誤，DNS解析錯誤占比緊隨其后。根據(jù)這一數(shù)據(jù)統(tǒng)計，重試成為最主要的請求成功率優(yōu)化的措施。
經(jīng)過不斷探索和實踐總結，基線網(wǎng)絡庫針對不同業(yè)務需求提供了四種不同的重試手段。
1）IP直連重試，通過配置直連IP數(shù)來控制重試次數(shù)：
Scheme不變，Host改為直接使用IP(消除域名解析風險)。由于此舉需要各個業(yè)務線自己提供直連的IP，目前接入的業(yè)務主要是登錄等強制要求HTTPS連接的業(yè)務。
2）超級管道重試，可以配置1~3次重試：
公司自研基于HTTP的網(wǎng)關代理服務(類似于遠程charles代理)。Host改為代理IP(消除域名解析風險)，Scheme改為HTTP(消除SSL風險，h2降級為HTTP1.1)。由于該措施需要付出流量成本，目前接入的業(yè)務都是關鍵核心業(yè)務，比如首頁等。
3）HTTP重試，可以配置1~3次重試：
Scheme修改為HTTP(消除SSL風險，h2降級為HTTP1.1)，其他不變。鑒于其為普惠性重試手段，目前接入非關鍵核心的一般業(yè)務。
4）原url重試，可以配置1~3次重試：
Scheme和host等都不變，通常意義上理解的重試，單純的再請求一次。此舉目前不是推薦重試手段，由業(yè)務方自主決定。
除了單個重試手段可以重試多次，基礎網(wǎng)絡庫也支持多種重試手段的組合，四種重試手段的優(yōu)先次序為：IP直連重試 > 超級管道重試 > HTTP重試 > 原URL重試。扣除無網(wǎng)情況，首頁推薦頁CARD接口成功率通過組合重試在2020第一季度末達到了99.76%。
5、其它影響移動端網(wǎng)絡請求成功率的因素
除了重試，還有以下因素對網(wǎng)絡請求成功率有直接影響。
1）HTTP/2 vs HTTP/1.1：推薦的請求策略是首次請求走H2，當失敗重試時走HTTP/1.1：
HTTP/2對HTTP/1.1最大改進是共用一個TCP連接（詳見《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設計思路》），其在網(wǎng)絡順暢時，為HTTP/2帶來了速度上的優(yōu)勢。但當網(wǎng)絡變壞時，TCP包的絕對順序編號會導致一個包的丟失而堵住后面所有的請求。這樣單TCP連接反而擴大了擁堵，增大了請求失敗的可能性。
NSURLSession是HTTP協(xié)議自適應的，不能控制請求使用HTTP/2或者HTTP/1.1。不過由于業(yè)界事實上的標準要求HTTP/2必須是HTTPs的，這樣通過將URL Scheme改為HTTP可以間接降級到HTTP/1.1。
2）適當?shù)某瑫r設置是一個重要影響因素：
NSURLSession的超時實際上是TCP的包間超時，并不是整體請求耗時的超時。
推薦的超時設置策略是：首次請求的超時可以小一點，而重試的超時應該大一些。
3）接口請求過于密集并發(fā)可能降低請求成功率：
比如播放記錄的upload接口在加上多次重試后，成功率仍然只有98.2%。APM監(jiān)控此接口在IPv4環(huán)境失敗率只有0.47%，而IPv6失敗率高達7.07%。通過端上優(yōu)化請求策略，降低接口的并發(fā)密度后，IPv6環(huán)境和IPv4環(huán)境同時提高到99.85%的成功率。
4）接口數(shù)據(jù)體積越小，請求成功率越高：
HTTP/2和HTTP/1.1都是基于TCP連接的，接口數(shù)據(jù)體積越小，需要傳輸?shù)腡CP包越少，傳輸失敗的概率也就降低了。目前愛奇藝APP正在從gzip轉(zhuǎn)向壓縮率更高的br（指的是Brotli壓縮算法，詳見：《啟用 Brotli 壓縮算法，對比 Gzip 壓縮 CDN 流量再減少 20%》）。
6、提高魯棒性并防止故障的優(yōu)化措施
在經(jīng)過各種優(yōu)化措施提高網(wǎng)絡成功率后，我們還通過下面幾個措施成功的防止線上故障造成的成功率瞬時下降，提高了網(wǎng)絡請求的魯棒性。
1）超級管道本身的魯棒性：
下面案例顯示使用了超級管道重試的接口錯誤率只有3.95%，而沒有使用超級管道重試的接口錯誤率高達28.96%。這個案例的時間點還沒有使用異地容災IP，在疊加異地容災IP之后，錯誤率曲線幾乎可以抹平。
2）HTTP重試和原URL重試在v4v6雙棧環(huán)境下，優(yōu)先IPv4：
由于IPv6仍在建設中，有些接口在IPv6的表現(xiàn)弱于IPv4，那么可以指定重試走IPv4。
3）TLS1.3– 1RTT的節(jié)省：
TLS1.3將SSL握手2個RTT降為1個RTT，降低了SSL握手失敗的概率。iOS12.2開始，NSURLSession支持TLS1.3。只需要服務器升級支持TLS1.3即可，端上無須改動。
4）IP復合連接競速：
使用TCP連接測速，目的是剔除壞IP，選擇最優(yōu)IP，從而提高請求的成功概率。
經(jīng)上述措施的持續(xù)優(yōu)化，愛奇藝APP在2020Q1末，扣除無網(wǎng)情況后，業(yè)務成功率達到了99.7%，而網(wǎng)絡層成功率達到了99.77%。
▲ 業(yè)務成功率 = 網(wǎng)絡層成功率+HTTP響應成功率+解析成功率
在完成優(yōu)化后，愛奇藝APP基礎網(wǎng)絡庫的構成如下：
如上圖所示，基礎網(wǎng)絡庫各模板的功能作用如下：
1）統(tǒng)一網(wǎng)絡庫：提供一個網(wǎng)絡接口層，所有業(yè)務接口都對接使用網(wǎng)絡接口層；
2）統(tǒng)一網(wǎng)絡庫：提供一個網(wǎng)絡封裝層，對接了iOS系統(tǒng)網(wǎng)絡層NSURLSession、ASIHTTPRequest(基于CFNetwork)、和公司自研的長連接網(wǎng)關；
3）網(wǎng)絡統(tǒng)計模塊：將從業(yè)務調(diào)用開始到回調(diào)給業(yè)務方的各個環(huán)節(jié)的耗時及狀態(tài)值，變成統(tǒng)計數(shù)據(jù)，上傳到APM匯合；
4）網(wǎng)絡診斷模塊：對關鍵業(yè)務進行診斷，包括dns解析，ping，tcpconnect，trace等工具對具體IP進行分析，分析結果上傳到APM匯合；
5）弱網(wǎng)檢測模塊：通過借鑒Facebook的弱網(wǎng)檢測是基于網(wǎng)速擬合的網(wǎng)絡等級分級，分為網(wǎng)絡情況非常差(2G或者無網(wǎng))、網(wǎng)絡情況較差(3G)、網(wǎng)絡情況一般、網(wǎng)絡情況較好、網(wǎng)絡情況非常好五個等級；
6）HTTPDNS模塊：有效的解決了運營商劫持問題；
7）超級管道重試：基于HTTP的網(wǎng)關代理，具有異地容災代理能力；
8）ipv4/ipv6模塊：識別端上是ipv4 only環(huán)境、v4/v6雙棧還是ipv6 only環(huán)境；
9）復合連接模塊：可以在server IP緩存池選出最佳IP，手段包括目標IP連接競速，IP歷史請求統(tǒng)計數(shù)據(jù)排序；
10）網(wǎng)絡日志模塊：記錄了最近發(fā)生的失敗網(wǎng)絡請求詳細數(shù)據(jù)和網(wǎng)絡診斷數(shù)據(jù)。隨反饋一并提交，可以便捷的排查線上網(wǎng)絡問題。
7、未來的目標與可能的優(yōu)化措施
為了持續(xù)優(yōu)化網(wǎng)絡成功率，下一步目標是扣除無網(wǎng)情況，重點業(yè)務成功率達到99.9%。后續(xù)考慮的優(yōu)化措施如下。
1）Multipath：
當Wifi假連接的時可以走蜂窩流量，iOS 7開始支持Multipath特性（詳見：《揭開 iOS 7 之 Multipath TCP 的面紗》）。
2）QUIC：
QUIC是基于UDP的，由于運營商對UDP有針對性的丟包，實測QUIC并沒有體現(xiàn)出優(yōu)勢。然而，考慮到libcurl在2019已提供完整QUIC能力，NSURLSession不久也會支持QUIC。隨著運營商對UDP包的干擾減少，QUIC的優(yōu)勢將得到體現(xiàn)。
如果對QUIC協(xié)議感興趣，可以讀一讀下面這些文章：
《網(wǎng)絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協(xié)議》
《技術掃盲：新一代基于UDP的低延時網(wǎng)絡傳輸層協(xié)議——QUIC詳解》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術實踐分享》
《七牛云技術分享：使用QUIC協(xié)議實現(xiàn)實時視頻直播0卡頓！》
3）智能調(diào)度并發(fā)：
更精準更靈敏的弱網(wǎng)識別，弱網(wǎng)下對關鍵核心業(yè)務進行傾斜。
4）HTTPDNS的push能力：
HTTPDNS打通APM的質(zhì)量監(jiān)控體系后，通過push及時下線故障IP。
關于移動端DNS問題上的優(yōu)化，業(yè)內(nèi)已經(jīng)有了很多總結，有興趣可以深入研究：
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優(yōu)化實踐：HTTPS請求耗時減小近半》
《百度APP移動端網(wǎng)絡深度優(yōu)化實踐分享(一)：DNS優(yōu)化篇》
《移動端網(wǎng)絡優(yōu)化之HTTP請求的DNS優(yōu)化》
附錄：更多網(wǎng)絡通信方面的技術資料
《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報協(xié)議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎》
《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動窗口、擁塞處理》
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》
《理論聯(lián)系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網(wǎng)絡通訊協(xié)議關系圖（中文珍藏版）》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解(基本原理篇)》
《P2P技術詳解(三)：P2P中的NAT穿越(打洞)方案詳解(進階分析篇)》
《P2P技術詳解(四)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《高性能網(wǎng)絡編程(一)：單臺服務器并發(fā)TCP連接數(shù)到底可以有多少》
《高性能網(wǎng)絡編程(二)：上一個10年，著名的C10K并發(fā)連接問題》
《高性能網(wǎng)絡編程(三)：下一個10年，是時候考慮C10M并發(fā)問題了》
《高性能網(wǎng)絡編程(四)：從C10K到C10M高性能網(wǎng)絡應用的理論探索》
《高性能網(wǎng)絡編程(五)：一文讀懂高性能網(wǎng)絡編程中的I/O模型》
《高性能網(wǎng)絡編程(六)：一文讀懂高性能網(wǎng)絡編程中的線程模型》
《Java的BIO和NIO很難懂？用代碼實踐給你看，再不懂我轉(zhuǎn)行！》
《不為人知的網(wǎng)絡編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》
《不為人知的網(wǎng)絡編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》
《不為人知的網(wǎng)絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡編程(四)：深入研究分析TCP的異常關閉》
《不為人知的網(wǎng)絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網(wǎng)絡編程(六)：深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網(wǎng)絡編程(八)：從數(shù)據(jù)傳輸層深度解密HTTP》
《不為人知的網(wǎng)絡編程(九)：理論聯(lián)系實際，全方位深入理解DNS》
《網(wǎng)絡編程懶人入門(一)：快速理解網(wǎng)絡通信協(xié)議（上篇）》
《網(wǎng)絡編程懶人入門(二)：快速理解網(wǎng)絡通信協(xié)議（下篇）》
《網(wǎng)絡編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》
《網(wǎng)絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網(wǎng)絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優(yōu)勢》
《網(wǎng)絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網(wǎng)絡編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》
《網(wǎng)絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《網(wǎng)絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《網(wǎng)絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協(xié)議》
《網(wǎng)絡編程懶人入門(十一)：一文讀懂什么是IPv6》
《技術掃盲：新一代基于UDP的低延時網(wǎng)絡傳輸層協(xié)議——QUIC詳解》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術實踐分享》
《現(xiàn)代移動端網(wǎng)絡短連接的優(yōu)化手段總結：請求速度、弱網(wǎng)適應、安全保障》
《聊聊iOS中網(wǎng)絡編程長連接的那些事》
《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡優(yōu)化方法總結》
《IPv6技術詳解：基本概念、應用現(xiàn)狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現(xiàn)狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設計思路》
《腦殘式網(wǎng)絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網(wǎng)絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網(wǎng)絡編程入門(三)：HTTP協(xié)議必知必會的一些知識》
《腦殘式網(wǎng)絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網(wǎng)絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網(wǎng)絡編程入門(六)：什么是公網(wǎng)IP和內(nèi)網(wǎng)IP？NAT轉(zhuǎn)換又是什么鬼？》
《腦殘式網(wǎng)絡編程入門(七)：面視必備，史上最通俗計算機網(wǎng)絡分層詳解》
《腦殘式網(wǎng)絡編程入門(八)：你真的了解127.0.0.1和0.0.0.0的區(qū)別？》
《以網(wǎng)游服務端的網(wǎng)絡接入層設計為例，理解實時通信的技術挑戰(zhàn)》
《邁向高階：優(yōu)秀Android程序員必知必會的網(wǎng)絡基礎》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優(yōu)化實踐：HTTPS請求耗時減小近半》
《Android程序員必知必會的網(wǎng)絡通信傳輸層協(xié)議——UDP和TCP》
《IM開發(fā)者的零基礎通信技術入門(一)：通信交換技術的百年發(fā)展史(上)》
《IM開發(fā)者的零基礎通信技術入門(二)：通信交換技術的百年發(fā)展史(下)》
《IM開發(fā)者的零基礎通信技術入門(三)：國人通信方式的百年變遷》
《IM開發(fā)者的零基礎通信技術入門(四)：手機的演進，史上最全移動終端發(fā)展史》
《IM開發(fā)者的零基礎通信技術入門(五)：1G到5G，30年移動通信技術演進史》
《IM開發(fā)者的零基礎通信技術入門(六)：移動終端的接頭人——“基站”技術》
《IM開發(fā)者的零基礎通信技術入門(七)：移動終端的千里馬——“電磁波”》
《IM開發(fā)者的零基礎通信技術入門(八)：零基礎，史上最強“天線”原理掃盲》
《IM開發(fā)者的零基礎通信技術入門(九)：無線通信網(wǎng)絡的中樞——“核心網(wǎng)”》
《IM開發(fā)者的零基礎通信技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發(fā)者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發(fā)者的零基礎通信技術入門(十二)：上網(wǎng)卡頓？網(wǎng)絡掉線？一文即懂！》
《IM開發(fā)者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發(fā)者的零基礎通信技術入門(十四)：高鐵上無線上網(wǎng)有多難？一文即懂！》
《IM開發(fā)者的零基礎通信技術入門(十五)：理解定位技術，一篇就夠》
《百度APP移動端網(wǎng)絡深度優(yōu)化實踐分享(一)：DNS優(yōu)化篇》
《百度APP移動端網(wǎng)絡深度優(yōu)化實踐分享(二)：網(wǎng)絡連接優(yōu)化篇》
《百度APP移動端網(wǎng)絡深度優(yōu)化實踐分享(三)：移動端弱網(wǎng)優(yōu)化篇》
《技術大牛陳碩的分享：由淺入深，網(wǎng)絡編程學習經(jīng)驗干貨總結》
《可能會搞砸你的面試：你知道一個TCP連接上能發(fā)起多少個HTTP請求嗎？》
《知乎技術分享：知乎千萬級并發(fā)的高性能長連接網(wǎng)關技術實踐》
《5G時代已經(jīng)到來，TCP/IP老矣，尚能飯否？》
《愛奇藝移動網(wǎng)絡優(yōu)化實踐分享：網(wǎng)絡請求成功率優(yōu)化篇(iOS端)》
>> 更多同類文章 ……
歡迎關注我的“即時通訊技術圈”公眾號：
（本文已同步發(fā)布于：http://www.52im.net/thread-2981-1-1.html）