App網絡基礎知識概括

jxmu3532 8年前發布 | 10K 次閱讀服務器移動開發

前言

網絡模塊是 App 應用最基礎最核心的模塊，穩定高效的網絡處理是良好用戶體驗的基本保障。本文介紹日常開發中常用的網絡協議以及使用方法。

Http 協議

先看一下網絡請求傳輸的過程：

核心步驟主要是以下幾步：

DNS 解析，獲取服務器的 ip 地址列表
TCP/IP 鏈接到服務器
在 TCP/IP 上構建協議規則
服務器收到請求，通過通道返回響應
Client 收到響應后關閉通道

Http 協議分為 Request， Response 兩部分。客戶端發起一個 Request；服務器處理后，返回一個 Response。

Request

看一下 Request 的構成：

上半部分為請求頭，下半部分為請求體。

第一行描述請求的方式，請求的路徑， http 的協議版本。之后每一行描述一個請求頭字段。請求頭和請求體之間以兩個換行分割。

常用的請求頭字段：

Content-Type：表示請求內容的類型。一般 api 請求主要使用
application/json

application/x-www-form-urlencoded

multipart/form-data
Content-Length: 請求體大小。服務器根據這個值才能獲取完整的請求數據
User-Agent: 客戶端可以隨意設置的一個值，用來描述客戶端的信息
Connection: 鏈接類型。上圖中 Keep-Alive 表示服務器收到請求號保持鏈接不要關閉。
Accept-Encoding: gzip 表示當前客戶端接受 gzip 編碼的響應內容

Response

Response 同樣分為頭和體兩部分。

響應碼：請求是否成功根據響應碼判斷。每種響應碼都對應各自的含義。詳細參考 wiki

常用的響應頭：

Connection: keep-alive. 表示響應未關閉，客戶端實現上同樣需要保持鏈接未關閉
Cache-Control: 協議的緩存策略
Content-Encoding: gzip 表示當前返回的內容采用的 gzip 編碼。解析數據時使用 gzip 解碼
Content-Type：返回數據的內容格式

Cookie

cookie 是隨著 Response 返回的鍵值對數據，保存在本地。下次再訪問同一個域時，將 Cookie 的 kvs 隨著 Request 帶到 Server。后臺開發人員可以根據業務的需求設置對應的 Cookie。

Http 的問題

對于 App 的場景來說，使用 http 協議處理網絡請求是一種最簡單，但不是最高效的方式(個人觀點)

最大的問題，延遲。 App 的請求都很分散，大部分發起的請求都需要重新構建整個鏈接，延遲問題很嚴重。
無效數據重復提交。每次請求都會將同樣的 headers 提交到服務器。
單向數據通道。服務器屬于被動響應模式，無法做到主動推送數據。

Http 優化策略

Http耗時

如上圖， Http 請求的耗時主要由四部分組成。圍繞這四部分分析優化策略。

1. Cache

最快的請求是不發起請求。不僅在協議層處理網絡的緩存，還需要在業務層處理數據的緩存。在不必要的情況下，盡量不發起網絡請求，直接使用緩存中的數據。

2. DNS

系統都有 Dns 解析的實現。默認情況下直接調用系統 API 執行 Dns 查詢操作。

Dns 優化策略一

實現 Dns 二級緩存。當執行請求時，需要調用 Dns 查詢。將 ips 結果緩存起來，下次再請求同樣的域名時，直接從緩存內取出結果，而不需要再次調用系統查詢

3. 鏈接復用

http 1.1 默認是設置 Connection:Keep-Alive。就是表示請求完成后并不馬上關閉，后續相同的請求通過鏈路的復用，節省 tcp 鏈接建立的耗時。

4. 請求

在帶寬固定的情況下，減少提交的數據包大小，降低數據傳輸的耗時。

策略一
選擇合理的數據提交方式。一般常用的 post 數據提交格式有
JSON Content-Type: application/json
UrlEncode Content-Type:application/x-www-form-urlencoded
formdata Content-Type:application/form-data

相對來說 json 和 urlEncode 的格式占用比較小。 formdata 比較大，一般是上傳文件時使用。

策略二

對提交的內容進行壓縮。同時設置 Content-Encoding。

5. 響應

原理同上，減小數據包的大小，降低數據傳輸的耗時。

策略一
服務器返回數據時將數據做壓縮處理。
策略二
使用 webp 格式的圖片資源。 app 的流量消耗的大頭在于圖片，使用 webp 格式的圖片能夠減少 40%+ 的流量消耗。

安全

安全處理策略有兩個方面。一種是在使用上增加安全校驗，一種是在協議上使用安全協議，如 Https。

請求防篡改

前后端交互常規做法的一種。對請求的參數的某些值連在一塊，再通過加鹽算 MD5 值生成一個簽名。將簽名值附加到請求參數中。后端收到請求后同樣需要驗證這個簽名，不一致的話說明請求參數已經被篡改了，不予通過。

signature = md5(value1+value2+value3+solt);

稍微更嚴格一點的方式是，對所有請求參數根據 key 值做自然排序，再用上述方法算一遍簽名。

這種方式主要是為了防止參數被篡改，并不能防止被攔截。

Https

使用 Https 能從協議上解決安全問題。全面升級到 Https 是目前業界的趨勢。下圖是 Https 的處理過程簡圖：

WebSocket 協議

Http 協議是一種被動式的處理消息的方式。 app 很多場景下需要由服務器主動將數據推送到客戶端。使用 WS 協議維持客戶端到服務器的長連接是一種很好的解決方案。目前在 IM 或直播的場景下應用b

比較廣泛。

WS 請求

WS 響應

上面兩張圖為 ws 協議請求和響應。

客戶端發起一個 http 的 get 請求。
請求頭中表示鏈接方式為升級(Connection: Upgrade) 到 websocket協議（Upgrade: websocket）
Sec-WebSocket-Key: 為客戶端生成的隨機字符串(掩碼值)
Sec-WebSocket-Version： 13 表示使用 ws 1.3 版本。
響應碼 101 表示協議切換成功, 協議升級到 websocket (Upgrade:websocket)

在看一下 ws 協議下的每幀數據組成：

每幀數據都包含 2byte 的頭信息。

FIN 表示是否為最后一幀

RSV1/2/3 為擴展字段。客戶端與服務器可以通過約定這幾個字段的值實現協議上的附加操作，比如是否開啟數據壓縮。

OP Code 為每一幀的操作類型。比如當前幀是操作幀還是數據幀

MASK 0/1 表示是否設置了掩碼

LENGTH 為數據包長度

在 2byte 頭信息之后帶上整個幀的真實數據。

Http2 協議

下一代 http 協議。解決了諸多 http 下的問題，被越來越廣泛的應用。

App 下的理想網絡模型特點

App 的網絡場景要比 pc 上復雜很多，也不穩定的多。對于 app 來說，理想的網絡模型特點應該要有：

低延時
安全
雙向數據通道

在不同的場景下使用不同的工具去解決問題，重點是要熟悉每種協議的特點，以及如何使用。

來自：http://www.jianshu.com/p/b657a1bb0c32

本文由用戶 jxmu3532 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1474251584356.html

服務器移動開發