一、背景

如何度量和模擬“弱網(wǎng)絡(luò)”對(duì)移動(dòng)APP的開發(fā)有著重大的意義叮贩，比如：節(jié)約測(cè)試成本颅湘、易于問題重現(xiàn)话侧、加快產(chǎn)品上線等。

一般的方法是使用“丟包率”和“網(wǎng)絡(luò)延時(shí)”來定義和衡量“弱網(wǎng)絡(luò)”栅炒。

二掂摔、手機(jī)接入服務(wù)器的流程

要講這個(gè)問題，首先要來了解下手機(jī)接入服務(wù)器的流程赢赊。

• 首先乙漓，手機(jī)要通過無線網(wǎng)絡(luò)協(xié)議，從基站獲得無線鏈路分配释移，才能跟網(wǎng)絡(luò)進(jìn)行通訊叭披。
• 無線網(wǎng)絡(luò)基站、基站控制器這方面玩讳，會(huì)給手機(jī)進(jìn)行信號(hào)的分配涩蜘，已完成手機(jī)連接和交互。
• 獲得無線鏈路后熏纯，會(huì)進(jìn)行網(wǎng)絡(luò)附著同诫、加密、鑒權(quán)樟澜，核心網(wǎng)絡(luò)會(huì)檢查你是不是可以連接在這個(gè)網(wǎng)絡(luò)上误窖，是否開通套餐叮盘，是不是漫游等。核心網(wǎng)絡(luò)有SGSN和GGSN霹俺，在這一步完成無線網(wǎng)絡(luò)協(xié)議和有線以太網(wǎng)的協(xié)議轉(zhuǎn)換柔吼。
• 再下一步，核心網(wǎng)絡(luò)會(huì)給你進(jìn)行APN選擇丙唧、IP分配愈魏、啟動(dòng)計(jì)費(fèi)。
• 再往下面想际，才是傳統(tǒng)網(wǎng)絡(luò)的步驟：DNS查詢培漏、響應(yīng)，建立TCP鏈接沼琉，HTTP GET北苟，RTTP RESPONSE 200 OK，HTTP RESPONSE DATA打瘪，LAST HTTP RESPONSE DATA，開始UI展現(xiàn)傻昙。

這是手機(jī)通過無線網(wǎng)絡(luò)接入服務(wù)器的全過程闺骚。整個(gè)過程當(dāng)中有幾個(gè)困擾開發(fā)者的問題：

無線網(wǎng)絡(luò)是怎么給手機(jī)分配到無線鏈路的?

核心網(wǎng)絡(luò)有接入點(diǎn)(APN)，這里的CMNET和CMWAP有什么區(qū)別妆档，僅僅是協(xié)議不同嗎嗎?數(shù)據(jù)轉(zhuǎn)發(fā)又有什么區(qū)別?一個(gè)數(shù)據(jù)包在不同網(wǎng)絡(luò)上傳輸有不同嗎?

用戶怎么最快的找到正確的服務(wù)器?內(nèi)容怎么快速有效的加載僻爽，在第一時(shí)間顯示出來?

這幾個(gè)問題的重點(diǎn)在于其中的幾個(gè)連接點(diǎn)：

• 無線鏈路分配。這是一個(gè)物理實(shí)連接贾惦。
• IP層鏈接胸梆。這是一個(gè)邏輯虛連接。
• TCP層鏈接须板。這是一個(gè)邏輯虛連接碰镜。
• HTTP層鏈接。這是一個(gè)邏輯虛連接习瑰。
• 用戶在線绪颖。這是一個(gè)邏輯虛連接。

3.2 一秒鐘法則

根據(jù)以上情況甜奄，就形成無線網(wǎng)絡(luò)的一大特點(diǎn)：秒級(jí)狀態(tài)管理柠横，秒級(jí)狀態(tài)轉(zhuǎn)換。這兩個(gè)操作都在幾百ms到幾秒之間進(jìn)行课兄，對(duì)于維持連接來說時(shí)間太短牍氛，對(duì)于從無連接到有連接的轉(zhuǎn)換來說時(shí)間又太長(zhǎng)。

相比之下烟阐，有線網(wǎng)絡(luò)的狀態(tài)管理如ip分配搬俊、tcp連接釋放踱稍，都是分鐘級(jí)，而狀態(tài)轉(zhuǎn)換則是毫秒級(jí)悠抹。

