網絡模塊是 App 應用最基礎最核心的模塊， 穩定高效的網絡處理是良好用戶體驗的基本保障。 本文介紹日常開發中常用的網絡協議以及使用方法。
先看壹下網絡請求傳輸的過程：
核心步驟主要是以下幾步：
Http 協議分為 Request， Response 兩部分。 客戶端發起壹個 Request； 服務器處理後，返回壹個 Response。
看壹下 Request 的構成：
上半部分為請求頭， 下半部分為請求體。
第壹行描述請求的方式，請求的路徑， http 的協議版本。 之後每壹行描述壹個請求頭字段。 請求頭和請求體之間以兩個換行分割。
常用的請求頭字段：
響應碼： 請求是否成功根據響應碼判斷。 每種響應碼都對應各自的含義。詳細參考 wiki
常用的響應頭：
cookie 是隨著 Response 返回的鍵值對數據， 保存在本地。 下次再訪問同壹個域時， 將 Cookie 的 kvs 隨著 Request 帶到 Server。 後臺開發人員可以根據業務的需求設置對應的 Cookie。
對於 App 的場景來說， 使用 http 協議處理網絡請求是壹種最簡單， 但不是最高效的方式(個人觀點)
如上圖， Http 請求的耗時主要由四部分組成。 圍繞這四部分分析優化策略。
最快的請求是不發起請求。 不僅在協議層處理網絡的緩存， 還需要在業務層處理數據的緩存。 在不必要的情況下， 盡量不發起網絡請求， 直接使用緩存中的數據。
系統都有 Dns 解析的實現。 默認情況下直接調用系統 API 執行 Dns 查詢操作。
http 1.1 默認是設置 Connection:Keep-Alive。 就是表示請求完成後並不馬上關閉， 後續相同的請求通過鏈路的復用， 節省 tcp 鏈接建立的耗時。
在帶寬固定的情況下， 減少提交的數據包大小， 降低數據傳輸的耗時。
相對來說 json 和 urlEncode 的格式占用比較小。 formdata 比較大， 壹般是上傳文件時使用。
原理同上， 減小數據包的大小， 降低數據傳輸的耗時。
安全處理策略有兩個方面。 壹種是在使用上增加安全校驗， 壹種是在協議上使用安全協議，如 Https。
前後端交互常規做法的壹種。 對請求的參數的某些值連在壹塊， 再通過加鹽算 MD5 值生成壹個簽名。 將簽名值附加到請求參數中。 後端收到請求後同樣需要驗證這個簽名， 不壹致的話說明請求參數已經被篡改了， 不予通過。
稍微更嚴格壹點的方式是，對所有請求參數根據 key 值做自然排序， 再用上述方法算壹遍簽名。
這種方式主要是為了防止參數被篡改， 並不能防止被攔截。
使用 Https 能從協議上解決安全問題。全面升級到 Https 是目前業界的趨勢。 下圖是 Https 的處理過程簡圖：
Http 協議是壹種被動式的處理消息的方式。 app 很多場景下需要由服務器主動將數據推送到客戶端。 使用 WS 協議維持客戶端到服務器的長連接是壹種很好的解決方案。 目前在 IM 或直播的場景下應用b
比較廣泛。
上面兩張圖為 ws 協議請求和響應。
在看壹下 ws 協議下的每幀數據組成：
每幀數據都包含 2byte 的頭信息。
FIN 表示是否為最後壹幀
RSV1/2/3 為擴展字段。客戶端與服務器可以通過約定這幾個字段的值實現協議上的附加操作， 比如是否開啟數據壓縮。
OP Code 為每壹幀的操作類型。 比如當前幀是操作幀還是數據幀
MASK 0/1 表示是否設置了掩碼
LENGTH 為數據包長度
在 2byte 頭信息之後帶上整個幀的真實數據。
下壹代 http 協議。 解決了諸多 http 下的問題， 被越來越廣泛的應用。 我總結的也不太好， 詳細參見另壹篇博客 HTTP 2.0的那些事
App 的網絡場景要比 pc 上復雜很多， 也不穩定的多。 對於 app 來說， 理想的網絡模型特點應該要有：
在不同的場景下使用不同的工具去解決問題， 重點是要熟悉每種協議的特點，以及如何使用。
廣告： 基於 OkHttp 實現的網絡工具庫 BJNetwork