當我們開始關注 App 的使用者體驗後，網路通暢性和介面的流暢性是保證 App 好用的重要指標。近期對專案中的網路資料進行了簡單的分析，又對業界的一些方案做了調研，故寫此文做一下知識梳理。
當我們使用 App 的 時候，如經常遇到載入失敗或者小圈轉個不停的情況，那麼很可能 App 的網路效能出現了問題，急需研發同學來進行優化。而對於開發人員來說，定位網路問題又是十分艱難，因為出現網路問題的使用者往往遙在天邊，你沒辦法進行除錯定位。那麼建立完善的網路監控體系就顯得十分重要，通過海量資料的分析來對網路問題精確定位。
通過對資料的分析以及調研、使用者反饋，發現移動端網路常常存在如下的問題：
- 網路成功率低，經常請求失敗
- 使用者反饋 DNS 劫持，資料被篡改，出現廣告和請求超時等情況
- 網路延遲較長，且存在較多的長尾資料
- 經過資料分析，發現長連的時間明顯比短連的時間少 100ms 左右（短連指的是，經過DNS解析、 TCP 握手、 SSL 握手等一系列的過程建立連線，長連指的是直接複用前者的連線通道）
- 網路經常出現抖動，本來大部分請求都是 100ms 左右，突然冒出來一兩千毫秒的，甚至有10、20秒的延遲情況
HTTP 1.1的head of blocking情況存在，一個網路抖動，很容易影響後續的請求，導致一連串的延遲較高請求（head of blocking：指的是在 HTTP 1.1 中，如果你發出1、2、3 三個網路請求，那麼Response的順序 2、3 要在第一個網路請求之後）- 傳輸的
Payload太大，延遲高，易超時 - 蘋果要求
HTTPS，此時加入的SSL握手較耗時
針對上面一系列的問題，業界已經有很多解決方案，我在這裡簡單列舉一些
面對這樣的網路，如何解決？
對於 DNS 劫持的情況，業界的主要做法是 HTTPDNS 或者內建 Server IP 列表。客戶端直接訪問 HttpDNS 介面，獲取業務在域名配置管理系統上配置的訪問延遲最優的IP，獲取到IP後就直接往此IP傳送業務協議請求，不需要使用本地運營商解析域名，所以從根本避免了劫持問題，同時可以降低網路延遲，提高連線成功率。而建立 Server IP 列表，是在本地快取一個 IP 的對映表，此表可在App啟動時動態下發更新，訪問伺服器時直接拿出 IP 發出請求。
傳輸的 Payload 也直接影響了延遲，並且對成功率有影響，對於資料的壓縮，業界很多公司已經開始使用 ProtoBuf 協議，對於優化的百分比我還沒有準確的說資料結論，但是從大家的反饋來說，優化效果明顯。對於資料的壓縮，還可以考慮接入 HTTP 2.0，畢竟這是一個趨勢，也有較多公司已經加入 HTTP 2.0，HTTP 2.0 通過頭部壓縮等方式也幫你減小了傳輸的 Payload。
上面的問題其實很多是涉及到長連與短連的問題，對這個問題有較多的問題可以考慮
- 域名合併：淘寶、美團等公司公佈的方案中都有提到，就是將公司原來很多域名的情況，合併為較少的幾個域名，為什麼這麼做呢？HTTP 的通道複用是基於域名劃分的，如果域名只有幾個，那麼多數請求都可以在長連線通道進行，這樣就可以降低延遲、增加成功率。
- 儘早建立長連線，這樣其他的業務請求就可以複用長連線通道，加快訪問速度。對於建立連線的時機，可以考慮多個方面，比如冷啟動，前後臺切換、網路切換等
- 考慮接入
HTTP2.0，他們兩個都解決了HTTP 1.1的head of blocking，降低了網路延遲，提供了更強大的多路複用技術，還加入了流量控制、新的二進位制格式、Server Push、請求優先順序和依賴等特性。或者接入 SPDY ，但是目前覺得好像直接上 HTTP 2.0 比較合適 - 建立多通道，比如攜程、美團等公司都有自己
TCP、UDP通道，具有多域名共用通道，成功率三個九等誘人的功效。同時各大廠也對新的網路協議，比如QUIC，進行嘗試。Facebook還出一分享，對QUIC改進，實現TLS的0-RTT
再者還有一些其他可以考慮的點
- 加入 CDN 加速，動靜資源分離
- 對於埋點的資料，也可以合併請求，減少流量
- App 網路診斷
- 根據網路情況，動態設定超時時間等