APP網絡優化篇

Android

Addresses are cached for 600 seconds (10 minutes) by default. Failed lookups are cached for 10 seconds.
DNS caching
In Android 4.0 (Ice Cream Sandwich) and earlier, DNS caching was performed both by InetAddress and by the C library, which meant that DNS TTLs could not be honored correctly. In later releases, caching is done solely by the C library and DNS TTLs are honored.

IOS

按照官方文檔說法，iOS設備上每24小時刷新一次DNS緩存

 

SP（電信運營商）緩存有些不靠譜，有些緩存服務器（很少）會忽略網站DNS提供的TTL，本身設置一個較長的TTL，致使頂級DNS更新時不能及時拿到新的IP地址。

能夠看出，在從Root DNS請求域名解析的過程當中，有太多的層次影響DNS的獲取，緩存是雙刃劍，提升了獲取DNS的速度，也會影響DNS在IP變動時不能及時更新到最新。

短鏈接  參考https://tech.meituan.com/SharkSDK.html

　1、 合併域名。

1. 域名獲得了收編，減小了DNS調用次數，下降了DNS劫持風險。
2. 針對同一域名，能夠利用Keep-Alive來複用Http的鏈接。
3. 客戶端業務層不須要修改代碼，後端業務服務也不須要進行任何修改。

　　

　2、 IP直連方案有下面幾大優點：

1. 摒棄了系統DNS，減小外界干擾，擺脫DNS劫持困擾。
2. 自建DNS更新時機能夠控制。
3. IP列表更換方便。

此外，若是你的App域名沒有通過合併，域名比較多，也建議能夠嘗試使用HttpDNS方案。參考：http://www.tuicool.com/articles/7nAJBb 對HTTPS中的證書處理：

 

其實在整個DNS鏈路上也是有DNS緩存的，理論上也是可以提升速度的。這個鏈路上的DNS緩存在PC用戶上效果明顯，由於PC用戶的DNS鏈路相對穩定，信號源不會變來變去。可是在移動設備的用戶這邊，鏈路上的DNS緩存所帶來的性能提高就不太明顯了。由於移動設備的實際使用場景比較複雜，網絡信號源會常常變換，信號源每變換一次，對應的DNS解析鏈路就會變換一次，那麼原鏈路上的DNS緩存就不起做用了。並且信號源變換的狀況特別特別頻繁，因此對於移動設備用戶來講，鏈路的DNS緩存咱們基本上能夠默認爲沒有。因此大部分時間是手機系統自帶的本地DNS緩存在起做用，可是通常來講，移動設備上網的需求也特別頻繁，專門爲咱們這個App所作的DNS緩存頗有可能會被別的DNS緩存給擠出去被清理掉，這種狀況是特別多的，用戶看一下子知乎刷一下微博查一下地圖逛一逛點評再聊個Q，回來以後頗有可能屬於你本身的App的本地DNS緩存就沒了。這還沒完，這裏還有一個只有在中國特點社會主義的互聯網環境中才會有的問題：國內的互聯網環境因爲GFW的存在，就使得DNS服務速度會比正常狀況慢很多。

基於以上三個緣由所致使的最終結果就是，API請求在DNS解析階段的耗時會不少。

那麼針對這個的優化方案就是，索性直接走IP請求，那不就繞過DNS服務的耗時了嘛。

 

若是你還不熟悉NSURLProtocol應該怎麼玩，看完官方文檔和這篇文章以及這個Demo以後，你確定就會了，其實很簡單的。另外，剛纔提到那篇文章的做者(mattt)還寫了這個基於NSURLProtocol的工具，至關好用，是能夠直接拿來集成到項目中的。

https://casatwy.com/iosying-yong-jia-gou-tan-wang-luo-ceng-she-ji-fang-an.html

 

3、創建連接自己是屬於比較消耗資源的操做，耗電耗時。SPDY自帶連接複用以及數據壓縮的功能，因此服務端支持SPDY的時候，App直接掛SPDY就能夠了。若是服務端不支持SPDY，也可使用PipeLine，蘋果原生自帶這個功能。

 

這是我看過，講述的最詳細的文章。

http://www.gameres.com/767209.html

 

針對窄帶寬、高時延、不穩定的移動網絡

參數調優

　　慢啓動閥值，窗口擴大，RTO調大（由於是高延時），針對性禁用快速回收，使用TCP_NODELAY選項，

對於移動APP，大部分網絡交互都是HTTP併發短連接小數據量傳輸的形式，若是服務器端有10KB的數據返回，採用過去的慢啓動機制時，效率會低一些，大概須要2~3個RTT才能完成數據傳輸，反應到用戶體驗層面就是慢，而把擁塞窗口cwnd初始值提高到10後，在大多數狀況下都能在1個RTT的週期內完成應用數據的傳輸，這在移動網絡這樣的高時延、不穩定、易丟包的場景下，顯得尤爲意義重大。

 

TCP窗口是用於在接收端和發送端之間動態反映接收端讀緩衝大小的變化，它的初始值就是讀緩衝區設定的值，單位是字節，這個數字在TCP包頭的16位窗口大小字段中傳遞，最大65535字節，若是嫌不夠大，在TCP選項中還有一個窗口擴大的選項可供選擇。

 

提高TCP吞吐量，最佳狀態是在流量控制機制的調控下，使得發送端老是能發送足夠的數據報文填滿發送端和接收端之間的邏輯管道和緩衝區。其中邏輯管道的容量有專門的學名叫BDP（BandwidthDelayProduct，帶寬時延乘積，BDP=鏈路帶寬*RTT），在一個高帶寬低時延的網絡中，TCP包頭中的16位窗口大小可能就不夠用了，須要用到TCP窗口縮放選項，在RFC1323中定義，有興趣能夠研究一下

 

 快速回收

（tcp_tw_recycle啓用時必須同時啓用本項，反之則否則，timestamps用於RTT計算，在TCP報文頭部的可選項中傳輸，包括兩個參數，分別爲發送方發送TCP報文時的時間戳和接收方收到TCP報文響應時的時間戳。Linux系統和移動設備上的Android、iOS都缺省開啓了此選項，建議不要隨意關閉）

 

接入調度