行動網路優化是超級App永恆的話題，對於無線電商來說更為重要，網路請求體驗跟使用者的購買行為息息相關，手機淘寶從過去的HTTP API閘道器，到2014年升級支援SPDY，2015年雙十一自研高效能、全雙工、安全的ACCS（阿里雲通道服務)扛住雙十一戰場主要流量，無論是基礎架構的演進、網路調優、協議的優化、異地多活、網路排程上都有不少寶貴的經驗與大家分享。

ACCS基於無線場景精心設計的雙工 、安全、低時延、開放的移動統一接入層服務，在雙十一當天穩定高效地服務了近2億的線上使用者，支援了峰值4500萬的線上長連線，這個背後的故事以及我們的思考是什麼呢？

1.業務高速發展下訴求

回到一年前，移動電商在2014年雙十一業務開始興起，2014年雙十一當天移動成交243億佔整體571億的42.6%，業務高速發展希望更多主動推送去觸達使用者，一些新的玩法和互動形式，需要連線買家與買家、買家與賣家、買家與達人，因為沒有有效的通道能力，業務採取的是不停去輪詢伺服器，一來對伺服器造成不必要的壓力，二來對於使用者手機的電量流量也是極大的浪費，關鍵在大促當天不必要的請求過大甚至會導致後端叢集限流，從而影響到使用者體驗。

資訊傳播形態的變化的背後是移動化帶來新的技術特徵導致的結果。在過去的幾年，移動電商從無到有，手機淘寶一直是這個領域的先行者。移動電商從最初的複製WEB的業務形態到移動特性不斷湧現，更多的互動形式的出現，向社交化、娛樂化不斷邁進的今天，一個單純的商品的陳列架形式已經不能滿足業務的需求。

業務上需要實時的觸達使用者，充分發揮移動的特性，將消費時間的碎片利用起來，事實也證明了使用者的消費時間隨著移動化的程序不斷髮生變化，逐步分佈到全天的碎片時間中。同時貨架形態也在向社群化、娛樂化的方向發展，這些都對網路層連線使用者有了更高的要求。更多的媒體形態和展示方式，對網路層提出了更多元的要求。大家可以關注到手機淘寶內的訊息盒子、微淘、淘友這些產品都是業務求變的體現，業務的變化倒逼技術的前進。

2.行動網路環境依然嚴峻

行動網路的速度在過去幾年有很大提升，但網路環境的多樣性和差異性使行動網路的環境更加複雜，在去年雙十一之前我們還常遇到一些行動網路劫持的事情。網路劫持這塊問題的排查效率很低，需要找到使用者、復現現場，甚至找網工、運營商配合排查，一查就是幾天過去。

同時在我們的輿情反饋上總是看到使用者在說－“某個頁面載入中、頁面打不開、請求很慢、開啟某個功能很慢”，面對這些問題過去我們是沒有太好的辦法，只能貓抓耗子一樁樁去排雷很被動。很多網路的問題是偶現的，一旦錯過現在就無從查起，背後的原因很多：

運營商問題機房部署原因客戶端SDK Bug弱網和網路抖動DNS劫持和資料篡改

PC時代我們訪問網站的接入條件是相對恆定的，所以在開發時很少考慮網路對使用者體驗的影響。但是移動APP則不然，尤其是在中國，基礎的行動網路環境並不好，而且我們有很多使用者的訪問是發生在地鐵、公車這樣的移動環境下，移動基站的頻繁切換進一步增加了網路的不穩定。從手機淘寶的資料可以看出，我們每天活躍使用者中有不少來自於類似2G這樣的弱網環境。如果端到雲的連線不穩定、高延時，那麼所有的使用者體驗都無從談起。

基礎網路的效率就像一輛列車，時延是火車的速度(啟動時間)，而頻寬就像火車的車廂裝載量，整個傳輸的物理鏈路就像火車的鐵軌。目前現實條件下的行動網路條件非常複雜，既有高鐵這樣先進的傳輸渠道，也有不少老舊緩慢的綠皮車還在服務很多使用者。我們的目標很簡單，就是想讓所有使用者都能在手機淘寶獲得流暢的體驗，不論你坐的是“高鐵”還是“綠皮車”。

下面這張圖，能夠讓大家更加直觀的了解中國的行動網路環境。描述了從使用者到IDC的端到端的路由情況，不僅資料傳輸耗時長且丟包率高，同時安全性也是相當糟糕的，DNS劫持、內容劫持在中國就是家常便飯。

因此我們在改善網路通道上有很多的事情可以去做，去探索突破運營商基礎網路的限制，力爭為使用者創造極致的購物體驗。

3.ACCS整體架構

為了滿足移動電商業務高速發展的需求，我們決定打造一個世界級的網路接入服務，構建一個無線網路下”水、電、煤“ 一樣的基礎設施。這樣一個基礎設施需要做到的四個目標：

“ 雙工、低延時、安全、開放”。在這四個目標之上是圍繞這個接入服務配套的運維體系，幫助終端使用者取得良好的端上體驗的同時，幫助開發者快速構建自己的業務。

