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