APP端的網絡優化(DNS優化,HTTP優化)

1、使用httpDNS優化DNS解析和緩存java

  通常來講在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/a73e963b63b1python

 

  一、這裏存在兩個問題c++

    若是以前訪問api.weibo.cn的是聯通用戶,如今新用戶使用電信來訪問api.weibo.cn,因爲localDNS緩存的存在,不會去查詢新浪的權威DNS,這樣返回的ip是聯通這個運營商的ip,從而會使得用戶出現訪問變慢等情況。緩存還會致使一點就是,當權威DNS將域名與ip的映射發生改變以後,因爲LocalDNS緩存沒有及時改變,用戶就會訪問到錯誤的服務器,或者直接訪問不到資源。web

    不少三四級運營商會把運營解析指向他們的緩存服務器上,並把網頁裏面的廣告替換成他們本身的,或者內嵌他們本身的廣告。(以前作的APP出現過這樣的狀況,投訴以後會好上一段時間,可是過段時間又會出現廣告)。編程

 

    居然DNS解析存在問題,那有沒有一種調度精準、成本低廉、配置方便的基於域名的流量調度系統呢?答案是確定的。HttpDNS基於Http協議和域名解析的流量調度解決方案,能夠在很大程度上防止上面的問題出現。json

  HttpDNS原理:api

    A、客戶端直接訪問HttpDNS接口,獲取業務在域名配置管理系統上配置的訪問延遲最優的IP。(基於容災考慮,app內確定是須要保留使用運營商LocalDNS解析域名方式的。)數組

    B、客戶端向獲取到的IP後就向直接往此IP發送業務協議請求。以Http請求爲例,經過在header中指定host字段,向HttpDNS返回的IP發送標準的Http請求便可。緩存

  總的來講,採用HttpDNS來解析域名,就繞過了三四級運營商解析域名會出現的問題,在HttpDNS返回了正確的ip以後,咱們是直接採用ip去進行http請求,只須要關注通訊內容的安全便可。安全

 

  二、基於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這樣的後綴,以避免擊中運營商的攔截。

 

2、資源優化

  資源優化基本就是儘量的縮小傳輸數據的大小,首先是圖片大小的解決方案。

    一、在必定程度上使用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圖片。

 

    二、可使用ProtocolBuffer代替Json進行數據傳輸

    Protocolbuffer(簡稱Protobuf或PB)是由Google推出的一種數據交換格式,它獨立於語言,獨立於平臺。Google 提供了三種語言的實現:java、c++ 和 python,每一種實現都包含了相應語言的編譯器以及庫文件。能夠把它用於分佈式應用之間的數據通訊或者異構環境下的數據交換。與傳統的XML和JSON不一樣的是,它是一種二進制格式,免去了文本格式轉換的各類困擾,而且轉換效率很是快,因爲它的跨平臺、跨編程語言的特色,讓它愈來愈普及,尤爲是網絡數據交換方面日趨成爲一種主流。

    在tcp中,咱們可使用 ProtocolBuffer代替Json進行數據傳輸,由於ProtocolBuffer數據比Json更小,也是跨平臺的,序列號與反序列化也很簡單。在實際項目中,當數據變小的時候會顯著提升傳輸速度。

相關文章
相關標籤/搜索