如圖-1所示，在整個接入服務上我們劃分為兩層，接入閘道器層和應用閘道器層。接入閘道器負責連線的保持、訊息的解析、訊息的分發。應用閘道器實現各種應用層協議：API、SYNC、RPC、PUSH等，在應用閘道器的背後是具體的業務系統。同時我們建立了一個統一排程服務，而不是採用傳統的DNS，排程服務是我們的控制中心，通過它我們可以強有力的指揮我們的客戶端，並且不會受到DNS汙染的影響。

與服務端的分層架構對應的是客戶端的SDK，最底層的統一網路庫SDK集中了我們對網路優化的策略，並向上為各個應用閘道器技術的SDK提供API。

(圖-1)

基於上面的開放架構，業務方可以選擇直接開放具體的後端服務對接不同的應用閘道器，不需要了解網路背後的細節，並通過應用閘道器如API閘道器提供的開發工具快速生成客戶端程式碼。業務方也可以基於這個接入層設計自己的協議。

統一接入層集中管理了使用者的裝置、線上狀態，並提供資訊的雙向傳遞能力。如下圖所示：

閘道器將致力於解決中間網路的通訊，為上層的服務提供高品質的雙向通訊能力。

4.穩定性與容災

穩定性與容災是服務端中介軟體永恆的主題，統一接入層這樣一個匯聚閘道器收益和風險是並存的，一旦這個入口故障了，波及的使用者範圍是不可想象的，如何做的更加穩定，是一個巨大的挑戰。

4.1 閘道器架構的優化

對於一個統一閘道器來說，對接的業務閘道器的資訊傳遞特點是不一樣的，大部分的業務在全天都是比較平緩的，但是個別營銷類業務會在短時間內釋出海量的資訊，這樣的資訊釋出會搶佔閘道器的大量資源，對於使用者的正常訪問會產生影響。

舉個例子，push服務需要通過閘道器推送2億條訊息，而這些訊息需要在短時間內全部推送完，而同時閘道器在為正常的使用者的互動提供服務，海量資訊的推送和正常的使用者互動相互競爭資源，最終會造成正常使用者的互動失敗，對於業務來說，這是不可接受的。

基於上面的情況考慮整個閘道器在佈署上分為兩個叢集，一個叢集處理常態的線上使用者訪問，另一個叢集處理海量資訊的推送。如下圖-2所示，通過這樣的方式，避免了業務形態不同，對統一閘道器的衝擊，將不同的業務形態進行了隔離。

(圖-2)

4.2 異地多活

阿里這兩年一直在實施的異地多活的架構，在異地多活的整體方案中，統一閘道器承擔了快速引導流量的職責，也是這一方案順利實施的一個重要環節。

異地多活是一個多機房的整體方案，在多個地區同時存在對等的多個機房，以使用者維度劃分，多機房共同承擔全量使用者的流量；在單個機房發生故障時，故障機房的流量可以快速的被遷引到可用機房，減少故障的恢復時間。

4.2.1 無線接入層單元化的協商機制

先看一下web端在這異地多活中的實現方式

(圖-3)

從圖-3可以看到，瀏覽器的業務器求會發給CDN，由CDN上儲存的分發規則，向後續的單元機房分發。無線端也這樣做嗎？客戶端擁有強大的能力，可以做的更靈活；CDN的分發節點帶來更多的機器成本；對於需要雙工通訊能力的客戶端，訊息投遞更為複雜。這些是我們思考與WEB不同的地方，是不是能做些不一樣的選擇？

(圖-4)

如圖-4, 我們藉助了客戶端的強大能力，利用協商的機制來完成使用者的請求正確被分配到不同的單元，含以下幾點:

客戶端的請求始終帶上當前使用者歸屬單元的資訊。當請求到達服務端時，服務端判斷使用者歸屬單元是否正確，不正確將使用者重定向到正確的單元 。當前請求由閘道器在服務端上通過跨單元呼叫保證業務的正確性。當客戶端歸屬單元更新後，後續的請求都會發到正確的單元機房。

4.2.2 無線接入層單元化的旁路排程

協商機制看起來很不錯，這裡一個重磅炸彈丟過來了，機房的入口網路斷了！

(圖-5)

如圖-5, 外網不可用，協商的機會都沒有故障單元的使用者無法恢復，這時旁路的排程服務出場了。

(圖-6)

如上圖-6, 我們設計的排程中心這時又承擔了單元化的旁路排程職責,當app訪問的單元無法訪問的時候, app會訪問不同單元的排程中心，詢問使用者的歸屬單元，通過這種方式取得可用的單元節點，將使用者切到正確的單元。這個方案同樣適用於單機房的接入層閘道器不可用的場景。

4.2.3 應用層閘道器不可用

某個單元機房的應用層閘道器不可用，這時等待應用閘道器排查問題需要的時間比較久，為了達到最快的故障恢復，我們通過開關把修改接入層的轉發規則，將流量切到可用的單元。如下圖-7

(圖-7)

5.端到端網路優化

5.1 統一網路庫

