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