這些通訊機(jī)制珠月，同時(shí)加上無線網(wǎng)絡(luò)的高延遲、高丟包楔敌。如何保證移動(dòng)互聯(lián)網(wǎng)的產(chǎn)品提供穩(wěn)定的啤挎、可預(yù)期的服務(wù)質(zhì)量，成為非常大的挑戰(zhàn)：

2G網(wǎng)絡(luò)上無線部分?jǐn)?shù)據(jù)傳輸?shù)难舆t有幾百ms卵凑，4G網(wǎng)絡(luò)上無線部分傳輸延遲減少到幾十ms庆聘，核心網(wǎng)狀態(tài)轉(zhuǎn)換、協(xié)議轉(zhuǎn)換30~100ms勺卢，IP骨干網(wǎng)上的延遲又跟物理距離以及運(yùn)營(yíng)商互聯(lián)互通質(zhì)量有關(guān)伙判，跨運(yùn)營(yíng)商50-400ms，同運(yùn)營(yíng)商5-80ms黑忱，這個(gè)還要取決于網(wǎng)絡(luò)擁塞的情況宴抚。

無線網(wǎng)絡(luò)誤碼率比有線高兩個(gè)數(shù)量級(jí)，在不同時(shí)間段的波動(dòng)也非常巨大甫煞。

怎么基于移動(dòng)網(wǎng)絡(luò)的特性去優(yōu)化服務(wù)?

這就是我們總結(jié)的一秒鐘法則：在一秒內(nèi)要完成的規(guī)定動(dòng)作菇曲。

1. 2g網(wǎng)絡(luò)：1秒內(nèi)完成dns查詢、和后臺(tái)服務(wù)器建立連接
2. 3g網(wǎng)絡(luò)：1秒內(nèi)完成首字顯示(首字時(shí)間)
3. wifi網(wǎng)絡(luò)：1秒內(nèi)完成首屏顯示(首屏?xí)r間)
4. 這些指標(biāo)需要在終端度量抚吠，必須跟用戶體驗(yàn)相關(guān)：首字時(shí)間常潮、首屏?xí)r間都必須是用戶可以直觀感受到的。

四楷力、優(yōu)化思路

4.1 服務(wù)保證原則

從以上分析可知喊式，如何保證移動(dòng)互聯(lián)網(wǎng)的產(chǎn)品提供穩(wěn)定的、可預(yù)期的服務(wù)質(zhì)量萧朝，具有非常大的挑戰(zhàn)岔留。以下幾點(diǎn)原則可能會(huì)有幫助：

