移動互聯(lián)網(wǎng)的一個很大問題在于無線網(wǎng)絡(luò)跟以前的有線網(wǎng)絡(luò)不一樣，無論是網(wǎng)絡(luò)的組織形態(tài)、架構(gòu)、通訊機(jī)制，跟有線網(wǎng)絡(luò)都有很大差異，這帶來很多挑戰(zhàn)。今天介紹的“一秒鐘法則”就是根據(jù)我們在移動互聯(lián)網(wǎng)研發(fā)、運營過程中總結(jié)出來的一條解決的原則。

手機(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 分配、啟動計費。

再往下面，才是傳統(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ā)者的問題：

1. 無線網(wǎng)絡(luò)是怎么給手機(jī)分配到無線鏈路的？
2. 核心網(wǎng)絡(luò)有接入點（APN），這里的 CMNET 和 CMWAP 有什么區(qū)別，僅僅是協(xié)議不同嗎嗎？數(shù)據(jù)轉(zhuǎn)發(fā)又有什么區(qū)別？一個數(shù)據(jù)包在不同網(wǎng)絡(luò)上傳輸有不同嗎？
3. 用戶怎么最快的找到正確的服務(wù)器？內(nèi)容怎么快速有效的加載，在***時間顯示出來？

這幾個問題的重點在于其中的幾個連接點：

1. 無線鏈路分配（物理實連接）；
2. IP 層鏈接（邏輯虛連接）；
3. TCP 層鏈接（邏輯虛連接）；
4. HTTP 層鏈接（邏輯虛連接）；
5. 用戶在線（邏輯虛連接）。

即使 TCP 連接建立，看到用戶在線，也必須在手機(jī)獲得無線鏈路分配的情況下，一個完整的通信才能真正完成，上行下行數(shù)據(jù)才能發(fā)送。這是移動互聯(lián)網(wǎng)非常重要的特性。在 現(xiàn)實中，手機(jī)已經(jīng)分配 IP 也可能是沒有無線鏈路，為什么？無線網(wǎng)絡(luò)的資源是有限的，必須有效利用，這里由無線網(wǎng)絡(luò)的信令機(jī)制完成無線網(wǎng)絡(luò)資源的分配與釋放。

以用手機(jī)打電話的場景示例：用戶在手機(jī)上撥號出去后，手機(jī)會跟網(wǎng)絡(luò)申請無線鏈路，呼叫申請會發(fā)給電路域的核心網(wǎng)，通過電話交換機(jī)找尋被叫電話，被叫方接通電話，無線鏈路建立；完成通話，掛斷的時候，手機(jī)給網(wǎng)絡(luò)發(fā)送指令，表示服務(wù)使用結(jié)束，把已經(jīng)分配的無線鏈路釋放。

上網(wǎng)的情況就比較復(fù)雜一些了。什么時候決定無線鏈路的分配？什么時候決定通訊完成？對于這兩個時間點，不同的網(wǎng)絡(luò)制式、不同的運營商都是不同的，不過大致上有幾個區(qū)間值：

在 2G Edge 網(wǎng)絡(luò)下，差不多是 1 秒鐘不傳數(shù)據(jù)，就釋放物理連接，回收給其他人備用。3G 網(wǎng)絡(luò)會延長幾秒鐘。

這樣的設(shè)定是有原因的。比如現(xiàn)在我們這個會場里有 200 人，那么我們 200 人同時上網(wǎng)的前提是共享同一個基站的資源，共享資源必須要有規(guī)則，比如要有排序，根據(jù)資源情況、用戶鏈接活躍決定分配還是回收，這都是通過無線網(wǎng)絡(luò)信令控制的。

給一個手機(jī)分配無線信道的信令又有好幾個情況，比如基站跟手機(jī)，基站跟基站控制器、核心網(wǎng)。舉個例子，服務(wù)器從后臺發(fā)送 push 消息，移動網(wǎng)絡(luò)可能不知道這個手機(jī)是否活躍，不知道在哪個小區(qū)，移動網(wǎng)絡(luò)就會發(fā)一個尋呼，在各個小區(qū)找這個手機(jī)，當(dāng)然這個不能基于 IP，而是其他的網(wǎng)絡(luò)標(biāo)識。找到了之后，這個手機(jī)再去申請信道資源，然后才能接受 push。所以，這種場景下信令的消耗可能會在很多小區(qū)產(chǎn)生。

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

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

這些通訊機(jī)制，同時加上無線網(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)上的延遲又跟物理距離以及運營商互聯(lián)互通質(zhì)量有關(guān)，跨運營商 50-400ms，同運營商 5-80ms，這個還要取決于網(wǎng)絡(luò)擁塞的情況。 •無線網(wǎng)絡(luò)誤碼率比有線高兩個數(shù)量級，在不同時間段的波動也非常巨大。

怎么基于移動網(wǎng)絡(luò)的特性去優(yōu)化服務(wù)？這就是我們總結(jié)的一秒鐘法則：在一秒內(nèi)要完成的規(guī)定動作。

• 2G 網(wǎng)絡(luò)：1 秒內(nèi)完成 DNS 查詢、和后臺服務(wù)器建立連接；
• 3G 網(wǎng)絡(luò)：1 秒內(nèi)完成首字顯示（首字時間）；
• WiFi 網(wǎng)絡(luò)：1 秒內(nèi)完成首屏顯示（首屏?xí)r間）。

