狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

　　 [ 核心提示 ] 移動互聯網的組織形態、架構、通訊機制等等與有線網絡都有著巨大的差異，騰訊在處理這種差異的時候都有哪些經驗呢？
　　編者注：本文轉自騰訊大講堂。在 2014 年 4 月 11 日的騰訊分享日活動上，來自騰訊 MIG 的移動互聯網事業群運營總監 /T4 專家，負責運營 QQ 手機瀏覽器、騰訊 PC 瀏覽器、騰訊手機安全管家、騰訊電腦管家產品的劉昕介紹了移動無線產品研發中的 " 一秒鐘法則 "。
　　移動互聯網的一個很大問題在于無線網絡跟以前的有線網絡不一樣，無論是網絡的組織形態、架構、通訊機制，跟有線網絡都有很大差異，這帶來很多挑戰。今天介紹的 " 一秒鐘法則 " 就是根據我們在移動互聯網研發、運營過程中總結出來的一條解決的原則。
　　手機接入服務器的流程
　　首先，手機要通過無線網絡協議，從基站獲得無線鏈路分配，才能跟網絡進行通訊。無線網絡基站、基站控制器這方面，會給手機進行信號的分配，已完成手機連接和交互。
　　獲得無線鏈路后，會進行網絡附著、加密、鑒權，核心網絡會檢查你是不是可以連接在這個網絡上，是否開通套餐，是不是漫游等。核心網絡有 SGSN 和 GGSN，在這一步完成無線網絡協議和有線以太網的協議轉換。
　　再下一步，核心網絡會給你進行 APN 選擇、IP 分配、啟動計費。
　　再往下面，才是傳統網絡的步驟：DNS 查詢、響應，建立 TCP 鏈接，HTTP GET，RTTP RESPONSE 200 OK，HTTP RESPONSE DATA，LAST HTTP RESPONSE DATA，開始 UI 展現。
　　這是手機通過無線網絡接入服務器的全過程。整個過程當中有幾個困擾開發者的問題：
　　無線網絡是怎么給手機分配到無線鏈路的？
　　核心網絡有接入點（APN），這里的 CMNET 和 CMWAP 有什么區別，僅僅是協議不同嗎嗎？數據轉發又有什么區別？一個數據包在不同網絡上傳輸有不同嗎？
　　用戶怎么最快的找到正確的服務器？內容怎么快速有效的加載，在第一時間顯示出來？
　　這幾個問題的重點在于其中的幾個連接點：
　　無線鏈路分配（物理實連接）；
　　IP 層鏈接（邏輯虛連接）；
　　TCP 層鏈接（邏輯虛連接）；
　　HTTP 層鏈接（邏輯虛連接）；
　　用戶在線（邏輯虛連接）。
　　即使 TCP 連接建立，看到用戶在線，也必須在手機獲得無線鏈路分配的情況下，一個完整的通信才能真正完成，上行下行數據才能發送。這是移動互聯網非常重要的特性。在現實中，手機已經分配 IP 也可能是沒有無線鏈路，為什么？無線網絡的資源是有限的，必須有效利用，這里由無線網絡的信令機制完成無線網絡資源的分配與釋放。
　　以用手機打電話的場景示例：用戶在手機上撥號出去后，手機會跟網絡申請無線鏈路，呼叫申請會發給電路域的核心網，通過電話交換機找尋被叫電話，被叫方接通電話，無線鏈路建立；完成通話，掛斷的時候，手機給網絡發送指令，表示服務使用結束，把已經分配的無線鏈路釋放。
　　上網的情況就比較復雜一些了。什么時候決定無線鏈路的分配？什么時候決定通訊完成？對于這兩個時間點，不同的網絡制式、不同的運營商都是不同的，不過大致上有幾個區間值：
　　在 2G Edge 網絡下，差不多是 1 秒鐘不傳數據，就釋放物理連接，回收給其他人備用。3G 網絡會延長幾秒鐘。
　　這樣的設定是有原因的。比如現在我們這個會場里有 200 人，那么我們 200 人同時上網的前提是共享同一個基站的資源，共享資源必須要有規則，比如要有排序，根據資源情況、用戶鏈接活躍決定分配還是回收，這都是通過無線網絡信令控制的。
　　給一個手機分配無線信道的信令又有好幾個情況，比如基站跟手機，基站跟基站控制器、核心網。舉個例子，服務器從后臺發送 push 消息，移動網絡可能不知道這個手機是否活躍，不知道在哪個小區，移動網絡就會發一個尋呼，在各個小區找這個手機，當然這個不能基于 IP，而是其他的網絡標識。找到了之后，這個手機再去申請信道資源，然后才能接受 push。所以，這種場景下信令的消耗可能會在很多小區產生。
　　根據以上情況，就形成無線網絡的一大特點：秒級狀態管理，秒級狀態轉換。這兩個操作都在幾百毫秒到幾秒之間進行，對于維持連接來說時間太短，對于從無連接到有連接的轉換來說時間又太長。
　　相比之下，有線網絡的狀態管理如 IP 分配、TCP 連接釋放，都是分鐘級，而狀態轉換則是毫秒級。
　　這些通訊機制，同時加上無線網絡的高延遲、高丟包。如何保證移動互聯網的產品提供穩定的、可預期的服務質量，成為非常大的挑戰： ??2G 網絡上無線部分數據傳輸的延遲有幾百 ms，4G 網絡上無線部分傳輸延遲減少到幾十 ms，核心網狀態轉換、協議轉換 30~100ms，IP 骨干網上的延遲又跟物理距離以及運營商互聯互通質量有關，跨運營商 50-400ms，同運營商 5-80ms，這個還要取決于網絡擁塞的情況。 ?? 無線網絡誤碼率比有線高兩個數量級，在不同時間段的波動也非常巨大。
　　怎么基于移動網絡的特性去優化服務？這就是我們總結的一秒鐘法則：在一秒內要完成的規定動作。
　　2G 網絡：1 秒內完成 DNS 查詢、和后臺服務器建立連接；
　　3G 網絡：1 秒內完成首字顯示（首字時間）；
　　WiFi 網絡：1 秒內完成首屏顯示（首屏時間）。
　　這些指標需要在終端度量，必須跟用戶體驗相關：首字時間、首屏時間都必須是用戶可以直觀感受到的。
　　優化思路 接入調度優化
　　接入調度優化首先要考慮的是減少 DNS 的影響。移動網絡的 DNS 有如下特點：
　　骨干網無法識別移動用戶在哪個城市，東西南北各個地方的調度沒有充分調用，目前有一部分全國范圍的 DNS 承載了超過 40% 的全網用戶；
　　很多山寨機的終端 Local DNS 設置是錯誤的。
　　另外還有一些有線網絡也一樣會遇到的問題，如終端 DNS 解析濫用、域名劫持、DNS 污染、老化、脆弱等。不過對于這些問題，桌面的自愈性會比較好，而在手機上則比較難以解決。
　　對于 DNS 的問題，有兩條主要的解決思路：
　　減少 DNS 的請求、查詢、更新，也就是做 DNS 緩存；
　　在終端配置 server list，直接訪問 IP，不用 DNS。
　　但僅僅這么做還不夠，因為用戶可能來自國內外不同的運營商，還需要進一步優化調度策略：
　　DNS 緩存需要多建立接入點，用不同域名區分；
　　IP 列表需要更新以適應不同網絡情況，要做到主動調度。好比最早我們只服務好移動用戶就行，保證移動用戶的接入質量優先，因為絕大多數用戶集中在移動；現在國內有三個運營商，用戶分布的比例在慢慢接近，要區分清楚；智能手機會用 WiFi，接入的是電信、聯通還是哪個運營商，不知道，所以你不可能預先設置場景再 if then，必須通過后臺調度能力來解決。
　　再進一步優化，就產生一種融合的方式：
　　先做域名解析，客戶端直接連接解析的 IP，可以用 http 協議，也可以用 tcp socket；
　　多端口、多協議組合：不同協議有不同的限制，有些只能 http，有些只能 tcp socket，各種環境都要適應，客戶端不能只支持一種協議；
　　終端測速：接入點越來越多，接入哪個合適，要選擇，可以通過終端測速來選擇最快的。你當然可以每一次新建連接都做測速，但是這樣建立連接時間可能會很長；我們可以給用戶先建立連接后，在后臺根據長期速度監控、當前測速的結果，來做動態調度。也就是說，第一次連接可能不是最優，連接建立后動態測速，再轉移到最快接入點。更進一步就是建立網絡 profile，終端學習的思路。
　　測速采樣的粒度我也說一下，移動互聯網取 IP 段是沒用的，比較好的粒度是到網元級別，比如廣東有 20 多個 wap 網關，每一個網關的情況都不一樣，這就是一個比較合適的粒度。
　　另外我們后面還有一個 SET 模型，可以就近提供服務。
　　最后想強調一個所有的接入調度原則：不要把調度邏輯寫死在客戶端，一定要由后臺完成。
　　協議優化
　　協議參數優化這塊就簡單列一下，是我們長期運營過程中總結的一些經驗，在啟動移動互聯網服務時作為運營的規范，可以少走很多彎路：
　　關閉 TCP 快速回收；
　　Init RTO 不低于 3 秒；
　　初始擁塞控制窗口不小于 10。因為大部分頁面在 10kB 以下，很多請求在慢啟動階段已經結束，改為 10 可以降低小頁面資源傳輸時延。內容越大，這個選項的效果就比較不明顯；
　　Socket buffer > 64k；
　　TCP 滑動窗口可變；
　　控制發包大小在 1400 字節以下，避免分片。
　　協議優化的原則總結下來是這么幾條：
　　連接重用；
　　并發連接控制；
　　超時控制；
　　包頭精簡；
　　內容壓縮；
　　選擇更高效率的協議。無論是 TCP、HTTP、UDP、長連接、GZIP、SPDY、WUP 還是 WebP，每一種協議、方案都有其道理，沒有最優，只有是否適合你的產品和服務特點，需要大家在運營過程驗證和取舍。
　　WAP 接入點優化
　　關于 WAP 接入點優化，可能有些人會說，我們的 App 是高端大氣上檔次的應用，是不是就不用做 WAP 優化？實際上我們的統計顯示，目前有 5%-20% 的用戶選擇的接入點是＊WAP（CMWAP、3GWAP、CTWAP），這甚至包括一些 iPhone 終端。實際上，WAP 網關本質是個代理，不完全是落后的東西，隨著技術的進步也在演進，以后在組網架構中可能有綜合網關、內容計費網關來取代目前的 WAP 網關，所以建議也要一并考慮。以下是做 WAP 優化需要注意的一些問題：
　　資費提醒頁面；
　　302 跳轉處理；
　　X-Online-Host 使用與處理；
　　包大小限制；
　　劫持與緩存；
　　正確獲取資源包大小。
　　業務邏輯優化
　　簡化邏輯：交互繁瑣的內容盡量用標識更新。舉一個例子，我們在老版的手機 QQ 上做過一個測試：假如我有 100 個好友，用手機 QQ 完成登陸，完成好友列表更新一遍，需要 3.5 分鐘。這肯定是不合理的。建議用信令狀態來通知是否需要更新，同時合理利用緩存。在比如玩游戲，好友給你送了很多星星，是讓用戶一次一次點還是批量點？從優化的角度肯定是批量點，從用戶體驗的角度這也更加舒服。
　　另一方面，延長域名圖標的緩存時間也可以有效地優化訪問次數。我們把手機騰訊網圖標的緩存時長從 120 分鐘延長到 2 天后，訪問次數優化了差不多 35%。
　　柔性可用：這個意思就是在網絡質量好的時候給高清大圖，不好的時候先給用戶看小圖，點一下再拉取原圖。舉一個極端的例子，比如萬一地震了，基站毀掉 20%，用戶要給家人報平安，這時候產品上就必須優化，比如只發送文字，合理降低網絡消耗。另外在響應很慢的時候，需要給用戶一些合理的頁面提示，比如提示用戶再過 5 秒會發送，所以你不要一直刷屏，這也可以減少訪問對后臺服務、對網絡的沖擊。
　　最后談談對優化方法的實踐和結果的評估。QQ 手機瀏覽器從 4.5 版本、5.0 版本到 5.1 版本，我們對 2G 網絡下的連接時間、3G 網絡下的首字耗時、wifi 網絡下的首屏耗時進行持續監控，耗時降到一秒鐘以下還在不斷的改進，每個新的版本平均值均有所壓縮。這個結果是從每天用戶實際使用的運營數據中得到的，覆蓋到絕大多數的手機終端和網絡環境。
　　不過平均值只是一方面，我們另一方面還要看 " 有多少比例的數據滿足了一秒鐘法則 " 這個維度，因為無線網絡的長尾數據波動很大，這一個維度也非常重要。目前現狀是我們 2G 網絡做到 79%，3G 網絡做到 73%，WiFi 網絡做到 69%。目前我們的目標是達到 80%，實現之后，再進一步挑戰 90% 的比例，不斷追求極致。
原文地址：http://iphone.myzaker.com/l.php?l=534ce4f31bc8e0d87d8b4568