APP端的網路最佳化（DNS最佳化，HTTP最佳化）

標籤：post   優秀   序列化   比較   轉換   java   伺服器   nbsp   google   

一、使用httpDNS最佳化DNS解析和緩衝

　　一般來說在App內用網域名稱發送請求都要經過DNS解析出ip，然後再根據ip去拿對應的資源，這個過程中，如果LocalDNS中存在這個網域名稱對應的ip，就會直接返回這個ip，類似於App內做緩衝。如果不存在，才會去權威DNS查詢改訪問哪個ip，然後查詢到的ip會在LocalDNS中做緩衝。也就是說，如果我們要訪問新浪http://api.weibo.cn，如果LocalDNS裡面有該網域名稱對應的ip，就直接返回了ip了。（DNS基礎知識：http://www.jianshu.com/p/a73e963b63b1）

 

　　1、這裡存在兩個問題

　　　　如果之前訪問api.weibo.cn的是聯通使用者，現在新使用者使用電信來訪問api.weibo.cn，由於localDNS緩衝的存在，不會去查詢新浪的權威DNS，這樣返回的ip是聯通這個電訊廠商的ip，從而會使得使用者出現訪問變慢等狀況。緩衝還會導致一點就是，當權威DNS將網域名稱與ip的映射發生改變之後，由於LocalDNS緩衝沒有及時改變，使用者就會訪問到錯誤的伺服器，或者直接存取不到資源。

　　　　很多三四級電訊廠商會把運營解析指向他們的快取服務器上，並把網頁裡面的廣告替換成他們自己的，或者內嵌他們自己的廣告。（之前做的APP出現過這樣的情況，投訴之後會好上一段時間，但是過段時間又會出現廣告）。

 

　　　　竟然DNS解析存在問題，那有沒有一種調度精準、成本低廉、配置方便的基於網域名稱的流量調度系統呢？答案是肯定的。HttpDNS基於Http協議和網域名稱解析的流量調度解決方案，可以在很大程度上防止上面的問題出現。

　　HttpDNS原理：

　　　　A、用戶端直接存取HttpDNS介面，擷取業務在網域名稱組態管理系統上配置的訪問延遲最優的IP。（基於容災考慮，app內肯定是需要保留使用電訊廠商LocalDNS解析網域名稱方式的。）

　　　　B、用戶端向擷取到的IP後就向直接往此IP發送業務協議請求。以Http請求為例，通過在header中指定host欄位，向HttpDNS返回的IP發送標準的Http請求即可。

　　總的來說，採用HttpDNS來解析網域名稱，就繞過了三四級電訊廠商解析網域名稱會出現的問題，在HttpDNS返回了正確的ip之後，我們是直接採用ip去進行http請求，只需要關注通訊內容的安全即可。

 

　　2、基於HttpDNS擴充

　　　　A、在App內維護一個Serve IP List。把每次App從HttpDNS取到的ip儲存進入該數組，並設定權重，理論上來說從HttpDns解析下來的ip權重是最大的。這個List可以在App啟動的時候，進行更新，同時取出本機快取的Serve IP List的權重最大的ip進行資料的初始化操作（如果第一次啟動，沒有該List的話，就使用LocalDNS進行解析）。

　　　　　　Serve IP List裡面的權重設定機制，很明顯的一點就是從DNS解析出來的ip具有最大的權重，每次從List裡面取ip應該要取權重最大的ip。列表中的ip也是需要可以動態更新配置的，根據串連或者服務的成功失敗來進行動態調整，這樣即使DNS解析失敗，使用者在一段時間後也會取到合適的ip進行訪問。

　　　　B、對ip進行資料統計。在所有app內統計每個ip進行請求所需平均時間、最長時間、最短時間、請求成功次數、失敗次數，需要注意的是，要區分網路環境進行統計，Wifi、4G、3G，對在不同的網路環境下資料優秀的ip進行儲存，下發到App裡面使用起來。這樣每次啟動App時可以對收集起來的ip根據不同的網路環境進行測速，選擇最好的ip進行請求。需要注意的是，在網路環境切換的時候，必須要重新進行速度測試。做到這一步，可以節約DNS解析時間，以及劫持的問題。

 

　　　　C、將圖片、音頻等資源放到單獨的伺服器裡面，與其他資源分開。

　　　　　　第一個是多個網域名稱可以增加並行下載條數，因為用戶端對同一個域的網域名稱下載條數是有限制的，所以多個域就會增加並行下載條數，從而加快載入速度。當然次層網域也不能使用太多，因為太多要考慮到dns的解析花費的時間。
　　　　　　第二個是方便管理，一般來說，圖片在網站的載入中是最占頻寬的，可以用獨立伺服器方便後期管理；還可以使用非同步載入的方式，增強使用者體驗。同時是圖片多是靜態內容，可以更好的使用CDN加速。
　　　　　　第三是如果使用了獨立伺服器的話，在安全設定上可以有差別的針對設定，很是方便。

　　　　D、在防止劫持這一塊，需要注意把資源的尾碼名去掉，比如說.mp3\.json這樣的尾碼，以免擊中電訊廠商的攔截。

 

二、資源最佳化

　　資源最佳化基本就是儘可能的縮小傳輸資料的大小，首先是圖片大小的解決方案。

　　　　1、在一定程度上使用webp來代替jpg、png圖片

　　　　　　　　　　

　　　　就是各種圖片同等品質下的大小，其中webp是最小的。當我們下載圖片展示的時候，如果在一定程度上使用webp圖片，就能大大減少使用者流量的損失，以及下載圖片的所需時間。

　　　　一般來說，會在App內固定使用幾種尺寸來做展示圖，比如說，banner圖是640*640，cell展示圖可能是320*320、280*280，類似頭像的可能是80*80等。需要注意的是，webp的圖片要通過解析才能成為可用的jpg圖片，在iOS開發中，可以使用SDWebImage架構進行解析，webp->NSData->Image，app內解析是肯定需要花費一定時間和效能的。

　　　　根據實際使用的反饋情況，發現在wifi條件下，超過300*300的圖片使用webp圖片，解析時間+下載時間是比直接使用jpg\png圖片要快的，並且在流量方面也是消耗很小。低於300*300的可以直接下載使用jpg\png圖片。

　　　　在4G條件下，使用者可能會對流量比較敏感，建議都走webp圖片。

 

　　　　2、可以使用ProtocolBuffer代替Json進行資料轉送

　　　　Protocolbuffer(簡稱Protobuf或PB)是由Google推出的一種資料交換格式，它獨立於語言，獨立於平台。Google 提供了三種語言的實現：java、c++ 和 python，每一種實現都包含了相應語言的編譯器以及庫檔案。可以把它用於分布式應用之間的資料通訊或者異構環境下的資料交換。與傳統的XML和JSON不同的是，它是一種二進位格式，免去了文字格式設定轉換的各種困擾，並且轉換效率非常快，由於它的跨平台、跨程式設計語言的特點，讓它越來越普及，尤其是網路資料交換方面日趨成為一種主流。

　　　　在tcp中，我們可以使用 ProtocolBuffer代替Json進行資料轉送，因為ProtocolBuffer資料比Json更小，也是跨平台的，序號與還原序列化也很簡單。在實際項目中，當資料變小的時候會顯著提高傳輸速度。

APP端的網路最佳化（DNS最佳化，HTTP最佳化）