一個網絡請求可以簡單分爲連接服務器 -> 獲取數據兩個部分。
其中連接服務器前還包括 DNS 解析的過程；獲取數據後可能會對數據進行緩存。
一、連接服務器優化策略
1. 不用域名，用 IP 直連
省去 DNS 解析過程，DNS 全名 Domain Name System，解析意指根據域名得到其對應的 IP 地址。 如http://www.codekk.com 的域名解析結果就是 104.236.147.76。
首次域名解析一般需要幾百毫秒，可通過直接向 IP 而非域名請求，節省掉這部分時間，同時可以預防域名劫持等帶來的風險。
當然爲了安全和擴展考慮，這個 IP 可能是一個動態更新的 IP 列表，並在 IP 不可用情況下通過域名訪問。
2. 服務器合理部署
服務器多運營商多地部署，一般至少含三大運營商、南中北三地部署。
配合上面說到的動態 IP 列表，支持優先級，每次根據地域、網絡類型等選擇最優的服務器 IP 進行連接。
對於服務器端還可以調優服務器的 TCP 擁塞窗口大小、重傳超時時間(RTO)、最大傳輸單元(MTU)等。
二、獲取數據優化策略
1. 連接複用
節省連接建立時間，如開啓 keep-alive。
Http 1.1 默認啓動了 keep-alive。對於 Android 來說默認情況下 HttpURLConnection 和 HttpClient 都開啓了 keep-alive。只是 2.2 之前 HttpURLConnection 存在影響連接池的 Bug，具體可見：Android HttpURLConnection 及 HttpClient 選擇
2. 請求合併
即將多個請求合併爲一個進行請求，比較常見的就是網頁中的 CSS Image Sprites。 如果某個頁面內請求過多，也可以考慮做一定的請求合併。
3. 減小請求數據大小
(1) 對於 POST 請求，Body 可以做 Gzip 壓縮，如日誌。
(2) 對請求頭進行壓縮
這個 Http 1.1 不支持，SPDY 及 Http 2.0 支持。 Http 1.1 可以通過服務端對前一個請求的請求頭進行緩存，後面相同請求頭用 md5 之類的 id 來表示即可。
4. CDN 緩存靜態資源
緩存常見的圖片、JS、CSS 等靜態資源。
5. 減小返回數據大小
(1) 壓縮
一般 API 數據使用 Gzip 壓縮，下圖是之前測試的 Gzip 壓縮前後對比圖。 
(2) 精簡數據格式
如 JSON 代替 XML，WebP 代替其他圖片格式。關注公衆號 codekk，回覆 20 查看關於 WebP 的介紹。
(3) 對於不同的設備不同網絡返回不同的內容 如不同分辨率圖片大小。
(4) 增量更新
需要數據更新時，可考慮增量更新。如常見的服務端進行 bsdiff，客戶端進行 bspatch。
(5) 大文件下載
支持斷點續傳，並緩存 Http Resonse 的 ETag 標識，下次請求時帶上，從而確定是否數據改變過，未改變則直接返回 304。
6. 數據緩存
緩存獲取到的數據，在一定的有效時間內再次請求可以直接從緩存讀取數據。
關於 Http 緩存規則 Grumoon 在 Volley 源碼解析最後雜談中有詳細介紹。
三、其他優化手段
這類優化方式在性能優化系列總篇中已經有過完整介紹
1. 預取
包括預連接、預取數據。
2. 分優先級、延遲部分請求
將不重要的請求延遲，這樣既可以削峯減少併發、又可以和後面類似的請求做合併。
3. 多連接
對於較大文件，如大圖片、文件下載可考慮多連接。 需要控制請求的最大併發量，畢竟移動端網絡受限。
四、監控
優化需要通過數據對比才能看出效果，所以監控系統必不可少，通過前後端的數據監控確定調優效果。