1. 接口設(shè)計(jì)優(yōu)化，接口的優(yōu)化理論上不屬于APP弱網(wǎng)絡(luò)的優(yōu)化剪勿，但是這個(gè)的API性能的問題贸诚，確實(shí)在網(wǎng)絡(luò)條件不好的情況下才暴露無遺。大家都在談?wù)摲?wù)器的好壞厕吉，設(shè)備的性能高低酱固，其實(shí)，對(duì)于一個(gè)良好的Server來說头朱，絕大部分拖延請(qǐng)求速度的地方都是在IO上运悲。包括，磁盤讀寫的IO项钮，SQL查詢的IO等等班眯。常用的優(yōu)化點(diǎn)：慢查詢監(jiān)控 希停、多次查詢優(yōu)化、常用接口cache等署隘。
2. 圖片相關(guān)策略宠能。
3. 使用更快的圖片格式，嚴(yán)格說也不算弱網(wǎng)下的優(yōu)化磁餐，但一個(gè)更快的圖片格式真的很重要!這里建議采用WebP格式违崇。(WebP格式，谷歌(google)開發(fā)的一種旨在加快圖片加載速度的圖片格式诊霹。圖片壓縮體積大約只有JPEG的2/3羞延，并能節(jié)省大量的服務(wù)器帶寬資源和數(shù)據(jù)空間。但WebP是一種有損壓縮脾还。相較編碼JPEG文件伴箩，編碼同樣質(zhì)量的WebP文件需要占用更多的計(jì)算資源。)
4. 不同網(wǎng)絡(luò)的不同圖片下發(fā)鄙漏。如(對(duì)于原圖是600X480的圖片)：2/3G使用低清晰度圖片——>下發(fā)300X240嗤谚，精度為80的圖片、4G普通清晰度圖片——>下發(fā)600X480泥张，精度為80的圖片呵恢、WiFi高清晰度圖片(最好根據(jù)網(wǎng)速來判斷，wifi也有慢的)——>下發(fā)600X480媚创，精度為100的圖片。
5. 斷線重連彤恶。這可能是最重的一個(gè)特性钞钙，因?yàn)樵跓o線網(wǎng)絡(luò)中有太多的原因?qū)е聰?shù)據(jù)連接中斷了。這里可以使用CDN声离。(CDN 是構(gòu)建在數(shù)據(jù)網(wǎng)絡(luò)上的一種分布式的內(nèi)容分發(fā)網(wǎng)芒炼。 CDN 的作用是采用流媒體服務(wù)器集群技術(shù)，克服單機(jī)系統(tǒng)輸出帶寬及并發(fā)能力不足的缺點(diǎn)术徊，可極大提升系統(tǒng)支持的并發(fā)流數(shù)目本刽，減少或避免單點(diǎn)失效帶來的不良影響。)
6. 由于創(chuàng)建連接是一個(gè)非常昂貴的操作赠涮，所以應(yīng)盡量減少數(shù)據(jù)連接的創(chuàng)建次數(shù)子寓，且在一次請(qǐng)求中應(yīng)盡量以批量的方式執(zhí)行任務(wù)。如果多次發(fā)送小數(shù)據(jù)包笋除，應(yīng)該盡量保證在2秒以內(nèi)發(fā)送出去斜友。在短時(shí)間內(nèi)訪問不同服務(wù)器時(shí)，盡可能地復(fù)用無線連接垃它。
7. 優(yōu)化DNS查詢鲜屏。應(yīng)盡量減少DNS查詢烹看、避免域名劫持、DNS污染洛史，同時(shí)把用戶調(diào)度到“最優(yōu)接入點(diǎn)”惯殊。
8. 減小數(shù)據(jù)包大小和優(yōu)化包量。通過壓縮也殖、精簡(jiǎn)包頭土思、消息合并等方式，來減小數(shù)據(jù)包大小和包量毕源。
9. 控制數(shù)據(jù)包大小不超過1500浪漠，避免分片。包括邏輯鏈路控制(Logic Link Control)分片霎褐、GGSN分片址愿，以及IP分片。其中冻璃，當(dāng)數(shù)據(jù)包大小超出GGSN所允許的最大大小時(shí)响谓，GGSN的處理方式有以下三種：分片、丟棄和拒絕省艳。
10. 優(yōu)化TCP socket參數(shù)娘纷，包括：是否關(guān)閉快速回收、初始RTO跋炕、初始擁塞窗口赖晶、socket緩存大小、Delay-ACK辐烂、Selective-ACK遏插、TCP_CORK、擁塞算法(westwood/TLP/cubic)等纠修。做這件事情的意義在于：由于2G/3G/4G/WIFI/公司內(nèi)網(wǎng)等接入網(wǎng)絡(luò)的QoS差異很大胳嘲，所以不同網(wǎng)絡(luò)下為了取得較好的服務(wù)質(zhì)量，上述參數(shù)的取值差異可能會(huì)很大扣草。
11. 優(yōu)化ACK包了牛。在弱網(wǎng)絡(luò)的情況下，TCP協(xié)議中的ACK包是非常昂貴的辰妙，延時(shí)甚至能夠達(dá)到秒級(jí)別鹰祸，而TCP協(xié)議的擁塞控制、快速重傳上岗、快速恢復(fù)等特性都非常依賴接收端反饋的ACK包福荸。可想而知肴掷，如果發(fā)送端接收到的ACK包延時(shí)太長(zhǎng)敬锐，會(huì)嚴(yán)重影響TCP協(xié)議的效率背传。但是如果發(fā)送ACK太多又會(huì)占用寶貴過多的無線資源。在移動(dòng)網(wǎng)絡(luò)下通信台夺，“在可靠的連接上径玖，如何在減少ACK包的情況下，降低數(shù)據(jù)包的延時(shí)”是研究的熱點(diǎn)颤介∈嵝牵基本的思想：平衡冗余包和ACK包個(gè)數(shù)，達(dá)到降低延時(shí)滚朵，提高吞吐量的目的冤灾。例如SGSN和GGSN之間的通信實(shí)現(xiàn)：二者之間通過UDP協(xié)議通信，發(fā)送者在無新的數(shù)據(jù)包的情況下辕近，每隔一定的時(shí)間重試已發(fā)送的包韵吨，達(dá)到最大重試次數(shù)后，則丟棄該包移宅。
12. TCP的擁塞控制算法是以“丟包意味著網(wǎng)絡(luò)出現(xiàn)擁塞”為假設(shè)設(shè)計(jì)的归粉，很明顯這個(gè)假設(shè)在無線網(wǎng)絡(luò)環(huán)境下是不合適的。但是在無線網(wǎng)絡(luò)環(huán)境下漏峰，在設(shè)計(jì)可靠UDP協(xié)議時(shí)是否能夠完全丟棄擁塞控制呢?這里有其它的文章中提出了幾種在無線網(wǎng)絡(luò)環(huán)境下的TCP友好的擁塞控制算法循狰，有興趣可以自行查閱砾嫉。
13. 靈活使用長(zhǎng)連接/短連接聊训，支持不同協(xié)議(TCP/UDP, http礁竞、二進(jìn)制協(xié)議等)，支持不同端口等靖苇。
14. 讓用戶覺得快滴劲。到這里已經(jīng)不能算是技術(shù)層面的方法了，屬于一種心理層面的博弈顾复，一種改善用戶體驗(yàn)的方式。比如：

