1、引言
網(wǎng)絡(luò)優(yōu)化對(duì)于移動(dòng)端App產(chǎn)品的用戶體驗(yàn)至關(guān)重要，也與公司的運(yùn)營(yíng)和營(yíng)收息息相關(guān)。
這里列舉兩個(gè)公開的數(shù)據(jù)：
“《頁(yè)面加載超過(guò)3秒，57%的用戶會(huì)離開》”
“《Amazon頁(yè)面加載延長(zhǎng)1秒，一年就會(huì)減少16億美金營(yíng)收》”
網(wǎng)絡(luò)性能對(duì)于用戶體驗(yàn)的影響，將非常直接地反饋到業(yè)務(wù)的運(yùn)營(yíng)上。
而且，移動(dòng)網(wǎng)絡(luò)固有的弱網(wǎng)問(wèn)題、DNS問(wèn)題、連接性能等等都無(wú)法跟傳統(tǒng)的固定網(wǎng)絡(luò)相比。所以，優(yōu)化移動(dòng)端網(wǎng)絡(luò)，顯的尤其必要。
對(duì)于即時(shí)通訊應(yīng)用（IM、消息推送）的開發(fā)者來(lái)說(shuō)，無(wú)論是短連接還是長(zhǎng)連接優(yōu)化，都會(huì)直接體現(xiàn)在APP的體驗(yàn)上，必竟IM或類IM應(yīng)用都是用戶使用頻度很高的場(chǎng)景，網(wǎng)絡(luò)有關(guān)的體驗(yàn)問(wèn)題稍有懈怠，就會(huì)被用戶無(wú)限放大，所以回避也不是解決問(wèn)題的正確之道。
有鑒于此，即時(shí)通訊網(wǎng)整理收集了相當(dāng)多有關(guān)移動(dòng)弱網(wǎng)的文章（包括本篇），希望能為你移動(dòng)端網(wǎng)絡(luò)優(yōu)化帶來(lái)一些啟發(fā)。
本文同步發(fā)布于“即時(shí)通訊技術(shù)圈”公眾號(hào)，歡迎關(guān)注：
2、本文作者
周輝：美團(tuán)點(diǎn)評(píng)移動(dòng)技術(shù)專家，移動(dòng)架構(gòu)負(fù)責(zé)人。移動(dòng)端開發(fā)10年以上經(jīng)驗(yàn)。
* 領(lǐng)導(dǎo)和參加過(guò)公司大部分移動(dòng)客戶端產(chǎn)品的架構(gòu)設(shè)計(jì)和業(yè)務(wù)開發(fā)；
* 2010 年加入原大眾點(diǎn)評(píng)，現(xiàn)專注于美團(tuán)點(diǎn)評(píng)客戶端底層架構(gòu)的開發(fā)和維護(hù)；
* 2016 年所負(fù)責(zé)的移動(dòng)端通信架構(gòu)獲得公司級(jí)別技術(shù)突破大獎(jiǎng)。
3、相關(guān)文章
《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》
《移動(dòng)端IM開發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》（推薦）
《移動(dòng)端IM開發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》（推薦）
《全面了解移動(dòng)端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》
《美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半》
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(一)：DNS優(yōu)化篇》（推薦）
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(二)：網(wǎng)絡(luò)連接優(yōu)化篇》（推薦）
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(三)：移動(dòng)端弱網(wǎng)優(yōu)化篇》
《愛(ài)奇藝移動(dòng)端網(wǎng)絡(luò)優(yōu)化實(shí)踐分享：網(wǎng)絡(luò)請(qǐng)求成功率優(yōu)化篇》（推薦）
《5G時(shí)代已經(jīng)到來(lái)，TCP/IP老矣，尚能飯否？》
《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫(kù)，即將開源》
《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺(tái)組件庫(kù)Mars已正式開源》
《談?wù)勔苿?dòng)端 IM 開發(fā)中登錄請(qǐng)求的優(yōu)化》
《騰訊原創(chuàng)分享(一)：如何大幅提升移動(dòng)網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》
《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（下篇）》
《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（上篇）》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十一)：為什么WiFi信號(hào)差？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十二)：上網(wǎng)卡頓？網(wǎng)絡(luò)掉線？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十三)：為什么手機(jī)信號(hào)差？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十四)：高鐵上無(wú)線上網(wǎng)有多難？一文即懂！》
4、內(nèi)容概述
如何防止網(wǎng)絡(luò)通信被劫持？
如何提升用戶頁(yè)面打開速度？
老板反饋?lái)?yè)面打不開時(shí)你該怎么辦？
來(lái)看看美團(tuán)點(diǎn)評(píng)客戶端網(wǎng)絡(luò)優(yōu)化實(shí)踐中的經(jīng)驗(yàn)分享吧。
在這篇文章里你可以了解到美團(tuán)點(diǎn)評(píng)移動(dòng)架構(gòu)團(tuán)隊(duì)在提升移動(dòng)通信質(zhì)量方面所做的嘗試，以及逐漸發(fā)展出的一整套監(jiān)控和通信方案，為你優(yōu)化自己App的網(wǎng)絡(luò)通信質(zhì)量打開新的思路。
5、問(wèn)題現(xiàn)狀
在討論解決方法之前，我們來(lái)梳理一下，在移動(dòng)網(wǎng)絡(luò)請(qǐng)求過(guò)程中，主要都出現(xiàn)了哪些最常見的問(wèn)題？
▼ 首先：是網(wǎng)絡(luò)不可用問(wèn)題。主要由以下幾種原因?qū)е拢?/strong>
- 1）GFW的攔截，原因你懂的；
- 2）DNS的劫持，端口的意外封禁等；
- 3）偏遠(yuǎn)地區(qū)網(wǎng)絡(luò)基礎(chǔ)設(shè)施比較差。
▼ 其次：是網(wǎng)絡(luò)加載時(shí)間長(zhǎng)問(wèn)題。這些原因包括：
- 1）移動(dòng)設(shè)備出于省電的目的，發(fā)出網(wǎng)絡(luò)請(qǐng)求前需要先預(yù)熱通信芯片；
- 2）網(wǎng)絡(luò)請(qǐng)求需要跨網(wǎng)絡(luò)運(yùn)營(yíng)商，物理路徑長(zhǎng)；
- 3）HTTP請(qǐng)求是基于Socket設(shè)計(jì)的，請(qǐng)求發(fā)起之前會(huì)經(jīng)歷三次握手，斷開時(shí)又會(huì)進(jìn)行四次揮手。
▼ 最后：是HTTP協(xié)議的數(shù)據(jù)安全問(wèn)題。具體的原因有：
- 1）HTTP協(xié)議的數(shù)據(jù)容易被抓包；
- 2）Post包體數(shù)據(jù)經(jīng)過(guò)加密能夠避免泄露，但協(xié)議中的URL和header部分還是會(huì)暴露給抓包軟件（HTTPS也面臨相似的問(wèn)題）；
- 3）運(yùn)營(yíng)商數(shù)據(jù)惡意篡改嚴(yán)重。
如下圖中，App的網(wǎng)頁(yè)中就被運(yùn)營(yíng)商插入了廣告：
當(dāng)然，上述問(wèn)題并非我們憑空想象。在美團(tuán)點(diǎn)評(píng)，監(jiān)控團(tuán)隊(duì)開發(fā)了基于端到端的客戶端監(jiān)控平臺(tái)。這里要先解釋一下“端到端”的含義：是指請(qǐng)求從客戶端發(fā)出到服務(wù)端響應(yīng)返回的整個(gè)過(guò)程。它區(qū)別于后臺(tái)服務(wù)監(jiān)控，是一種從用戶角度觀察到的真實(shí)體驗(yàn)監(jiān)控。
通過(guò)美團(tuán)點(diǎn)評(píng)的監(jiān)控工具，可以很清晰地看到各種網(wǎng)絡(luò)原因和占比：
6、短連接優(yōu)化方案1：域名合并
面對(duì)上節(jié)中提到的網(wǎng)絡(luò)問(wèn)題，我們首先在HTTP短連請(qǐng)求中進(jìn)行了一些優(yōu)化嘗試。
隨著開發(fā)規(guī)模逐漸擴(kuò)大，各業(yè)務(wù)團(tuán)隊(duì)出于獨(dú)立性和穩(wěn)定性的考慮，紛紛申請(qǐng)了自己的三級(jí)域名。
App中的API域名越來(lái)越多，如下所示：
search.api.dianping.com
ad.api.dianping.com
tuangou.api.dianping.com
waimai.api.dianping.com
movie.api.dianping.com
… ...
App中域名多了之后，將面臨下面幾個(gè)問(wèn)題：
- 1）HTTP請(qǐng)求需要跟不同服務(wù)器建立連接，增加了網(wǎng)絡(luò)的并發(fā)連接數(shù)量損耗；
- 2）每條域名都需要經(jīng)過(guò)DNS服務(wù)來(lái)解析服務(wù)器IP。
如果想將所有的三級(jí)域名都合并為一個(gè)域名，又會(huì)面臨巨大的項(xiàng)目推進(jìn)難題。因?yàn)椴煌瑯I(yè)務(wù)團(tuán)隊(duì)當(dāng)初正是出于獨(dú)立性和穩(wěn)定性的考慮才把域名進(jìn)行拆分，現(xiàn)在再想把域名合并起來(lái)，勢(shì)必會(huì)遭遇巨大的阻力。
所以我們面臨的是：
- 1）既要將域名合并；
- 2）又要提升網(wǎng)絡(luò)連接效率；
- 3）又不能改造后端業(yè)務(wù)服務(wù)器。
經(jīng)過(guò)討論，我們想到了一個(gè)折中的方案。
如上圖所示，該方案的核心思想在于：保持客戶端業(yè)務(wù)層代碼編寫的網(wǎng)絡(luò)請(qǐng)求與后端業(yè)務(wù)服務(wù)器收到的請(qǐng)求保持一致，請(qǐng)求發(fā)出前，在客戶端網(wǎng)絡(luò)層對(duì)域名收編，請(qǐng)求送入后端，在SLB（Server Load Balancing）中對(duì)域名進(jìn)行還原。
▼ 網(wǎng)絡(luò)請(qǐng)求發(fā)出前，在客戶端的網(wǎng)絡(luò)底層將URL中的域名做簡(jiǎn)單的替換，我們稱之為“域名收編”。
例如：URL “http:// ad.api.dianping.com/command?param1=123" 在網(wǎng)絡(luò)底層被修改為 “http:// api.dianping.com/ad/command?param1=123" 。
這里，將域名“ad.api.dianping.com”替換成了”api.dianping.com”，而緊跟在域名后的其后的”ad”表示了這是一條與廣告業(yè)務(wù)有關(guān)的域名請(qǐng)求。
依此類推，所有URL的域名都被合并為“api.dianping.com”。子級(jí)域名信息被隱藏在了域名后的path中。
▼ 被改造的請(qǐng)求被送到網(wǎng)絡(luò)后端，在SLB中，擁有與客戶端網(wǎng)絡(luò)層相反的一套域名反收編邏輯，稱為“域名還原”。
例如：“http://api.dianping.com/ad/command?param1=123" 在SLB中被還原為 “http://ad.api.dianping.com/command?param1=123" 。 SLB的作用是將請(qǐng)求分發(fā)到不同的業(yè)務(wù)服務(wù)器，在經(jīng)過(guò)域名還原之后，請(qǐng)求已經(jīng)與客戶端業(yè)務(wù)代碼中原始請(qǐng)求一致了。
該方案具有如下優(yōu)勢(shì)：
- 1）域名得到了收編，減少了DNS調(diào)用次數(shù)，降低了DNS劫持風(fēng)險(xiǎn)；
- 2）針對(duì)同一域名，可以利用Keep-Alive來(lái)復(fù)用Http的連接；
- 3）客戶端業(yè)務(wù)層不需要修改代碼，后端業(yè)務(wù)服務(wù)也不需要進(jìn)行任何修改。
7、短連接優(yōu)化方案2：IP直連
經(jīng)過(guò)域名合并方案，我們已經(jīng)將所有的域名都統(tǒng)一成了“api.dianping.com”。針對(duì)這唯一的域名，我們可以在客戶端架設(shè)自己的DNS服務(wù)。
方案很簡(jiǎn)單：
- 1）程序啟動(dòng)的時(shí)候拉取“api.dianping.com”對(duì)應(yīng)的所有的IP列表；
- 2）對(duì)所有IP進(jìn)行跑馬測(cè)試，找到速度最快的IP（后續(xù)所有的HTTPS請(qǐng)求都將域名更換為跑馬最快的IP即可）。
舉個(gè)例子，假如：經(jīng)過(guò)跑馬測(cè)試發(fā)現(xiàn)域名“api.dianping.com”對(duì)應(yīng)最快的IP是“1.23.456.789”。
URL“http:// api.dianping.com/ad/command?param1=123”將被替換為“http:// 1.23.456.789/ad/command?param1=123”
IP直連方案有下面幾大優(yōu)勢(shì)：
- 1）摒棄了系統(tǒng)DNS，減少外界干擾，擺脫DNS劫持困擾；
- 2）自建DNS更新時(shí)機(jī)可以控制；
- 3）IP列表更換方便。
此外，如果你的App域名沒(méi)有經(jīng)過(guò)合并，域名比較多，也建議可以嘗試使用HttpDNS方案。
可以參考以下幾篇文章：
《全面了解移動(dòng)端DNS域名劫持等雜癥：技術(shù)原理、問(wèn)題根源、解決方案等》
《美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半》
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(一)：DNS優(yōu)化篇》
《愛(ài)奇藝移動(dòng)端網(wǎng)絡(luò)優(yōu)化實(shí)踐分享：網(wǎng)絡(luò)請(qǐng)求成功率優(yōu)化篇》
另外，IP直連方案對(duì)HTTPS中證書的處理需要注意：HTTPS由于要求證書綁定域名，如果做IP直連方案可能會(huì)遇到一些麻煩，這時(shí)我們需要對(duì)客戶端的HTTPS的域名校驗(yàn)部分進(jìn)行改造，參見《https信任證書的三種方式》 。
經(jīng)過(guò)域名合并加上IP直連方案改造后，HTTP短連的端到端成功率從95%提升到97.5%，網(wǎng)絡(luò)延時(shí)從1500毫秒降低到了1000毫秒，可謂小投入大產(chǎn)出。
8、進(jìn)一步提升端到端成功率：長(zhǎng)連通道的建設(shè)
接下來(lái)要想進(jìn)一步提升端到端成功率，就要開始進(jìn)行長(zhǎng)連通道建設(shè)了。
8.1 HTTP/2技術(shù)
提到長(zhǎng)連通道建設(shè)，首先讓人想到的應(yīng)該是HTTP/2技術(shù)（見：《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計(jì)思路》）——它具有異步連接多路復(fù)用、頭部壓縮、請(qǐng)求響應(yīng)管線化等眾多優(yōu)點(diǎn)。
如果查看HTTP/2的拓?fù)浣Y(jié)構(gòu)，其實(shí)非常簡(jiǎn)單：
HTTP/2在客戶端與服務(wù)器之間建立長(zhǎng)連通道，將同一域名的請(qǐng)求都放在長(zhǎng)連通道上進(jìn)行。
這種拓?fù)浣Y(jié)構(gòu)有如下一些缺點(diǎn)：
- 1）請(qǐng)求基于DNS，仍將面臨DNS劫持風(fēng)險(xiǎn)；
- 2）不同域名的請(qǐng)求需要建立多條連接；
- 3）網(wǎng)絡(luò)通道難以優(yōu)化：客戶端與服務(wù)器之間是公網(wǎng)鏈路，如果在多地部署服務(wù)器，成本消耗又會(huì)很大；
- 4）業(yè)務(wù)改造難度大：部署HTTP/2，需要對(duì)業(yè)務(wù)服務(wù)器進(jìn)行改造，而且使用的業(yè)務(wù)服務(wù)器越多，需要改造的成本也越大；
- 5）網(wǎng)絡(luò)協(xié)議可訂制程度小。
8.2 代理長(zhǎng)連的模式
與HTTP/2相區(qū)別，我們這里推薦另一種代理長(zhǎng)連的模式。
這種模式的拓?fù)鋱D如下：
基本思路為：
- 1）在客戶端與業(yè)務(wù)服務(wù)器之間架設(shè)代理長(zhǎng)連服務(wù)器；
- 2）客戶端與代理服務(wù)器建立TCP長(zhǎng)連通道；
- 3）客戶端的HTTP請(qǐng)求被轉(zhuǎn)換為了TCP通道上的二進(jìn)制數(shù)據(jù)包；
- 4）代理服務(wù)器負(fù)責(zé)與業(yè)務(wù)服務(wù)器進(jìn)行HTTP請(qǐng)求，請(qǐng)求的結(jié)果通過(guò)長(zhǎng)連通道送回客戶端。
與HTTP/2模式對(duì)比，代理長(zhǎng)連模式具有下面一些優(yōu)勢(shì)：
1）對(duì)DNS無(wú)依賴：
客戶端與代理服務(wù)器之間的長(zhǎng)連通道是通過(guò)IP建立的，與DNS沒(méi)有關(guān)系。客戶端的HTTP請(qǐng)求被轉(zhuǎn)換為二進(jìn)制數(shù)據(jù)流送到代理服務(wù)器，也不需要進(jìn)行DNS解析。代理服務(wù)器轉(zhuǎn)發(fā)請(qǐng)求到業(yè)務(wù)服務(wù)器時(shí)，都處于同一內(nèi)網(wǎng)，因此可以自己搭建DNS服務(wù)，減少對(duì)公網(wǎng)DNS服務(wù)的依賴。從這個(gè)層面上說(shuō)，代理長(zhǎng)連模式天生具有防DNS劫持的能力。
2）不同域名的請(qǐng)求可以復(fù)用同一條長(zhǎng)連通道；
3）通道易優(yōu)化：
與部署業(yè)務(wù)服務(wù)器相比，部署代理長(zhǎng)連服務(wù)器的代價(jià)就小了很多，可以在全國(guó)甚至全世界多地部署代理長(zhǎng)連服務(wù)器。客戶端在選擇代理長(zhǎng)連服務(wù)器時(shí)，可以通過(guò)跑馬找到最快的服務(wù)器IP進(jìn)行連接。另一方面，代理服務(wù)器與業(yè)務(wù)服務(wù)器之間的網(wǎng)絡(luò)通道也可以進(jìn)行優(yōu)化，通過(guò)架設(shè)專線或者租用騰訊云等方式可以大大提升通道服務(wù)質(zhì)量；
4）對(duì)業(yè)務(wù)完全透明：
客戶端的業(yè)務(wù)代碼只要接入網(wǎng)絡(luò)層的SDK即可，完全不用關(guān)心網(wǎng)絡(luò)請(qǐng)求使用的是長(zhǎng)連通道還是短連通道。代理服務(wù)器將客戶端的請(qǐng)求還原為HTTP短連方式送到業(yè)務(wù)服務(wù)器，業(yè)務(wù)服務(wù)器不需要進(jìn)行任何改造。
5）網(wǎng)絡(luò)協(xié)議完全自定義。
8.3 自建代理長(zhǎng)連模式的過(guò)程
自建長(zhǎng)連建設(shè)大概可以分為以下幾個(gè)周期。
▼ ① 中轉(zhuǎn)服務(wù)的開發(fā)和部署：
作為開發(fā)的初級(jí)階段，這一時(shí)期的任務(wù)主要是搭建代理中轉(zhuǎn)服務(wù)器，并架設(shè)完整鏈路結(jié)構(gòu)。
▼ ② 加密通道的建設(shè)：
為了保護(hù)TCP通道上數(shù)據(jù)的安全性，客戶端與代理長(zhǎng)連服務(wù)器之間的二進(jìn)制通信數(shù)據(jù)可以利用加密來(lái)保障數(shù)據(jù)安全。
▼ ③ 專線建設(shè)：
在代理長(zhǎng)連服務(wù)器與后臺(tái)業(yè)務(wù)服務(wù)器之間建設(shè)專線。使用專線，可以大大降低公網(wǎng)環(huán)境的干擾，保障服務(wù)的穩(wěn)定性。
▼ ④ 自動(dòng)降級(jí)Failover建設(shè)：
由于客戶端的請(qǐng)求都放在TCP通道上進(jìn)行，當(dāng)代理長(zhǎng)連服務(wù)器需要升級(jí)或者由于極端情況發(fā)生了故障時(shí)，將會(huì)造成客戶端的整體網(wǎng)絡(luò)服務(wù)不可用。
為了解決這個(gè)問(wèn)題，我們準(zhǔn)備了Failover降級(jí)方案——當(dāng)TCP通道無(wú)法建立或者發(fā)生故障時(shí)，可以使用UDP面向無(wú)連接的特性提供另一條請(qǐng)求通道，或者繞過(guò)代理長(zhǎng)連服務(wù)器之間向業(yè)務(wù)服務(wù)器發(fā)起HTTP公網(wǎng)請(qǐng)求（本文的后面章節(jié)將展示Failover機(jī)制的實(shí)際效果）。
▼ ⑤ 多地部署接入點(diǎn)：
在全國(guó)多地部署代理長(zhǎng)連接入點(diǎn)。客戶端與接入點(diǎn)建立長(zhǎng)連通道時(shí)，可以選擇最快的服務(wù)器就近接入，從而大大降低通道連接速度并提升通信質(zhì)量。 我們?cè)诮鼉赡甑木W(wǎng)絡(luò)優(yōu)化實(shí)踐中，將客戶端的網(wǎng)絡(luò)通道服務(wù)整理成了一個(gè)獨(dú)立的SDK，SDK包含了自建的長(zhǎng)連通信服務(wù)。
完整的網(wǎng)絡(luò)通道拓?fù)鋱D如下所示：
圖中網(wǎng)絡(luò)通道SDK包含了三大通信通道：
1）CIP通道：
CIP通道就是上文中提到的自建代理長(zhǎng)連通道。CIP是China Internet Plus的縮寫，為美團(tuán)點(diǎn)評(píng)集團(tuán)的注冊(cè)英文名稱。App中絕大部分的請(qǐng)求通過(guò)CIP通道中的TCP子通道與長(zhǎng)連服務(wù)器（CIP Connection Server）通信，長(zhǎng)連服務(wù)器將收到的請(qǐng)求代理轉(zhuǎn)發(fā)到業(yè)務(wù)服務(wù)器（API Server）。由于TCP子通道在一些極端情況下可能會(huì)無(wú)法工作，我們?cè)贑IP通道中額外部署了UDP子通道和HTTP子通道，其中HTTP子通道通過(guò)公網(wǎng)繞過(guò)長(zhǎng)連服務(wù)器與業(yè)務(wù)服務(wù)器進(jìn)行直接請(qǐng)求。CIP通道的平均端到端成功率目前已達(dá)99.7%，耗時(shí)平均在350毫秒左右；
2）WNS通道：
出于災(zāi)備的需要，騰訊的WNS目前仍被包含在網(wǎng)絡(luò)通道SDK中。當(dāng)極端情況發(fā)生，CIP通道不可用時(shí)，WNS通道還可以作為備用的長(zhǎng)連替代方案；
3）HTTP通道：
此處的HTTP通道是在公網(wǎng)直接請(qǐng)求API Server的網(wǎng)絡(luò)通道。出于長(zhǎng)連通道重要性的考慮，上傳和下載大數(shù)據(jù)包的請(qǐng)求如果放在長(zhǎng)連上進(jìn)行都有可能導(dǎo)致長(zhǎng)連通道的擁堵，因此我們將CDN訪問(wèn)、文件上傳和頻繁的日志上報(bào)等放在公網(wǎng)利用HTTP短連進(jìn)行請(qǐng)求，同時(shí)也減輕代理長(zhǎng)連服務(wù)器的負(fù)擔(dān)。
推送方案：在網(wǎng)絡(luò)通道拓?fù)鋱D的右上角，有個(gè)Push Server。它是考慮到TCP通道的雙工特性，為網(wǎng)絡(luò)通道SDK提供推送的能力。利用通知推送，可以在服務(wù)器數(shù)據(jù)發(fā)生變化時(shí)及時(shí)通知客戶端。推送方案可以替換掉代碼中常見的耗時(shí)低效的輪詢方案。
9、實(shí)際案例展示
下圖展示了某開機(jī)接口在接入長(zhǎng)連后的端到端成功率對(duì)比：
上圖中黑色曲線是某開機(jī)接口在短連通道下的成功率曲線。成功率平均只有81%，抖動(dòng)的特別劇烈，說(shuō)明網(wǎng)絡(luò)服務(wù)穩(wěn)定性不夠。藍(lán)色曲線是同一接口在長(zhǎng)連通道下的成功率曲線。成功率平均已達(dá)到99%，抖動(dòng)大幅減小。
成功延時(shí)對(duì)比圖：
上圖中展示了同樣情況下的成功延時(shí)曲線。藍(lán)色線為長(zhǎng)連延時(shí)曲線，黑色線為短連延時(shí)曲線。
接下來(lái)我們看Failover的效果展示圖。下圖展示了2015年的一次長(zhǎng)連服務(wù)器故障。
當(dāng)時(shí)Android客戶端采用了Failover方案，在長(zhǎng)連不可用時(shí)Failover到短鏈或者UDP通道上。與未采用Failover方案的iOS客戶端相比，F(xiàn)ailover機(jī)制在維持網(wǎng)絡(luò)整體可用性方面體現(xiàn)出了非常大的優(yōu)勢(shì)。
10、網(wǎng)絡(luò)配置系統(tǒng)展示
網(wǎng)絡(luò)通道SDK包含了CIP | WNS | HTTP 三大通道，不同的通道具有各自的優(yōu)缺點(diǎn)，控制各請(qǐng)求選擇合適的網(wǎng)絡(luò)通道成了迫在眉睫的重要課題。
為此我們開發(fā)了網(wǎng)絡(luò)配置系統(tǒng)，通過(guò)下發(fā)指令，調(diào)整App中網(wǎng)絡(luò)通道SDK中的通道選擇策略，可以控制不同的API請(qǐng)求動(dòng)態(tài)切換網(wǎng)絡(luò)通道。
下圖是某接口的線上通道切換示意圖：
上圖中展示了某接口切換WNS通道的過(guò)程。圖中的黑色線代表短連通道下的請(qǐng)求數(shù)量曲線，藍(lán)色線代表WNS通道下的請(qǐng)求數(shù)量曲線。通過(guò)線上控制系統(tǒng)下發(fā)了通道切換指令后，絕大部分的短連請(qǐng)求在5分鐘之內(nèi)被切換成了WNS通道請(qǐng)求。
11、在優(yōu)化開發(fā)過(guò)程中，我們發(fā)現(xiàn)的規(guī)律
在移動(dòng)端網(wǎng)絡(luò)優(yōu)化開發(fā)過(guò)程中，我們發(fā)現(xiàn)以下這些規(guī)律。
▼ 1）長(zhǎng)連通道建立越早，成功率越高：
長(zhǎng)連通道越早建立，越多的請(qǐng)求能夠在長(zhǎng)連通道上進(jìn)行。特別是當(dāng)App剛打開時(shí)，數(shù)量眾多的請(qǐng)求同時(shí)需要發(fā)出。
面對(duì)這種情況，我們采取的策略是首先建立長(zhǎng)連通道，將眾多請(qǐng)求放入等待發(fā)送隊(duì)列中，待長(zhǎng)連通道建立完畢后再將等待隊(duì)列中的請(qǐng)求放在長(zhǎng)連通道上依次送出。
采用這種策略后，我們發(fā)現(xiàn)啟動(dòng)時(shí)的接口成功率平均提升了1.4%，延時(shí)平均降低了160毫秒。
▼ 2）TCP數(shù)據(jù)包越大，傳輸時(shí)間越長(zhǎng)：
如果長(zhǎng)連通道未采用類似HTTP/2中的數(shù)據(jù)切片技術(shù)，大的數(shù)據(jù)包非常容易導(dǎo)致長(zhǎng)連通道的堵塞。
▼ 3）底層SDK上線新功能一定要有線上降級(jí)手段：
當(dāng)新功能上線了發(fā)生故障時(shí)，可以通過(guò)開關(guān)或參數(shù)控制，或是采用ABTest方式等進(jìn)行降級(jí)，防止故障擴(kuò)大化。
▼ 4）iOS和Android系統(tǒng)網(wǎng)絡(luò)庫(kù)存在很多默認(rèn)行：
例如系統(tǒng)網(wǎng)絡(luò)庫(kù)會(huì)在內(nèi)部處理網(wǎng)絡(luò)重定向，再比如請(qǐng)求頭中如果沒(méi)有填寫Accept-Encoding或Content-Type等字段，系統(tǒng)網(wǎng)絡(luò)庫(kù)會(huì)自動(dòng)填寫默認(rèn)值。
▼ 5）一個(gè)容易忽視的地方：
HTTP的請(qǐng)求頭鍵值對(duì)中的的鍵是允許相同和重復(fù)的。例如下圖所示的”Set-Cookie”字段就是包含了多組的相同的鍵名稱。與之類似的還有”Cookie”字段。在長(zhǎng)連通信中，如果對(duì)header中的鍵值對(duì)用不加處理的字典方式保存和傳輸，就會(huì)造成數(shù)據(jù)的丟失。
12、小小的建議
對(duì)于正在成長(zhǎng)中的創(chuàng)業(yè)公司，我們有如下改善網(wǎng)絡(luò)狀況的建議。
1）收攏網(wǎng)絡(luò)底層：隨著公司的成長(zhǎng)，開發(fā)團(tuán)隊(duì)越來(lái)越多，不可避免的將會(huì)引入越來(lái)越多的網(wǎng)絡(luò)庫(kù)。網(wǎng)絡(luò)庫(kù)多了之后，再對(duì)網(wǎng)絡(luò)請(qǐng)求進(jìn)行集中管理就非常困難了。我們的建議是在網(wǎng)絡(luò)庫(kù)與業(yè)務(wù)代碼之間架設(shè)自己的網(wǎng)絡(luò)層，業(yè)務(wù)的網(wǎng)絡(luò)請(qǐng)求全部經(jīng)過(guò)網(wǎng)絡(luò)層代碼進(jìn)行請(qǐng)求。這樣未來(lái)進(jìn)行底層網(wǎng)絡(luò)庫(kù)的更換，或者網(wǎng)絡(luò)通道的優(yōu)化將變得容易很多。
2）使用網(wǎng)絡(luò)監(jiān)控：引入網(wǎng)絡(luò)監(jiān)控機(jī)制，發(fā)現(xiàn)網(wǎng)絡(luò)問(wèn)題。這里推薦我公司開發(fā)的開源的Cat監(jiān)控系統(tǒng)。Cat開源地址為：http://github.com/dianping/cat 。
3）嘗試進(jìn)行短連優(yōu)化：前文中提到的域名合并和IP直連方案都是簡(jiǎn)單有效的手段。
4）可以嘗試HTTP/2或騰訊WNS長(zhǎng)連服務(wù)（注：騰訊云的WNS已停止服務(wù)）。
附錄：更多網(wǎng)絡(luò)編程基礎(chǔ)資料
[1.1] 移動(dòng)端弱網(wǎng)相關(guān)資料：
《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》
《聊聊iOS中網(wǎng)絡(luò)編程長(zhǎng)連接的那些事》
《移動(dòng)端IM開發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》
《移動(dòng)端IM開發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
《全面了解移動(dòng)端DNS域名劫持等雜癥：技術(shù)原理、問(wèn)題根源、解決方案等》
《美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半》
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(一)：DNS優(yōu)化篇》
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(二)：網(wǎng)絡(luò)連接優(yōu)化篇》
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(三)：移動(dòng)端弱網(wǎng)優(yōu)化篇》
《愛(ài)奇藝移動(dòng)端網(wǎng)絡(luò)優(yōu)化實(shí)踐分享：網(wǎng)絡(luò)請(qǐng)求成功率優(yōu)化篇》
《美團(tuán)點(diǎn)評(píng)的移動(dòng)端網(wǎng)絡(luò)優(yōu)化實(shí)踐：大幅提升連接成功率、速度等》
《5G時(shí)代已經(jīng)到來(lái)，TCP/IP老矣，尚能飯否？》
《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫(kù)，即將開源》
《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺(tái)組件庫(kù)Mars已正式開源》
《談?wù)勔苿?dòng)端 IM 開發(fā)中登錄請(qǐng)求的優(yōu)化》
《騰訊原創(chuàng)分享(一)：如何大幅提升移動(dòng)網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》
《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（下篇）》
《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（上篇）》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十一)：為什么WiFi信號(hào)差？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十二)：上網(wǎng)卡頓？網(wǎng)絡(luò)掉線？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十三)：為什么手機(jī)信號(hào)差？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十四)：高鐵上無(wú)線上網(wǎng)有多難？一文即懂！》
>> 更多同類文章 ……
[1.2] 網(wǎng)絡(luò)編程基礎(chǔ)資料：
《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報(bào)協(xié)議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時(shí)與重傳》
《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機(jī)慎點(diǎn)）》
《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》
《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動(dòng)窗口、擁塞處理》
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過(guò)程詳解》
《理論聯(lián)系實(shí)際：Wireshark抓包分析TCP 3次握手、4次揮手過(guò)程》
《計(jì)算機(jī)網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》
《UDP中一個(gè)包的大小最大能多大？》
《P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡(jiǎn)介》
《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解(基本原理篇)》
《P2P技術(shù)詳解(三)：P2P中的NAT穿越(打洞)方案詳解(進(jìn)階分析篇)》
《P2P技術(shù)詳解(四)：P2P技術(shù)之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術(shù)中的NAT穿透原理》
《高性能網(wǎng)絡(luò)編程(一)：?jiǎn)闻_(tái)服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》
《高性能網(wǎng)絡(luò)編程(二)：上一個(gè)10年，著名的C10K并發(fā)連接問(wèn)題》
《高性能網(wǎng)絡(luò)編程(三)：下一個(gè)10年，是時(shí)候考慮C10M并發(fā)問(wèn)題了》
《高性能網(wǎng)絡(luò)編程(四)：從C10K到C10M高性能網(wǎng)絡(luò)應(yīng)用的理論探索》
《高性能網(wǎng)絡(luò)編程(五)：一文讀懂高性能網(wǎng)絡(luò)編程中的I/O模型》
《高性能網(wǎng)絡(luò)編程(六)：一文讀懂高性能網(wǎng)絡(luò)編程中的線程模型》
《Java的BIO和NIO很難懂？用代碼實(shí)踐給你看，再不懂我轉(zhuǎn)行！》
《不為人知的網(wǎng)絡(luò)編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》
《不為人知的網(wǎng)絡(luò)編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》
《不為人知的網(wǎng)絡(luò)編程(三)：關(guān)閉TCP連接時(shí)為什么會(huì)TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》
《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負(fù)載均衡》
《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡(luò)編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網(wǎng)絡(luò)編程(八)：從數(shù)據(jù)傳輸層深度解密HTTP》
《不為人知的網(wǎng)絡(luò)編程(九)：理論聯(lián)系實(shí)際，全方位深入理解DNS》
《網(wǎng)絡(luò)編程懶人入門(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》
《網(wǎng)絡(luò)編程懶人入門(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》
《網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》
《網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異》
《網(wǎng)絡(luò)編程懶人入門(五)：快速理解為什么說(shuō)UDP有時(shí)比TCP更有優(yōu)勢(shì)》
《網(wǎng)絡(luò)編程懶人入門(六)：史上最通俗的集線器、交換機(jī)、路由器功能原理入門》
《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》
《網(wǎng)絡(luò)編程懶人入門(八)：手把手教你寫基于TCP的Socket長(zhǎng)連接》
《網(wǎng)絡(luò)編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《網(wǎng)絡(luò)編程懶人入門(十)：一泡尿的時(shí)間，快速讀懂QUIC協(xié)議》
《網(wǎng)絡(luò)編程懶人入門(十一)：一文讀懂什么是IPv6》
《技術(shù)掃盲：新一代基于UDP的低延時(shí)網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》
《聊聊iOS中網(wǎng)絡(luò)編程長(zhǎng)連接的那些事》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計(jì)思路》
《腦殘式網(wǎng)絡(luò)編程入門(一)：跟著動(dòng)畫來(lái)學(xué)TCP三次握手和四次揮手》
《腦殘式網(wǎng)絡(luò)編程入門(二)：我們?cè)谧x寫Socket時(shí)，究竟在讀寫什么？》
《腦殘式網(wǎng)絡(luò)編程入門(三)：HTTP協(xié)議必知必會(huì)的一些知識(shí)》
《腦殘式網(wǎng)絡(luò)編程入門(四)：快速理解HTTP/2的服務(wù)器推送(Server Push)》
《腦殘式網(wǎng)絡(luò)編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網(wǎng)絡(luò)編程入門(六)：什么是公網(wǎng)IP和內(nèi)網(wǎng)IP？NAT轉(zhuǎn)換又是什么鬼？》
《腦殘式網(wǎng)絡(luò)編程入門(七)：面視必備，史上最通俗計(jì)算機(jī)網(wǎng)絡(luò)分層詳解》
《腦殘式網(wǎng)絡(luò)編程入門(八)：你真的了解127.0.0.1和0.0.0.0的區(qū)別？》
《以網(wǎng)游服務(wù)端的網(wǎng)絡(luò)接入層設(shè)計(jì)為例，理解實(shí)時(shí)通信的技術(shù)挑戰(zhàn)》
《邁向高階：優(yōu)秀Android程序員必知必會(huì)的網(wǎng)絡(luò)基礎(chǔ)》
《全面了解移動(dòng)端DNS域名劫持等雜癥：技術(shù)原理、問(wèn)題根源、解決方案等》
《美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半》
《Android程序員必知必會(huì)的網(wǎng)絡(luò)通信傳輸層協(xié)議——UDP和TCP》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(一)：通信交換技術(shù)的百年發(fā)展史(上)》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(二)：通信交換技術(shù)的百年發(fā)展史(下)》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(三)：國(guó)人通信方式的百年變遷》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(四)：手機(jī)的演進(jìn)，史上最全移動(dòng)終端發(fā)展史》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(五)：1G到5G，30年移動(dòng)通信技術(shù)演進(jìn)史》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(六)：移動(dòng)終端的接頭人——“基站”技術(shù)》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(七)：移動(dòng)終端的千里馬——“電磁波”》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(八)：零基礎(chǔ)，史上最強(qiáng)“天線”原理掃盲》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(九)：無(wú)線通信網(wǎng)絡(luò)的中樞——“核心網(wǎng)”》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十)：零基礎(chǔ)，史上最強(qiáng)5G技術(shù)掃盲》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十一)：為什么WiFi信號(hào)差？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十二)：上網(wǎng)卡頓？網(wǎng)絡(luò)掉線？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十三)：為什么手機(jī)信號(hào)差？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十四)：高鐵上無(wú)線上網(wǎng)有多難？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十五)：理解定位技術(shù)，一篇就夠》
《技術(shù)大牛陳碩的分享：由淺入深，網(wǎng)絡(luò)編程學(xué)習(xí)經(jīng)驗(yàn)干貨總結(jié)》
《可能會(huì)搞砸你的面試：你知道一個(gè)TCP連接上能發(fā)起多少個(gè)HTTP請(qǐng)求嗎？》
《知乎技術(shù)分享：知乎千萬(wàn)級(jí)并發(fā)的高性能長(zhǎng)連接網(wǎng)關(guān)技術(shù)實(shí)踐》
《5G時(shí)代已經(jīng)到來(lái)，TCP/IP老矣，尚能飯否？》
>> 更多同類文章 ……
（本文已同步發(fā)布于：http://www.52im.net/thread-3015-1-1.html）