如何對“弱網絡”進行測量和模擬，對於手機APP的開發具有重要意義，如節省測試成本、容易重復出現問題、加快產品上市速度等。
壹般的方法是用“丟包率”和“網絡時延”來定義和衡量“弱網絡”。
二、手機訪問服務器的過程
要說這個問題，首先要了解手機訪問服務器的過程。
首先，手機只有通過無線網絡協議從基站獲得無線鏈路分配，才能與網絡進行通信。
另壹方面，無線網絡基站和基站控制器將信號分配給手機，並且已經完成了手機的連接和交互。
獲得無線鏈接後，網絡會被附著、加密、認證，核心網會檢查妳是否能連接到這個網絡，是否有套餐，是否在漫遊等。核心網是SGSN和GGSN，無線網絡協議和有線以太網的協議轉換在這壹步完成。
接下來，核心網絡將為您提供APN選擇、IP分配和啟動計費。
再往下，就是傳統網絡的步驟:DNS查詢響應、TCP鏈接建立、HTTP GET、RTTP響應200 OK、HTTP響應數據、最後壹次HTTP響應數據、UI展現。
這是手機通過無線網絡訪問服務器的全過程。在整個過程中有幾個問題困擾著開發者:
無線網絡如何為手機分配無線鏈接？
核心網絡有壹個接入點(APN)。這裏CMNET和CMWAP有什麽區別，只是協議？數據轉發有什麽區別？壹個數據包在不同網絡上的傳輸有什麽區別嗎？
用戶如何最快找到合適的服務器？如何快速有效的加載內容並在第壹時間展示？
這些問題的焦點在於幾個連接點:
3.2壹秒鐘規則
根據以上情況，形成了無線網絡的壹大特點:二級狀態管理和二級狀態轉移。這兩個操作都需要幾百毫秒到幾秒鐘，這對於保持連接來說太短了，而對於從無連接到連接的轉換來說又太長了。
相比之下，有線網絡的狀態管理，如ip分配、tcp連接釋放都是分鐘級的，而狀態轉移是毫秒級的。
這些通信機制，加上無線網絡的高延遲和高丟包。如何保證移動互聯網產品穩定、可預測的服務質量，成為壹個巨大的挑戰；
無線數據傳輸在2G網絡上的時延是幾百ms，而在4G網絡上的時延降低到幾十ms，核心網的狀態轉換和協議轉換是30 ~ 100 ms，在IP骨幹網上的時延與物理距離和運營商的互聯質量有關，跨運營商是50-400ms，同壹運營商是5-80ms，視網絡擁塞情況而定。
無線網絡的誤碼率比有線網絡高兩個數量級，不同時間段的波動也非常巨大。
如何根據移動網絡的特點優化服務？
這就是我們總結的壹秒規則:壹秒內要完成的規定動作。
1，2g網絡:1秒內完成dns查詢並與後臺服務器建立連接。
2、3g網絡:1秒內顯示首字(首字時間)
3、wifi網絡:首屏顯示在1秒(首屏時間)內完成。
4.這些指標需要在終端進行測量，必須與用戶體驗相關:首字時間和首屏時間必須讓用戶直觀感受到。
第四，優化思路
4.1服務保障原則
從上面的分析可以看出，保證移動互聯網產品穩定可預測的服務質量是壹個很大的挑戰。以下原則可能會有所幫助:
1)，界面設計優化，界面優化理論上不屬於APP弱網的優化，但是在網絡條件不好的情況下這個API性能問題才真正暴露出來。大家都在說服務器的質量，設備的性能。其實對於壹個好的服務器來說，延遲請求速度的地方大多在IO上。包括，磁盤讀寫的IO，SQL查詢的IO等等。常見的優化點:慢速查詢監控、多重查詢優化、通用接口緩存等。
2)形象相關策略。
1)使用更快的圖片格式嚴格來說不是弱網下的優化，但是更快的圖片格式真的很重要！這裏推薦WebP格式。(WebP格式，google為加快圖片加載速度而開發的圖片格式。圖像壓縮量只有JPEG的2/3左右，可以節省大量的服務器帶寬資源和數據空間。但是WebP是有損壓縮。與編碼JPEG文件相比，編碼相同質量的WebP文件需要更多的計算資源。)
2)不同的圖片分布在不同的網絡上。如(針對原圖為600X480): 2/3G使用低清晰度圖片->；分發精度為80的300X240圖片和普通清晰度的4G圖片->；發送600X480圖片，精度80，wifi高清圖片(最好根據網速判斷，WiFi也慢)->發送600X480圖片，精度100。
3)斷開並重新連接。這可能是最重要的特點，因為無線網絡中數據連接中斷的原因太多了。這裏可以用CDN。(CDN是建立在數據網絡上的分布式內容分發網絡。CDN的作用是采用流媒體服務器集群技術，克服單機系統輸出帶寬和並發性不足的缺點，可以大大增加系統支持的並發流數量，減少或避免單點故障帶來的不利影響。)
4)因為創建連接是壹個開銷非常大的操作，所以應該盡可能減少數據連接創建的次數，並且盡可能在壹個請求中批量執行任務。如果多次發送小數據包，應盡量保證在2秒內發送。短時間內訪問不同服務器時，盡可能多路復用無線連接。
5)、優化DNS查詢。應盡量減少DNS查詢，避免域名劫持和DNS汙染，將用戶調度到“最佳接入點”。
6)減小分組大小並優化分組容量。通過壓縮、精簡分組報頭和合並消息，分組的大小和容量被減小。
7)控制數據包大小不超過1500，避免碎片。包括邏輯鏈路控制分段、GGSN分段和IP分段。其中，當數據包大小超過GGSN允許的最大值時，GGSN可以通過以下三種方式進行處理:切片、丟棄和拒絕。
8)優化TCP套接字參數，包括是否關閉快速回收、初始r to、初始擁塞窗口、套接字緩沖區大小、Delay-ACK、Selective-ACK、TCP_CORK、擁塞算法(韋斯特伍德/TLP/立方)等。這樣做的意義在於2G/3G/4G/WIFI/ intranet等接入網的QoS差別很大，所以為了在不同的網絡下獲得更好的服務質量，上述參數的取值可能會有很大的不同。
9)優化ACK包。在網絡較弱的情況下，TCP協議中的ACK包非常昂貴，延遲甚至可以達到秒級。TCP協議的特性，如擁塞控制、快速重傳和快速恢復，很大程度上依賴於接收方反饋的ACK包。可想而知，如果發送方收到的ACK包延時過長，會嚴重影響TCP協議的效率。但是，如果發送太多的ack，就會占用太多寶貴的無線資源。在移動網絡通信中，“如何在可靠連接上減少ack包的同時減少數據包的延遲”是壹個熱門的研究課題。基本思想:平衡冗余包和ACK包的數量，減少延遲，提高吞吐量。例如，SGSN和GGSN之間的通信是這樣實現的:它們通過UDP協議進行通信，發送方在沒有新數據包的情況下，每隔壹段時間重試壹次已發送的數據包，達到最大重試次數後丟棄該數據包。
10)，TCP的擁塞控制算法是在“丟包就意味著網絡擁塞”的假設下設計的，這在無線網絡環境下顯然是不合適的。但是在無線網絡環境下，在設計可靠的UDP協議時，是否可以完全放棄擁塞控制？其他文章裏有幾個無線網絡環境下TCP友好的擁塞控制算法，有興趣可以自己去查閱。
11)，靈活使用長連接/短連接，支持不同協議(TCP/UDP、http、二進制協議等)。)，支持不同端口等。
12)，讓用戶感覺很快。到目前為止，它已經不再是壹種技術手段，而是壹種心理博弈，壹種提升用戶體驗的方式。例如:
1)，壹個非零進度條。無論網頁如何加載，無論網絡條件如何，加載進度總是從50%開始，壹直保持在98%左右。
2)首先顯示文字，加載圖片。同樣在Webview中，圖片或者多媒體的加載速度肯定比文字慢很多。因為不同的WebView有不同的顯示和渲染效果，所以我們可以讓WebView先顯示文字，再顯示圖片。給用戶壹種可以先預覽整個網頁的感覺。
4.2訪問調度優化
接入調度優化首先考慮的是降低DNS的影響。移動網絡的DNS具有以下特點:
1)骨幹網無法識別移動用戶在哪個城市，東、西、北、南所有地方的調度都沒有完全調用。目前，全國DNS的壹部分承載了全網40%以上的用戶。
2)很多山寨手機本地dns設置錯誤。
3)另外，有線網絡也會遇到壹些問題，比如濫用終端DNS解析、域名劫持、DNS汙染、老化、脆弱等。但是對於這些問題，桌面的自愈會更好，但是在手機上解決起來比較困難。
有兩種解決DNS問題的主要方法:
1)，減少DNS請求、查詢和更新，也就是做DNS緩存。
2)、在終端配置服務器列表，不需要DNS直接訪問IP。
但這還不夠，因為用戶可能來自國內外不同的運營商，調度策略需要進壹步優化:
1)，DNS緩存需要建立更多的接入點，並用不同的域名進行區分。
2)、需要更新IP列表以適應不同的網絡情況，並實現主動調度。比如最早我們只服務好移動用戶，首先保證移動用戶的訪問質量，因為絕大多數用戶集中在移動；目前國內有三家運營商，用戶比例慢慢接近，需要區分清楚；智能手機會用wifi，哪家運營商接入電信，聯通與否，我不知道，所以妳不能事先設置好場景然後如果然後，妳必須通過後臺調度能力來解決。
進壹步的優化將產生壹種整合方式:
1)，先做域名解析，客戶端可以直接連接解析後的IP，可以使用http協議，也可以使用tcp socket。
2)、多端口、多協議組合:不同的協議有不同的限制，有的只能是http，有的只能是tcp socket，所有的環境都要適配，客戶端不能只支持壹種協議。
3)終端測速:接入點越來越多。哪個適合接入？要選，可以通過終端測速選最快的。當然，妳可以在每次建立新連接時進行測速，但建立連接可能需要很長時間；我們可以在為用戶建立連接後，根據長期測速和當前測速的結果，在後臺進行動態調度。換句話說，第壹次連接可能不是最優的，連接建立後動態測量速度，然後傳輸到最快的接入點。再進壹步，就是建立網絡概要和終端學習的思路。
關於測速采樣的粒度，移動互聯網拿IP段沒用，更好的粒度在網元層面。比如廣東的wap網關有20多個，每個網關的情況不壹樣，是壹個比較合適的粒度。
最後強調壹下所有訪問調度的壹個原則:調度邏輯不要寫給客戶端，必須由後臺完成。
4.3協議優化
簡單列舉了協議參數的優化，是在長期運行過程中總結的壹些經驗。在啟動移動互聯網服務時，作為運營規範，可以避免很多彎路:
1，關閉TCP快速恢復。
2、Init RTO不小於3秒。
3.初始擁塞控制窗口不小於10。因為大部分頁面都在10kB以下，所以很多請求都在慢啟動階段就結束了。改成10可以減少小頁面資源的傳輸延遲。內容越大，這個選項的效果越不明顯。
4、套接字緩沖區& gt64k
5、TCP滑動窗口是可變的
6.將數據包大小控制在1400字節以下，以避免碎片。
協議優化的原則總結如下:
1，連接重用
2、並發連接控制
3、超時控制
4、包頭流線型
5、內容壓縮
6.選擇更有效的協議。無論是TCP、HTTP、UDP、長連接、GZIP、SPDY、WUP還是WebP，每壹種協議和方案都有它的道理，不存在優化的問題。只是是否適合妳的產品和服務的特點，需要在運營過程中進行驗證和選擇。
4.4 WAP接入點優化
關於WAP接入點優化，可能有人會說我們的App是高端大氣的應用，不需要做WAP優化？事實上，我們的統計顯示，目前有5%-20%的用戶選擇* *WAP(CMWAP、3GWAP、CTWAP)，其中甚至包括部分iPhone終端。其實WAP網關本質上是壹個代理，並不是完全落後。它也隨著技術的進步而發展。未來在組網架構上可能會有綜合網關和內容計費網關取代目前的WAP網關，建議壹並考慮。以下是做WAP優化時需要註意的壹些問題:
1，資費提醒頁面
2302跳轉處理
3、X-Online-主機的使用和處理
4.數據包大小限制
5、劫持和緩存
6、正確獲取資源包的大小
4.5業務邏輯優化
1，簡化邏輯:交互復雜的內容盡量用logo更新。比如我們在舊版手機QQ上做過壹個測試:如果我有100個好友，用手機QQ登錄，更新好友列表，需要3.5分鐘。這肯定是不合理的。建議用信令狀態通知是否需要更新，合理使用緩存。現在，比如妳玩遊戲，妳的朋友會送妳很多星星。妳希望用戶壹次訂購還是批量訂購？從優化的角度來說，肯定是批點，從用戶體驗的角度來說更舒服。
另壹方面，延長域名圖標的緩存時間也能有效優化訪問量。我們把手機騰訊圖標的緩存時間從120分鐘延長到兩天後，訪問量優化了差不多35%。
2、靈活可用:這是指網絡質量好的時候，給高清大圖，不好的時候，先給用戶看小圖，再點拉原圖。舉個極端的例子，比如地震時，基站被破壞20%，用戶想給家人報平安。這時候必須優化產品，比如只發文字，合理減3，減少網絡消耗。另外，在響應慢的時候，需要給用戶壹些合理的頁面提示，比如提醒用戶再過5秒就發了，不要壹直刷屏，這樣也可以減少訪問對後臺服務和網絡的影響。
說了這麽多，下面舉個例子幫助妳更直觀的理解。
這裏給出了壹個DNS系統的設計來實現最優調度。其拓撲結構如下:
TGCP SDK的職責:
1，通過HTTP Get/Post方法從DNSvr獲取服務器和DNSvr本身的最佳接入點列表。Get/Post方法的查詢參數包括uin/openid、客戶端版本號、IP列表的MD5(註意IP順序)、域名列表、VIP、ServiceID等。
2.緩存接入服務器和DNSvr的IP列表，以及其他元數據(如IP列表等。)，以APN為主鍵。
3.在某些情況下，您應該主動更新緩存的IP列表，例如緩存過期。
Tconnd的職責:
1，路由查詢請求到主動DNSvr；
DNSvr的職責:
1，根據靜態和動態策略確定客戶端的“最佳接入點”。靜態策略:根據uin/openid、客戶端版本號或強制規則確定IP列表；動態策略:燈塔根據測速數據動態確定用戶的服務器接入點。
2.支持手動或自動攻擊壹些IP。自動模式:服務器的access tconnd向DNSvr上報是否存活(需要上報多個點，包括公有IP)。如果在壹定時間內沒有收到報告，或者在報告消息中明確所有邏輯服務器都已掛起，則相應的IP將自動被封鎖。如果服務恢復，相應的IP會自動激活。如果項目組訪問TGW，對於某個IP和端口是否可用，需要考慮進程和VIP的映射關系。
3.將lighthouse的計算結果緩存在tcaplus中。此時需要DNSvr根據客戶端IP(可以通過訪問MIG的IP庫來實現)判斷國家、省份、運營商、網關。如果燈塔的計算結果被緩存，那麽在緩存超時後，應該再次從燈塔中拉出相應的數據。
燈塔的責任:
1，根據客戶端IP和服務器接入點IP，返回最優接入點列表，包括IP的順序，以及客戶端接入的國家、省份、運營商、APN、網關。
Tcaplus的職責:
1，保存訪問的IP列表和端口，靜態策略，或者緩存燈塔的計算結果；
主要流程:
客戶端批量域名解析流程
1，TGCP使用APN和域名列表作為關鍵字查詢緩存。如果存在且未過期，則直接將IP返還給用戶。如果指定強制解析域名列表，請跳過此步驟；
2.TGCP使用預先配置或緩存的IP向DNSvr發送查詢請求。如果結果返回成功，請繼續執行步驟3。否則，重試IP列表中的其他IP。如果都失敗，用域名訪問DNSvr。註意:如果結果格式不正確，用最後壹個IP再試壹次，不改變IP再試壹次。
3.DNS VR將客戶端的IP列表的MD5與最新的IP列表進行比較，如果相等，則告訴客戶端不需要更新本地緩存。否則，TGCP會在本地寫入訪問服務器和DNSvr的IP列表。註意:當訪問服務器時，這些IP的優先級高於客戶端上靜態配置的IP。
使用域名的客戶端訪問服務器進程
1，如果本地有壹個有效的IP(即有壹個對應APN的IP列表並且不是無效的)，那麽使用IP訪問服務器。
2.否則，在發起“客戶端批量域名解析流程”後，再次訪問服務器。
服務器訪問tconnd計劃報告狀態流程:
1，Tconnd定期向DNSvr報告心跳消息，該消息包含該接入點是否可用的信息。
2.如果2、DNSvr在壹定時間內沒有收到心跳消息或者對應的接入點不可用，對應的IP和端口會被黑掉，黑掉的IP不會發送到客戶端。
註意:在實際部署過程中，被訪問的tconnd應該報告給多個DNSvr訪問Tconnd。
主動向客戶端推送接入點列表的過程
1，當TGCP連接到服務器訪問的Tconnd時，Tconnd要向DNSvr發出請求，檢查當前訪問的IP的質量和及時性。如果IP列表發生變化，Tconnd會將最新的IP列表發送到客戶端進行緩存。
2.當TGCP下次訪問服務器時，它將使用最新的IP列表。
客戶端訪問DNSvr的過程失敗。
1，如果訪問DNSvr失敗(包括IP+域名)，如果配置了本地IP，直接用IP訪問服務器，否則用域名訪問。
優化傳輸層協議的設計
在原有tconnd支持的可靠UDP的基礎上，增加以下邏輯:
1，數據壓縮；
2、數據加密；
3、合並多個數據包；
4.支持流式數據傳輸，便於控制每個UDP包的大小，便於數據加密壓縮；
5、可選支持改進的擁塞控制算法；
6.即使沒有收到ACK包，也需要主動重試發送數據包；
5.2 hybrid開發下的壹些優化
要應對弱網絡下的加載速度，首先要確定我們整個APP加載到哪裏，最長的加載路徑在哪裏，這樣才能有針對性的優化修改。
5.2.1網絡視圖
如果是內嵌在APP中的webview頁面，優化web體驗已經很久了。我們可以使用Chrome的開發者模式，調整到網絡模式，將網絡條件設置為3G來請求網頁，然後就可以看到壹個網頁的加載速度主要花在了哪裏，如下圖所示:
當然，有很多方法可以提高html的速度。
1，使用gulpgrunt進行打包壓縮:jscss資源壓縮，CSS Sprites合並等。
2、用字體-牛逼代替圖片:字體可以很兼容，無限放大，常用圖片都有。