• 不從0開始的進(jìn)度條鲁捏。不管網(wǎng)頁(yè)的加載進(jìn)度如何芯砸，不管網(wǎng)絡(luò)條件如何，加載進(jìn)度始終是從50%起给梅，并且停留在大約98%進(jìn)度左右的地方假丧。
• 先顯示文字在加載圖片。同樣是在Webview之中动羽，圖片或者多媒體的加載速度肯定是遠(yuǎn)遠(yuǎn)慢過文字的加載速度的包帚。由于不同的webview顯示和渲染效果不同，我們可以先讓webview先顯示文字运吓，在顯示圖片渴邦。給用戶一種可以先預(yù)覽整個(gè)網(wǎng)頁(yè)概況的感覺疯趟。

4.2 接入調(diào)度優(yōu)化

接入調(diào)度優(yōu)化首先要考慮的是減少DNS的影響。移動(dòng)網(wǎng)絡(luò)的DNS有如下特點(diǎn)：

• 骨干網(wǎng)無法識(shí)別移動(dòng)用戶在哪個(gè)城市谋梭，東西南北各個(gè)地方的調(diào)度沒有充分調(diào)用信峻。目前有一部分全國(guó)范圍的DNS承載了超過40%的全網(wǎng)用戶
• 很多山寨機(jī)的終端local dns設(shè)置是錯(cuò)誤的
• 另外還有一些有線網(wǎng)絡(luò)也一樣會(huì)遇到的問題，如終端DNS解析濫用瓮床、域名劫持盹舞、DNS污染、老化隘庄、脆弱等踢步。不過對(duì)于這些問題，桌面的自愈性會(huì)比較好丑掺，而在手機(jī)上則比較難以解決获印。

對(duì)于DNS的問題，有兩條主要的解決思路：

• 減少DNS的請(qǐng)求吼鱼、查詢蓬豁、更新，也就是做DNS緩存
• 在終端配置server list菇肃，直接訪問IP地粪，不用DNS

但僅僅這么做還不夠，因?yàn)橛脩艨赡軄碜試?guó)內(nèi)外不同的運(yùn)營(yíng)商琐谤，還需要進(jìn)一步優(yōu)化調(diào)度策略：

