本文由手機淘寶技術團隊原創分享，吳志華（天施）、洪海（孤星）、陳虓將（仲升）等專家參與了本文創作，首次發表于公眾號“淘系技術”，收錄整理時有修訂和改動。
1、引言
移動端網絡的優化是超級App們永恒的話題，而對于無線電商來說這更為重要，因為網絡請求體驗跟用戶的購買行為息息相關。
手機淘寶從過去的HTTP API網關，到后來扛住雙十一戰場主要流量的自研高性能、全雙工、安全的ACCS（阿里云通道服務），無論是基礎架構的演進、網絡調優、協議的優化、異地多活、網絡調度上，都有不少寶貴的經驗與大家分享，本文借此機會總結了整個技術演進過程。
* 閱讀對象：本文屬于移動端網絡優化的深水區總結性文章，適合有一定移動端網絡應用經驗的開發者閱讀（尤其對移動弱網有一定了解的），初學者如果沒有相關知識積累的話，可以簡單了解無需深入。如果你對移動弱網很有興趣，可以進一步閱讀本文末尾“附錄”部分的推薦文章。
本文已同步發布于“即時通訊技術圈”公眾號。
2、相關文章
《Netty干貨分享：京東京麥的生產級TCP網關技術實踐總結》
《知乎技術分享：知乎千萬級并發的高性能長連接網關技術實踐》
《手機淘寶消息推送系統的架構與實踐(音頻+PPT) [附件下載]》
3、技術背景
回想移動電商在雙十一業務開始興起的時候，當時雙十一當天移動成交243億占整體571億的42.6%。
業務高速發展希望更多主動推送去觸達用戶，一些新的玩法和互動形式，需要連接買家與買家、買家與賣家、買家與達人，因為沒有有效的通道能力，業務采取的是不停去輪詢服務器，一來對服務器造成不必要的壓力，二來對于用戶手機的電量流量也是極大的浪費，關鍵在雙十五這種大促的情況下，不必要的請求過大甚至會導致后端集群限流，從而影響到用戶體驗。
信息傳播形態的變化的背后是移動化帶來新的技術特征導致的結果。移動電商領域，手機淘寶一直是先行者。移動電商從最初的復制WEB的業務形態到移動特性不斷涌現，更多的互動形式的出現，向社交化、娛樂化不斷邁進的今天，一個單純的商品的陳列架形式已經不能滿足業務的需求。
業務上需要實時的觸達用戶，充分發揮移動的特性，將消費時間的碎片利用起來，事實也證明了用戶的消費時間隨著移動化的進程不斷發生變化，逐步分布到全天的碎片時間中。同時貨架形態也在向社區化、娛樂化的方向發展，這些都對網絡層連接用戶有了更高的要求。更多的媒體形態和展示方式，對網絡層提出了更多元的要求。
大家可以關注到手機淘寶內的消息盒子這些產品都是業務求變的體現，業務的變化倒逼技術的前進。
4、移動網絡環境的挑戰性一直都存在
移動網絡的速度隨便3g、4g、5G的普及，速度有很大提升，但網絡環境的多樣性和差異性使移動網絡的環境更加復雜，在過去雙十一前還常遇到一些移動網絡劫持的事情。網絡劫持這塊問題的排查效率很低，需要找到用戶、復現現場，甚至找網工、運營商配合排查，一查就是幾天過去。
同時在我們的輿情反饋上總是看到用戶在說“某個頁面加載中、頁面打不開、請求很慢、打開某個功能很慢”，面對這些問題過去我們是沒有太好的辦法，只能貓抓耗子一樁樁去排雷很被動。很多網絡的問題是偶現的，一旦錯過現在就無從查起。
諸如此類的問題，背后的原因很多：
1）運營商問題；
2）機房部署原因；
3）客戶端SDK Bug；
4）弱網和網絡抖動；
5）DNS劫持和數據篡改。
在PC時代，我們訪問網站的接入條件是相對恒定的，所以在開發時很少考慮網絡對用戶體驗的影響。但是移動APP則不然，尤其是在國內，基礎的移動網絡環境還不算太好，而且我們有很多用戶的訪問是發生在地鐵、公交車這樣的移動環境下，移動基站的頻繁切換進一步增加了網絡的不穩定。從手機淘寶的數據可以看出，我們每天活躍用戶中有不少來自于弱網環境。如果端到云的連接不穩定、高延時，那么所有的用戶體驗都無從談起。
基礎網絡的效率就像一輛列車，時延是火車的速度(啟動時間)，而帶寬就像火車的車廂裝載量，整個傳輸的物理鏈路就像火車的鐵軌。目前現實條件下的移動網絡條件非常復雜，我們的目標很簡單，就是想讓所有用戶都能在手機淘寶獲得流暢的體驗。
下面這張圖，能夠讓大家更加直觀的了解國內的移動網絡環境。描述了從用戶到IDC的端到端的路由情況，不僅數據傳輸耗時長且丟包率高，同時安全性也是相當糟糕的，DNS劫持、內容劫持在中國就是家常便飯。
因此，我們在改善網絡通道上有很多的事情可以去做，去探索突破運營商基礎網絡的限制，力爭為用戶創造極致的購物體驗。
移動端的DNS問題相當普遍，可以詳讀以下專題文章：
《全面了解移動端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《移動端網絡優化之HTTP請求的DNS優化》
5、整體技術架構
為了滿足移動電商業務高速發展的需求，我們決定打造一個世界級的網絡接入服務，構建一個無線網絡下”水、電、煤“ 一樣的基礎設施。
這樣一個基礎設施需要做到的四個目標：
1）全雙工；
2）低延時；
3）高安全；
4）開放。
在這四個目標之上是圍繞這個接入服務配套的運維體系，幫助最終用戶取得良好的端上體驗的同時，幫助開發者快速構建自己的業務。
如上圖所示，在整個接入服務上我們劃分為兩層：
1）接入網關：負責連接的保持、消息的解析、消息的分發；
2）應用網關：實現各種應用層協議：API、SYNC、RPC、PUSH等，在應用網關的背后是具體的業務系統。
同時我們建立了一個統一調度服務，而不是采用傳統的DNS，調度服務是我們的控制中心，通過它我們可以強有力的指揮我們的客戶端，并且不會受到DNS污染的影響。
與服務端的分層架構對應的是客戶端的SDK，最底層的統一網絡庫SDK集中了我們對網絡優化的策略，并向上為各個應用網關技術的SDK提供API。
基于上面的開放架構，業務方可以選擇直接開放具體的后端服務對接不同的應用網關，不需要了解網絡背后的細節，并通過應用網關如API網關提供的開發工具快速生成客戶端代碼。業務方也可以基于這個接入層設計自己的協議。
統一接入層集中管理了用戶的設備、在線狀態，并提供信息的雙向傳遞能力。
如下圖所示：
網關將致力于解決中間網絡的通訊，為上層的服務提供高質量的雙向通訊能力。
6、穩定性與容災
穩定性與容災是服務端中間件永恒的主題，統一接入層這樣一個匯聚網關收益和風險是并存的，一旦這個入口故障了，波及的用戶范圍是不可想象的，如何做的更加穩定，是一個巨大的挑戰。
6.1 網關架構的優化
對于一個統一網關來說，對接的業務網關的信息傳遞特點是不一樣的，大部分的業務在全天都是比較平緩的，但是個別營銷類業務會在短時間內發布海量的信息，這樣的信息發布會搶占網關的大量資源，對于用戶的正常訪問會產生影響。
舉個例子：push服務需要通過網關推送2億條消息，而這些消息需要在短時間內全部推送完，而同時網關在為正常的用戶的交互提供服務，海量信息的推送和正常的用戶交互相互競爭資源，最終會造成正常用戶的交互失敗，對于業務來說，這是不可接受的。
基于上面的情況考慮，整個網關在布署上分為兩個集群：
1）一個集群處理常態的在線用戶訪問；
2）一個集群處理海量信息的推送。
如下圖所示，通過這樣的方式，避免了業務形態不同，對統一網關的沖擊，將不同的業務形態進行了隔離。
6.2 異地多活
在異地多活的整體方案中，統一網關承擔了快速引導流量的職責，也是這一方案順利實施的一個重要環節。
異地多活是一個多機房的整體方案，在多個地區同時存在對等的多個機房，以用戶維度劃分，多機房共同承擔全量用戶的流量；在單個機房發生故障時，故障機房的流量可以快速的被遷引到可用機房，減少故障的恢復時間。
6.2.1）無線接入層單元化的協商機制：
先看一下web端在這異地多活中的實現方式：
從上圖可以看到，瀏覽器的業務器求會發給CDN，由CDN上保存的分發規則，向后續的單元機房分發。
無線端也這樣做嗎？
1）客戶端擁有強大的能力，可以做的更靈活；
2）CDN的分發節點帶來更多的機器成本；
3）對于需要雙工通訊能力的客戶端，消息投遞更為復雜。
這些是我們思考與WEB不同的地方，是不是能做些不一樣的選擇？
如上圖所示, 我們借助了客戶端的強大能力，利用協商的機制來完成用戶的請求正確被分配到不同的單元。
含以下幾點：
1）客戶端的請求始終帶上當前用戶歸屬單元的信息；
2）當請求到達服務端時，服務端判斷用戶歸屬單元是否正確，不正確將用戶重定向到正確的單元 ；
3）當前請求由網關在服務端上通過跨單元調用保證業務的正確性；
4）當客戶端歸屬單元更新后，后續的請求都會發到正確的單元機房。
6.2.2）無線接入層單元化的旁路調度：
協商機制看起來很不錯，這里一個重磅炸彈丟過來了，機房的入口網絡斷了！
如上圖，外網不可用，協商的機會都沒有故障單元的用戶無法恢復，這時旁路的調度服務出場了。
如上圖，我們設計的調度中心這時又承擔了單元化的旁路調度職責，當app訪問的單元無法訪問的時候，app會訪問不同單元的調度中心，詢問用戶的歸屬單元。通過這種方式取得可用的單元節點，將用戶切到正確的單元。這個方案同樣適用于單機房的接入層網關不可用的場景。
6.2.3）應用層網關不可用：
某個單元機房的應用層網關不可用，這時等待應用網關排查問題需要的時間比較久，為了達到最快的故障恢復，我們通過開關把修改接入層的轉發規則，將流量切到可用的單元。
如下圖所示：
7、端到端網絡優化
7.1 統一網絡庫
在做網絡優化一開始，我們想做一個通用的網絡庫，這個網絡庫包含策略、httpDNS、SPDY協議等一切系統網絡優化需要的方方面面。（如果你對httpDNS不甚了解，可以詳讀《全面了解移動端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》）
上層api網關請求邏輯、推送邏輯、上傳下載邏輯對于這樣一個通用網絡庫來說都是業務。在分層上將通用網絡庫和上層應用邏輯分開、徹底解耦，對長期持續優化網絡是很有必要。
如下圖所示架構：
這樣架構上分離，可以讓我們更專注更系統化去做無線網絡優化。
統一網絡庫的幾個重要特性：
1）靈活控制客戶端網絡行為策略（建連、超時處理、請求協議、是否加密）；
2）包含HTTPDNS；
3）支持異地多活；
4）更細粒度控制和調度(域名級和域名下參數級)。
1、2、3、4均由網絡調度中心的集群控制，我們希望這個可以做到與業務無關，去掉一些阿里的業務屬性后，這個模塊大家可以理解為HTTPDNS，可以理解我們在HTTPDNS之外做了大量網絡優化的端到端的工作。
7.2 就近就快接入
基于網絡庫我們實現了一套智能學習的網絡策略，智能學習客戶端在不同網絡環境下建連策略，用戶重新回到這個網絡環境會給出最優的策略進行快速連接，并定期去更新或淘汰本地cache的歷史最優網絡策略。
為了建立更加迅速在各自網絡下穿透性更好，接入服務器支持了多種協議和端口，客戶端建連時可以極速接入網絡。
我們有一個重要指標是打開客戶端30秒內網絡請求成功率，就是關注連的快給用戶體驗帶來的價值。
基于調度中心，我們搭建了一個智能大數據分析平臺，將客戶端在在網絡請求過程中的數據如建連時間、首包收取時間、整包收取時間、ssl握手時間等重要指標收集上來 。根據這些指標分析出網絡異常區域，調整我們的就近就快接入規則，甚至推動IDC建設和CDN的布點完善。
7.3 弱網優化和抗抖動
在弱網優化上我們嘗試了QUIC協議，在網絡延時較高、丟包嚴重情況下比TCP有更好表現。
線上手機淘寶灰度版本實測切換到QUIC后，平均RT收益有接近20%。考慮QUIC在移動網絡可能存在穿透性問題，未來我們將采取SPDY為主，QUIC為輔助的模式來完善我們的網絡鏈接策略。
現在QUIC協議在移動端應用的越來越廣泛，有興趣的話可詳細以下文章：
《網絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》
《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《七牛云技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
同樣在一些網絡環境較差情況下，我們采取長短鏈接結合方式，在長鏈接遇到請求超時或穿透性較差情況，利用短鏈接HTTP短鏈接去請求數據（在移動網絡環境下HTTP協議尤其HTTP1.0的穿透性是最好的），這樣可以在一些極端情況下最大程度保證用戶體驗。
數據如下圖：
網絡切換和網絡抖動情況下的技術優化也是一個很重要的方面，我們經常遇到移動設備網絡切換和信號不穩定的情況，在這種情況我們怎么保證用戶的體驗？
針對這種情況我們的思路是有策略合理增加重試。我們對一個網絡請求以是否發送到socket緩沖區作為分割，將網絡請求生命周期劃分為“請求開始到發送到 socket緩沖區”和“已經發送到socket緩沖區到請求結束”兩個階段。在階段一內請求失敗了，會根據業務需求幫助業務請求去做重試。階段二請求失敗只針對讀操作提供重試能力。
設想一個場景：用戶在進電梯發起一個刷新數據請求，進到電梯因為網絡抖動的原因網絡鏈接斷了，這個時候我們能夠合理策略去做重試，這樣當用戶離開電梯時很可能網絡請求重試成功，幫助用戶拉到了想要的數據，提升了用戶體驗和客戶端的網絡抗抖動能力。
7.4 加密傳輸1秒鐘法則
眾所周知的傳統https的整個握手流程是非常重的，在網絡質量不高的情況下，造成建連過慢，用戶體驗慘不能睹，甚至都無法完成安全握手。然而從安全的角度我們是需要一個安全的傳輸通道保護用戶的隱私數據。
安全與網絡這一對沖突放在我們的面前，需要在技術上有所突破，因此我們自建了一套slight-ssl的技術，參考了tls1.3的協議，通過合并請求，優化加密算法，運用session-ticket等策略，最終在安全和體驗之間找到了一個平衡點，在基本不犧牲用戶體驗的基礎上，達到了安全傳輸的目地, 同時還大幅度提升了服務端的性能。通過技術的創新，我們實現了無線網絡加密傳輸下1秒鐘法則。
關于TLS1.3在移動端的應用，也可以詳讀微信團隊分享的這篇《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》。
附錄：有關移動端弱網方面的資料匯總
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《聊聊IOS中網絡編程長連接的那些事》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《全面了解移動端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網絡深度優化實踐分享(二)：網絡連接優化篇》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《愛奇藝移動端網絡優化實踐分享：網絡請求成功率優化篇》
《美團點評的移動端網絡優化實踐：大幅提升連接成功率、速度等》
《5G時代已經到來，TCP/IP老矣，尚能飯否？》
《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《談談移動端 IM 開發中登錄請求的優化》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
>> 更多同類文章 ……
（本文已同步發布于：http://www.52im.net/thread-3110-1-1.html）