這些指標(biāo)需要在終端度量，必須跟用戶體驗相關(guān)：首字時間、首屏?xí)r間都必須是用戶可以直觀感受到的。

優(yōu)化思路

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

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

1. 骨干網(wǎng)無法識別移動用戶在哪個城市，東西南北各個地方的調(diào)度沒有充分調(diào)用，目前有一部分全國范圍的 DNS 承載了超過 40% 的全網(wǎng)用戶；
2. 很多山寨機(jī)的終端 Local DNS 設(shè)置是錯誤的。 

另外還有一些有線網(wǎng)絡(luò)也一樣會遇到的問題，如終端 DNS 解析濫用、域名劫持、DNS 污染、老化、脆弱等。不過對于這些問題，桌面的自愈性會比較好，而在手機(jī)上則比較難以解決。

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

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

但僅僅這么做還不夠，因為用戶可能來自國內(nèi)外不同的運營商，還需要進(jìn)一步優(yōu)化調(diào)度策略：

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

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

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

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

另外我們后面還有一個 SET 模型，可以就近提供服務(wù)。

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

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

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

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

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

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

WAP 接入點優(yōu)化

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

• 資費提醒頁面；
• 302 跳轉(zhuǎn)處理；
• X-Online-Host 使用與處理；
• 包大小限制；
• 劫持與緩存；
• 正確獲取資源包大小。

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

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

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

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

***談?wù)剬?yōu)化方法的實踐和結(jié)果的評估。QQ 手機(jī)瀏覽器從 4.5 版本、5.0 版本到 5.1 版本，我們對 2G 網(wǎng)絡(luò)下的連接時間、3G 網(wǎng)絡(luò)下的首字耗時、wifi 網(wǎng)絡(luò)下的首屏耗時進(jìn)行持續(xù)監(jiān)控，耗時降到一秒鐘以下還在不斷的改進(jìn)，每個新的版本平均值均有所壓縮。這個結(jié)果是從每天用戶實際使用的運營數(shù)據(jù)中得到的，覆 蓋到絕大多數(shù)的手機(jī)終端和網(wǎng)絡(luò)環(huán)境。

不過平均值只是一方面，我們另一方面還要看“有多少比例的數(shù)據(jù)滿足了一秒鐘法則”這個維度，因為無線網(wǎng)絡(luò)的長尾數(shù)據(jù)波動很大，這一個維度也非常重要。目前現(xiàn) 狀是我們 2G 網(wǎng)絡(luò)做到 79%，3G 網(wǎng)絡(luò)做到 73%，WiFi 網(wǎng)絡(luò)做到 69%。目前我們的目標(biāo)是達(dá)到 80%，實現(xiàn)之后，再進(jìn)一步挑戰(zhàn) 90% 的比例，不斷追求***。

【移動開發(fā)視頻課程推薦】

• iOS培訓(xùn)之Objective-C基礎(chǔ)視頻教程(40集)
• Cocos2d-x從零開始【5天掌握跨平臺游戲開發(fā)利器】(12集)
• Objective C編程基礎(chǔ)(24集)
• Android技術(shù)輕松入門課程(12集)
• 微信開放平臺-Android應(yīng)用接入(4集)
• Cocos2d-x跨平臺游戲開發(fā)入門基礎(chǔ)(29集)
• iOS開發(fā)視頻教程-iOS網(wǎng)絡(luò)編程【高級篇】(39集)
• 移動應(yīng)用用戶體驗設(shè)計高級課程(60集)
• 從零學(xué)習(xí)iOS開發(fā)–UI多視圖(30集)
• iOS開發(fā)視頻教程【基礎(chǔ)入門篇】