• DNS緩存需要多建立接入點(diǎn)蟆技，用不同域名區(qū)分
• IP列表需要更新以適應(yīng)不同網(wǎng)絡(luò)情況，要做到主動(dòng)調(diào)度斗忌。好比最早我們只服務(wù)好移動(dòng)用戶就行质礼，保證移動(dòng)用戶的接入質(zhì)量?jī)?yōu)先，因?yàn)榻^大多數(shù)用戶集中在移動(dòng);現(xiàn)在國(guó)內(nèi)有三個(gè)運(yùn)營(yíng)商织阳，用戶分布的比例在慢慢接近眶蕉，要區(qū)分清楚;智能手機(jī)會(huì)用wifi，接入的是電信唧躲、聯(lián)通還是哪個(gè)運(yùn)營(yíng)商造挽，不知道，所以你不可能預(yù)先設(shè)置場(chǎng)景再if then弄痹，必須通過后臺(tái)調(diào)度能力來解決饭入。

再進(jìn)一步優(yōu)化，就產(chǎn)生一種融合的方式：

• 先做域名解析肛真，客戶端直接連接解析的IP谐丢，可以用http協(xié)議，也可以用tcp socket
• 多端口、多協(xié)議組合：不同協(xié)議有不同的限制乾忱，有些只能http讥珍，有些只能tcp socket，各種環(huán)境都要適應(yīng)饭耳，客戶端不能只支持一種協(xié)議
• 終端測(cè)速：接入點(diǎn)越來越多串述，接入哪個(gè)合適，要選擇寞肖，可以通過終端測(cè)速來選擇最快的纲酗。你當(dāng)然可以每一次新建連接都做測(cè)速，但是這樣建立連接時(shí)間可能會(huì)很長(zhǎng);我們可以給用戶先建立連接后新蟆，在后臺(tái)根據(jù)長(zhǎng)期速度監(jiān)控觅赊、當(dāng)前測(cè)速的結(jié)果，來做動(dòng)態(tài)調(diào)度琼稻。也就是說吮螺，第一次連接可能不是最優(yōu)，連接建立后動(dòng)態(tài)測(cè)速帕翻，再轉(zhuǎn)移到最快接入點(diǎn)鸠补。更進(jìn)一步就是建立網(wǎng)絡(luò)profile，終端學(xué)習(xí)的思路嘀掸。

關(guān)于測(cè)速采樣的粒度紫岩，移動(dòng)互聯(lián)網(wǎng)取IP段是沒用的，比較好的粒度是到網(wǎng)元級(jí)別睬塌，比如廣東有20多個(gè)wap網(wǎng)關(guān)泉蝌，每一個(gè)網(wǎng)關(guān)的情況都不一樣，這就是一個(gè)比較合適的粒度揩晴。

最后強(qiáng)調(diào)一個(gè)所有的接入調(diào)度原則：不要把調(diào)度邏輯寫死在客戶端勋陪，一定要由后臺(tái)完成。

4.3 協(xié)議優(yōu)化

協(xié)議參數(shù)優(yōu)化這塊就簡(jiǎn)單列一下硫兰，是長(zhǎng)期運(yùn)營(yíng)過程中總結(jié)的一些經(jīng)驗(yàn)诅愚，在啟動(dòng)移動(dòng)互聯(lián)網(wǎng)服務(wù)時(shí)作為運(yùn)營(yíng)的規(guī)范，可以少走很多彎路：

1. 關(guān)閉TCP快速回收
2. Init RTO不低于3秒
3. 初始擁塞控制窗口不小于10劫映。因?yàn)榇蟛糠猪?yè)面在10kB以下呻粹，很多請(qǐng)求在慢啟動(dòng)階段已經(jīng)結(jié)束，改為10可以降低小頁(yè)面資源傳輸時(shí)延苏研。內(nèi)容越大，這個(gè)選項(xiàng)的效果就比較不明顯腮郊。
4. Socket buffer > 64k
5. TCP滑動(dòng)窗口可變
6. 控制發(fā)包大小在1400字節(jié)以下摹蘑，避免分片

協(xié)議優(yōu)化的原則總結(jié)下來是這么幾條：

1. 連接重用
2. 并發(fā)連接控制
3. 超時(shí)控制
4. 包頭精簡(jiǎn)
5. 內(nèi)容壓縮
6. 選擇更高效率的協(xié)議。無論是TCP轧飞、HTTP衅鹿、UDP撒踪、長(zhǎng)連接、GZIP大渤、SPDY制妄、WUP還是WebP，每一種協(xié)議泵三、方案都有其道理耕捞，沒有最優(yōu)，只有是否適合你的產(chǎn)品和服務(wù)特點(diǎn)烫幕，需要大家在運(yùn)營(yíng)過程驗(yàn)證和取舍俺抽。

