一、背景

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

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

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

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

• 首先，手機(jī)要通過無線網(wǎng)絡(luò)協(xié)議，從基站獲得無線鏈路分配，才能跟網(wǎng)絡(luò)進(jìn)行通訊。
• 無線網(wǎng)絡(luò)基站、基站控制器這方面，會給手機(jī)進(jìn)行信號的分配，已完成手機(jī)連接和交互。
• 獲得無線鏈路后，會進(jìn)行網(wǎng)絡(luò)附著、加密、鑒權(quán)，核心網(wǎng)絡(luò)會檢查你是不是可以連接在這個網(wǎng)絡(luò)上，是否開通套餐，是不是漫游等。核心網(wǎng)絡(luò)有SGSN和GGSN，在這一步完成無線網(wǎng)絡(luò)協(xié)議和有線以太網(wǎng)的協(xié)議轉(zhuǎn)換。
• 再下一步，核心網(wǎng)絡(luò)會給你進(jìn)行APN選擇、IP分配、啟動計(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ù)器的全過程。整個過程當(dāng)中有幾個困擾開發(fā)者的問題：

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

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

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

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

• 無線鏈路分配。這是一個物理實(shí)連接。
• IP層鏈接。這是一個邏輯虛連接。
• TCP層鏈接。這是一個邏輯虛連接。
• HTTP層鏈接。這是一個邏輯虛連接。
• 用戶在線。這是一個邏輯虛連接。

3.2 一秒鐘法則

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

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

這些通訊機(jī)制，同時(shí)加上無線網(wǎng)絡(luò)的高延遲、高丟包。如何保證移動互聯(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)營商互聯(lián)互通質(zhì)量有關(guān)，跨運(yùn)營商50-400ms，同運(yùn)營商5-80ms，這個還要取決于網(wǎng)絡(luò)擁塞的情況。

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

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

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

1. 2g網(wǎng)絡(luò)：1秒內(nèi)完成dns查詢、和后臺服務(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ù)保證原則

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

1. 接口設(shè)計(jì)優(yōu)化，接口的優(yōu)化理論上不屬于APP弱網(wǎng)絡(luò)的優(yōu)化，但是這個的API性能的問題，確實(shí)在網(wǎng)絡(luò)條件不好的情況下才暴露無遺。大家都在談?wù)摲?wù)器的好壞，設(shè)備的性能高低，其實(shí)，對于一個良好的Server來說，絕大部分拖延請求速度的地方都是在IO上。包括，磁盤讀寫的IO，SQL查詢的IO等等。常用的優(yōu)化點(diǎn)：慢查詢監(jiān)控 、多次查詢優(yōu)化、常用接口cache等。
2. 圖片相關(guān)策略。
3. 使用更快的圖片格式，嚴(yán)格說也不算弱網(wǎng)下的優(yōu)化，但一個更快的圖片格式真的很重要!這里建議采用WebP格式。(WebP格式，谷歌(google)開發(fā)的一種旨在加快圖片加載速度的圖片格式。圖片壓縮體積大約只有JPEG的2/3，并能節(jié)省大量的服務(wù)器帶寬資源和數(shù)據(jù)空間。但WebP是一種有損壓縮。相較編碼JPEG文件，編碼同樣質(zhì)量的WebP文件需要占用更多的計(jì)算資源。)
4. 不同網(wǎng)絡(luò)的不同圖片下發(fā)。如(對于原圖是600X480的圖片)：2/3G使用低清晰度圖片——>下發(fā)300X240，精度為80的圖片、4G普通清晰度圖片——>下發(fā)600X480，精度為80的圖片、WiFi高清晰度圖片(最好根據(jù)網(wǎng)速來判斷，wifi也有慢的)——>下發(fā)600X480，精度為100的圖片。
5. 斷線重連。這可能是最重的一個特性，因?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)建連接是一個非常昂貴的操作，所以應(yīng)盡量減少數(shù)據(jù)連接的創(chuàng)建次數(shù)，且在一次請求中應(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)化包量。通過壓縮、精簡包頭、消息合并等方式，來減小數(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ù)的取值差異可能會很大。
11. 優(yōu)化ACK包。在弱網(wǎng)絡(luò)的情況下，TCP協(xié)議中的ACK包是非常昂貴的，延時(shí)甚至能夠達(dá)到秒級別，而TCP協(xié)議的擁塞控制、快速重傳、快速恢復(fù)等特性都非常依賴接收端反饋的ACK包。可想而知，如果發(fā)送端接收到的ACK包延時(shí)太長，會嚴(yán)重影響TCP協(xié)議的效率。但是如果發(fā)送ACK太多又會占用寶貴過多的無線資源。在移動網(wǎng)絡(luò)下通信，“在可靠的連接上，如何在減少ACK包的情況下，降低數(shù)據(jù)包的延時(shí)”是研究的熱點(diǎn)?；镜乃枷耄浩胶馊哂喟虯CK包個數(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ì)的，很明顯這個假設(shè)在無線網(wǎng)絡(luò)環(huán)境下是不合適的。但是在無線網(wǎng)絡(luò)環(huán)境下，在設(shè)計(jì)可靠UDP協(xié)議時(shí)是否能夠完全丟棄擁塞控制呢?這里有其它的文章中提出了幾種在無線網(wǎng)絡(luò)環(huán)境下的TCP友好的擁塞控制算法，有興趣可以自行查閱。
13. 靈活使用長連接/短連接，支持不同協(xié)議(TCP/UDP, http、二進(jìn)制協(xié)議等)，支持不同端口等。
14. 讓用戶覺得快。到這里已經(jīng)不能算是技術(shù)層面的方法了，屬于一種心理層面的博弈，一種改善用戶體驗(yàn)的方式。比如：

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

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

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

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

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