在做網路優化一開始，我們想做一個通用的網路庫，這個網路庫包含策略、httpDNS、SPDY協議等一切系統網路優化需要的方方面面。上層api閘道器請求邏輯、推送邏輯、上傳下載邏輯對於這樣一個通用網路庫來說都是業務。在分層上將通用網路庫和上層應用邏輯分開、徹底解耦，對長期持續優化網路是很有必要。如下圖-8所示架構。

(圖-8)

這樣架構上分離，可以讓我們更專注更系統化去做無線網路優化。統一網路庫的幾個重要特性:

靈活控制客戶端網路行為策略(建連、超時處理、請求協議、是否加密）包含HTTPDNS，支援異地多活更細粒度控制和排程(域名級和域名下引數級)

1、2、3均由網路排程中心的叢集控制，我們希望這個可以做到與業務無關，去掉一些阿里的業務屬性後，這個模組大家可以理解為HTTPDNS，可以理解我們在HTTPDNS之外做了大量網路優化的端到端的工作。

5.2 就近就快接入

基於網路庫我們實現了一套智慧學習的網路策略，智慧學習客戶端在不同網路環境下建連策略，使用者重新回到這個網路環境會給出最優的策略進行快速連線，並定期去更新或淘汰本地cache的歷史最優網路策略。為了建連更加迅速在各自網路下穿透性更好，接入伺服器支援了多種協議和埠，客戶端建連時可以極速接入網路。我們有一個重要指標是開啟客戶端30S內網路請求成功率，就是關注連的快給使用者體驗帶來的價值。

基於排程中心，我們搭建了一個智慧大資料分析平臺，將客戶端在在網路請求過程中的資料如建連時間、首包收取時間、整包收取時間、ssl握手時間等重要指標收集上來 。根據這些指標分析出網路異常區域，調整我們的就近就快接入規則，甚至推動IDC建設和CDN的布點完善。

5.3 弱網優化和抗抖動

在弱網優化上我們嘗試了QUIC,在網路延時較高、丟包嚴重情況下比TCP有更好表現。線上手機淘寶灰度版本實測切換到QUIC後，平均RT收益有接近20%。考慮QUIC在行動網路可能存在穿透性問題,未來我們將採取SPDY為主，QUIC為輔助的模式來完善我們的網路連結策略。

同樣在一些網路環境較差情況下，我們採取長短連結結合方式，在長連結遇到請求超時或穿透性較差情況，利用短連結HTTP短連結去請求資料(在行動網路環境下HTTP協議尤其HTTP1.0的穿透性是最好的)，這樣可以在一些極端情況下最大程度保證使用者體驗。資料如下圖-9

網路切換和網路抖動情況下的技術優化也是一個很重要的方面，我們經常遇到移動裝置網路切換和訊號不穩定的情況，在這種情況我們怎麼保證使用者的體驗？

針對這種情況我們的思路是有策略合理增加重試。我們對一個網路請求以是否傳送到socket緩衝區作為分割，將網路請求生命週期劃分為“請求開始到傳送到 socket緩衝區”和“已經發送到socket緩衝區到請求結束”兩個階段。在階段一內請求失敗了，會根據業務需求幫助業務請求去做重試。階段二請求失敗只針對讀操作提供重試能力。

設想一個場景：使用者在進電梯發起一個重新整理資料請求，進到電梯因為網路抖動的原因網路連結斷了，這個時候我們能夠合理策略去做重試，這樣當用戶離開電梯時很可能網路請求重試成功，幫助使用者拉到了想要的資料，提升了使用者體驗和客戶端的網路抗抖動能力。

5.4 加密傳輸1S鍾法則

眾所周知的傳統https的整個握手流程是非常重的，在網路品質不高的情況下，造成建連過慢，使用者體驗慘不能睹，甚至都無法完成安全握手；然而從安全的角度我們是需要一個安全的傳輸通道保護使用者的隱私資料。

安全與網路這一對衝突放在我們的面前，需要在技術上有所突破，因此我們自建了一套slight-ssl的技術，參考了tls1.3的協議，通過合併請求，優化加密演算法，運用session-ticket等策略，最終在安全和體驗之間找到了一個平衡點，在基本不犧牲使用者體驗的基礎上，達到了安全傳輸的目地, 同時還大幅度提升了服務端的效能。通過技術的創新，我們實現了無線網路加密傳輸下1S鍾法則。

6.總結和感悟

手機淘寶2015年雙十一網路接入工作關鍵字總結:

ACCS、閘道器架構優化、異地多活、弱網優化和抗抖動、加密傳輸1S鍾法則

幾點感悟：

網路接入任重道遠，對於手機淘寶這樣一個億級UV無線電商平臺,穩定性是立足之本。接入層架構調整要麼基於業務需求（能夠適應業務的變化的架構才是最合適的)，要麼能夠極大節省成本和提升穩定性。架構的演進一定是迭代式不能一蹴而就，重視積累和反思。移動接入層解決方案上可以更多利用客戶端能力，這個是無線對比PC Web的優勢所在。無線網路這兩年網速是提升了但網路環境更加複雜，萬物互聯、裝置隨時隨地線上、運營商的複雜性會對行動網路優化帶來更多的挑戰，端到端的網路優化以及推進運營商合作任重而道遠。