4.4 WAP接入點(diǎn)優(yōu)化

關(guān)于WAP接入點(diǎn)優(yōu)化，可能有些人會(huì)說较曼，我們的App是高端大氣上檔次的應(yīng)用磷斧，是不是就不用做WAP優(yōu)化?實(shí)際上我們的統(tǒng)計(jì)顯示，目前有5%-20%的用戶選擇的接入點(diǎn)是*WAP(CMWAP捷犹、3GWAP弛饭、CTWAP)，這甚至包括一些iPhone終端萍歉。實(shí)際上侣颂，WAP網(wǎng)關(guān)本質(zhì)是個(gè)代理，不完全是落后的東西翠桦，隨著技術(shù)的進(jìn)步也在演進(jìn)横蜒，以后在組網(wǎng)架構(gòu)中可能有綜合網(wǎng)關(guān)、內(nèi)容計(jì)費(fèi)網(wǎng)關(guān)來取代目前的WAP網(wǎng)關(guān)销凑，所以建議也要一并考慮丛晌。以下是做WAP優(yōu)化需要注意的一些問題：

1. 資費(fèi)提醒頁(yè)面
2. 302跳轉(zhuǎn)處理
3. X-Online-Host使用與處理
4. 包大小限制
5. 劫持與緩存
6. 正確獲取資源包大小

4.5 業(yè)務(wù)邏輯優(yōu)化

1、簡(jiǎn)化邏輯：交互繁瑣的內(nèi)容盡量用標(biāo)識(shí)更新斗幼。舉一個(gè)例子澎蛛，我們?cè)诶习娴氖謾C(jī)QQ上做過一個(gè)測(cè)試：假如我有100個(gè)好友，用手機(jī)QQ完成登陸蜕窿，完成好友列表更新一遍谋逻，需要3.5分鐘。這肯定是不合理的桐经。建議用信令狀態(tài)來通知是否需要更新毁兆，同時(shí)合理利用緩存。在比如玩游戲阴挣，好友給你送了很多星星气堕，是讓用戶一次一次點(diǎn)還是批量點(diǎn)?從優(yōu)化的角度肯定是批量點(diǎn)，從用戶體驗(yàn)的角度這也更加舒服。

另一方面茎芭，延長(zhǎng)域名圖標(biāo)的緩存時(shí)間也可以有效地優(yōu)化訪問次數(shù)揖膜。我們把手機(jī)騰訊網(wǎng)圖標(biāo)的緩存時(shí)長(zhǎng)從120分鐘延長(zhǎng)到2天后，訪問次數(shù)優(yōu)化了差不多35%梅桩。

2壹粟、柔性可用：這個(gè)意思就是在網(wǎng)絡(luò)質(zhì)量好的時(shí)候給高清大圖，不好的時(shí)候先給用戶看小圖宿百，點(diǎn)一下再拉取原圖趁仙。舉一個(gè)極端的例子，比如萬一地震了犀呼，基站毀掉20%幸撕，用戶要給家人報(bào)平安，這時(shí)候產(chǎn)品上就必須優(yōu)化外臂，比如只發(fā)送文字坐儿，合理降3,低網(wǎng)絡(luò)消耗。另外在響應(yīng)很慢的時(shí)候宋光，需要給用戶一些合理的頁(yè)面提示貌矿，比如提示用戶再過5秒會(huì)發(fā)送，所以你不要一直刷屏罪佳，這也可以減少訪問對(duì)后臺(tái)服務(wù)逛漫、對(duì)網(wǎng)絡(luò)的沖擊。

五 實(shí)戰(zhàn)演示

5.1 一個(gè)最優(yōu)調(diào)度設(shè)計(jì)示例

上面說了那么多赘艳，這里就給出一個(gè)實(shí)例幫助大家更直觀的理解酌毡。

這里給出一個(gè)DNS系統(tǒng)設(shè)計(jì)來實(shí)現(xiàn)最優(yōu)調(diào)度。其拓?fù)浣Y(jié)構(gòu)如下：