• 減少DNS的請求、查詢、更新，也就是做DNS緩存
• 在終端配置server list，直接訪問IP，不用DNS

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

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

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

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

關(guān)于測速采樣的粒度，移動互聯(lián)網(wǎng)取IP段是沒用的，比較好的粒度是到網(wǎng)元級別，比如廣東有20多個wap網(wǎng)關(guān)，每一個網(wǎng)關(guān)的情況都不一樣，這就是一個比較合適的粒度。

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

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

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

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

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

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

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

關(guān)于WAP接入點(diǎn)優(yōu)化，可能有些人會說，我們的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ì)是個代理，不完全是落后的東西，隨著技術(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)提醒頁面
2. 302跳轉(zhuǎn)處理
3. X-Online-Host使用與處理
4. 包大小限制
5. 劫持與緩存
6. 正確獲取資源包大小

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

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

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

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

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

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

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

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

TGCP SDK的職責(zé)：

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

Tconnd的職責(zé)：

1. 路由查詢請求給活動的DNSvr;

DNSvr的職責(zé)：

1. 根據(jù)靜態(tài)和動態(tài)策略來決定客戶端的“最優(yōu)接入點(diǎn)”。靜態(tài)策略：根據(jù)uin/openid、客戶端版本號或者強(qiáng)制規(guī)則來決定IP列表;動態(tài)策略：燈塔根據(jù)測速數(shù)據(jù)動態(tài)決定用戶的服務(wù)器接入點(diǎn)。
2. 支持以手動或自動的方式拉黑某些IP。自動方式：由服務(wù)器的接入tconnd向DNSvr上報(bào)其是否存活(需要向多個點(diǎn)上報(bào)，包括用公網(wǎng)IP上報(bào))，如果在一定時(shí)間內(nèi)沒有接收到上報(bào)或者上報(bào)消息中明確所有的邏輯服務(wù)器已經(jīng)掛掉，則自動拉黑相應(yīng)的IP。如果業(yè)務(wù)恢復(fù)，則自動激活相應(yīng)的IP。如果項(xiàng)目組接入TGW，對于某個IP和端口是否可用，則需要考慮進(jìn)程與VIP的映射關(guān)系。
3. 在tcaplus中緩存燈塔的計(jì)算結(jié)果。此時(shí)要求DNSvr能夠根據(jù)客戶端IP判斷所屬的國家、省份、運(yùn)營商和網(wǎng)關(guān)(可以通過訪問MIG的IP庫實(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的排序，以及客戶端接入的國家、省份、運(yùn)營商、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ā)起查詢請求，如果成功返回結(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)先級要高于靜態(tài)配置在客戶端的IP。

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

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

服務(wù)器接入tconnd主動上報(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要向多個DNSvr接入tconnd上報(bào)。

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

1. 當(dāng)TGCP連接到服務(wù)器接入的Tconnd時(shí)，Tconnd要向DNSvr發(fā)起請求，以校驗(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. 合并多個數(shù)據(jù)包;
4. 支持流式數(shù)據(jù)傳輸，便于控制每個UDP包的大小，也便于數(shù)據(jù)加密和壓縮;
5. 可選地支持改進(jìn)的擁塞控制算法;
6. 即使沒有接收到ACK包，也需要主動重試以發(fā)送的數(shù)據(jù)包;

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

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

5.2.1 WebView

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

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

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