弱網(wǎng)下移動(dòng)端網(wǎng)絡(luò)連接處理策略

TGCP SDK的職責(zé)：

1. 用HTTP的Get/Post方法從DNSvr獲服務(wù)器和DNSvr本身的最優(yōu)接入點(diǎn)列表蕾管。Get/Post方法的查詢參數(shù)包括uin/openid枷踏、客戶端版本號(hào)、IP列表的MD5(注意IP順序)掰曾、域名列表旭蠕、VIP、ServiceID等旷坦。
2. 緩存訪問服務(wù)器和DNSvr的IP列表掏熬，以及其它元數(shù)據(jù)(比如IP列表等)，且以APN為主鍵秒梅。
3. 滿足一定的條件下旗芬，要主動(dòng)更新緩存的IP列表，例如緩存過期捆蜀。

Tconnd的職責(zé)：

1. 路由查詢請(qǐng)求給活動(dòng)的DNSvr;

DNSvr的職責(zé)：

1. 根據(jù)靜態(tài)和動(dòng)態(tài)策略來決定客戶端的“最優(yōu)接入點(diǎn)”岗屏。靜態(tài)策略：根據(jù)uin/openid辆琅、客戶端版本號(hào)或者強(qiáng)制規(guī)則來決定IP列表;動(dòng)態(tài)策略：燈塔根據(jù)測(cè)速數(shù)據(jù)動(dòng)態(tài)決定用戶的服務(wù)器接入點(diǎn)。
2. 支持以手動(dòng)或自動(dòng)的方式拉黑某些IP这刷。自動(dòng)方式：由服務(wù)器的接入tconnd向DNSvr上報(bào)其是否存活(需要向多個(gè)點(diǎn)上報(bào)，包括用公網(wǎng)IP上報(bào))娩井，如果在一定時(shí)間內(nèi)沒有接收到上報(bào)或者上報(bào)消息中明確所有的邏輯服務(wù)器已經(jīng)掛掉暇屋，則自動(dòng)拉黑相應(yīng)的IP。如果業(yè)務(wù)恢復(fù)洞辣，則自動(dòng)激活相應(yīng)的IP咐刨。如果項(xiàng)目組接入TGW，對(duì)于某個(gè)IP和端口是否可用扬霜，則需要考慮進(jìn)程與VIP的映射關(guān)系定鸟。
3. 在tcaplus中緩存燈塔的計(jì)算結(jié)果。此時(shí)要求DNSvr能夠根據(jù)客戶端IP判斷所屬的國(guó)家著瓶、省份联予、運(yùn)營(yíng)商和網(wǎng)關(guān)(可以通過訪問MIG的IP庫(kù)實(shí)現(xiàn))。如果緩存了燈塔的計(jì)算結(jié)果材原，當(dāng)緩存超時(shí)后沸久，要重新從燈塔拉取相應(yīng)數(shù)據(jù)。

燈塔的職責(zé)：

1. 根據(jù)客戶端IP和服務(wù)器接入點(diǎn)IP余蟹，返回最優(yōu)的接入點(diǎn)列表卷胯，包括IP的排序，以及客戶端接入的國(guó)家威酒、省份窑睁、運(yùn)營(yíng)商、APN和網(wǎng)關(guān)葵孤。

Tcaplus的職責(zé)：

• 保存接入的IP列表和端口担钮、靜態(tài)策略，或緩存燈塔的計(jì)算結(jié)果;

主要的流程：

客戶端批量解析域名流程

1. TGCP以APN和域名列表為關(guān)鍵字查詢緩存佛呻，如果存在且沒有過期裳朋，則直接把IP返回給用戶。如果指定強(qiáng)制解析域名列表吓著，則跳過此步驟;
2. TGCP用預(yù)配置或緩存的IP向DNSvr發(fā)起查詢請(qǐng)求鲤嫡，如果成功返回結(jié)果，則執(zhí)行步驟3绑莺，否則暖眼，重試IP列表中的其它IP，如果都失敗纺裁，則用域名訪問DNSvr诫肠。注意：如果是結(jié)果格式不正確司澎，則使用上次的IP重試，不要更換IP重試栋豫。
3. DNSvr比較客戶端IP列表和當(dāng)前最新的IP列表的MD5挤安，如果相等，則告訴客戶端不需要更新本地緩存丧鸯。否則蛤铜，TGCP把接入服務(wù)器和DNSvr的IP列表寫入本地。注意：在訪問服務(wù)器時(shí)丛肢，這些IP的優(yōu)先級(jí)要高于靜態(tài)配置在客戶端的IP围肥。

客戶端使用域名訪問服務(wù)器流程

1. 如果本地存在有效的IP(即存在對(duì)應(yīng)APN的IP列表，且沒有失效)蜂怎，則使用IP訪問服務(wù)器穆刻。
2. 否則，發(fā)起“客戶端批量解析域名流程”后杠步，再訪問服務(wù)器氢伟。

服務(wù)器接入tconnd主動(dòng)上報(bào)狀態(tài)流程：

1. Tconnd周期性向DNSvr上報(bào)心跳消息，其中包含本接入點(diǎn)是否可用的信息篮愉。
2. DNSvr在一定的時(shí)間內(nèi)沒有收到心跳消息或者相應(yīng)的接入點(diǎn)不可用腐芍，則把相應(yīng)的IP和端口拉黑，黑掉的IP不在下發(fā)給客戶端试躏。

注意：實(shí)際部署的時(shí)候猪勇，接入的Tconnd要向多個(gè)DNSvr接入tconnd上報(bào)。

向客戶端主動(dòng)push接入點(diǎn)列表的流程

1. 當(dāng)TGCP連接到服務(wù)器接入的Tconnd時(shí)颠蕴，Tconnd要向DNSvr發(fā)起請(qǐng)求泣刹，以校驗(yàn)當(dāng)前接入IP的質(zhì)量和時(shí)效性。如果IP列表發(fā)生變化犀被，Tconnd要把最新的IP列表下發(fā)給客戶端緩存起來椅您。
2. 當(dāng)TGCP下次訪問服務(wù)器時(shí)，則使用最新的IP列表寡键。

客戶端訪問DNSvr失敗的流程

1. 如果訪問DNSvr失敗(包括IP+域名)掀泳，如果配置了本地IP，則直接用IP訪問服務(wù)器西轩，否則用域名訪問员舵。

優(yōu)化傳輸層協(xié)議設(shè)計(jì)

在原有tconnd支持的可靠UDP的基礎(chǔ)之上，添加以下邏輯：

1. 數(shù)據(jù)壓縮;
2. 數(shù)據(jù)加密;
3. 合并多個(gè)數(shù)據(jù)包;
4. 支持流式數(shù)據(jù)傳輸藕畔，便于控制每個(gè)UDP包的大小马僻，也便于數(shù)據(jù)加密和壓縮;
5. 可選地支持改進(jìn)的擁塞控制算法;
6. 即使沒有接收到ACK包，也需要主動(dòng)重試以發(fā)送的數(shù)據(jù)包;

5.2 Hybird開發(fā)下的一些優(yōu)化

要處理在弱網(wǎng)絡(luò)下的加載速度注服，那么我們要先確定一下我們的整個(gè)APP在哪個(gè)地方加載的速度如何韭邓，最長(zhǎng)的加載路徑在哪里措近，我們從而才有針對(duì)性的進(jìn)行優(yōu)化與修改。

5.2.1 WebView

如果是對(duì)是APP中內(nèi)嵌的webview網(wǎng)頁(yè)女淑，針對(duì)網(wǎng)頁(yè)體驗(yàn)優(yōu)化已經(jīng)由來已久了瞭郑。我們可以使用Chrome的開發(fā)者模式，調(diào)整到Network模式下鸭你，將網(wǎng)絡(luò)條件設(shè)置為3G去請(qǐng)求網(wǎng)頁(yè)凰浮，那么我們就能夠看出來一個(gè)網(wǎng)頁(yè)加載的速度主要都耗費(fèi)在哪個(gè)地方，如下圖所示：

弱網(wǎng)下移動(dòng)端網(wǎng)絡(luò)連接處理策略

當(dāng)然苇本，html的加速方式有很多種

1. 使用gulpgrunt進(jìn)行打包壓縮：jscss資源壓縮，CSS Sprites合并等菜拓。
2. 使用font-awesome替換圖片：字體可以很好的兼容瓣窄，無限放大，常用的圖片都有