App網(wǎng)絡(luò)基礎(chǔ)知識概括

前言

網(wǎng)絡(luò)模塊是 App 應(yīng)用最基礎(chǔ)最核心的模塊， 穩(wěn)定高效的網(wǎng)絡(luò)處理是良好用戶體驗的基本保障。 本文介紹日常開發(fā)中常用的網(wǎng)絡(luò)協(xié)議以及使用方法。

目錄

  • http 協(xié)議
  • http 的問題以及優(yōu)化策略
  • 安全處理策略
  • WebSocket 協(xié)議解析
  • Http2 協(xié)議簡介

Http 協(xié)議

先看一下網(wǎng)絡(luò)請求傳輸?shù)倪^程：


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

  1. DNS 解析， 獲取服務(wù)器的 ip 地址列表
  2. TCP/IP 鏈接到服務(wù)器
  3. 在 TCP/IP 上構(gòu)建協(xié)議規(guī)則
  4. 服務(wù)器收到請求，通過通道返回響應(yīng)
  5. Client 收到響應(yīng)后關(guān)閉通道

Http 協(xié)議分為 Request， Response 兩部分。 客戶端發(fā)起一個 Request； 服務(wù)器處理后，返回一個 Response。

Request

看一下 Request 的構(gòu)成：



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

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

常用的請求頭字段：

  • Content-Type： 表示請求內(nèi)容的類型。 一般 api 請求主要使用

application/json
application/x-www-form-urlencoded
multipart/form-data

  • Content-Length: 請求體大小。 服務(wù)器根據(jù)這個值才能獲取完整的請求數(shù)據(jù)
  • User-Agent: 客戶端可以隨意設(shè)置的一個值， 用來描述客戶端的信息
  • Connection: 鏈接類型。 上圖中 Keep-Alive 表示服務(wù)器收到請求號保持鏈接不要關(guān)閉。
  • Accept-Encoding: gzip 表示當(dāng)前客戶端接受 gzip 編碼的響應(yīng)內(nèi)容

Response


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

響應(yīng)碼： 請求是否成功根據(jù)響應(yīng)碼判斷。 每種響應(yīng)碼都對應(yīng)各自的含義。詳細(xì)參考 wiki

常用的響應(yīng)頭：

  • Connection: keep-alive. 表示響應(yīng)未關(guān)閉， 客戶端實現(xiàn)上同樣需要保持鏈接未關(guān)閉
  • Cache-Control: 協(xié)議的緩存策略
  • Content-Encoding: gzip 表示當(dāng)前返回的內(nèi)容采用的 gzip 編碼。 解析數(shù)據(jù)時使用 gzip 解碼
  • Content-Type：返回數(shù)據(jù)的內(nèi)容格式

Cookie

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

Http 的問題

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

  1. 最大的問題， 延遲。 App 的請求都很分散， 大部分發(fā)起的請求都需要重新構(gòu)建整個鏈接， 延遲問題很嚴(yán)重。
  2. 無效數(shù)據(jù)重復(fù)提交。 每次請求都會將同樣的 headers 提交到服務(wù)器。
  3. 單向數(shù)據(jù)通道。 服務(wù)器屬于被動響應(yīng)模式， 無法做到主動推送數(shù)據(jù)。

Http 優(yōu)化策略

Http耗時

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

1. Cache

最快的請求是不發(fā)起請求。 不僅在協(xié)議層處理網(wǎng)絡(luò)的緩存， 還需要在業(yè)務(wù)層處理數(shù)據(jù)的緩存。 在不必要的情況下， 盡量不發(fā)起網(wǎng)絡(luò)請求， 直接使用緩存中的數(shù)據(jù)。

2. DNS

系統(tǒng)都有 Dns 解析的實現(xiàn)。 默認(rèn)情況下直接調(diào)用系統(tǒng) API 執(zhí)行 Dns 查詢操作。

  • Dns 優(yōu)化策略一
    實現(xiàn) Dns 二級緩存。 當(dāng)執(zhí)行請求時，需要調(diào)用 Dns 查詢。 將 ips 結(jié)果緩存起來， 下次再請求同樣的域名時，直接從緩存內(nèi)取出結(jié)果， 而不需要再次調(diào)用系統(tǒng)查詢

  • Dns 優(yōu)化策略二
    使用第三方 HttpDns 服務(wù)。 系統(tǒng)默認(rèn)的 dns 服務(wù)在不同的設(shè)備不同的 os 上實現(xiàn)、速度、緩存策略可能都不太一樣?？梢允褂玫谌降?HttpDns 服務(wù)查詢 IPs， 繞開系統(tǒng)層的實現(xiàn)。 然后自己實現(xiàn)結(jié)果緩存策略。 例如, 使用騰訊的 DnsPod 查詢百度的 IPs：
    http://119.29.29.29/d?dn=www.baidu.com

3. 鏈接復(fù)用

http 1.1 默認(rèn)是設(shè)置 Connection:Keep-Alive。 就是表示請求完成后并不馬上關(guān)閉， 后續(xù)相同的請求通過鏈路的復(fù)用， 節(jié)省 tcp 鏈接建立的耗時。

4. 請求

在帶寬固定的情況下， 減少提交的數(shù)據(jù)包大小， 降低數(shù)據(jù)傳輸?shù)暮臅r。

  • 策略一
    選擇合理的數(shù)據(jù)提交方式。 一般常用的 post 數(shù)據(jù)提交格式有
  1. JSON Content-Type: application/json
  2. UrlEncode Content-Type:application/x-www-form-urlencoded
  3. formdata Content-Type:application/form-data

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

  • 策略二
    對提交的內(nèi)容進(jìn)行壓縮。 同時設(shè)置 Content-Encoding。

5. 響應(yīng)

原理同上， 減小數(shù)據(jù)包的大小， 降低數(shù)據(jù)傳輸?shù)暮臅r。

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

安全

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

請求防篡改

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

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

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

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

Https

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


WebSocket 協(xié)議

Http 協(xié)議是一種被動式的處理消息的方式。 app 很多場景下需要由服務(wù)器主動將數(shù)據(jù)推送到客戶端。 使用 WS 協(xié)議維持客戶端到服務(wù)器的長連接是一種很好的解決方案。 目前在 IM 或直播的場景下應(yīng)用b
比較廣泛。

WS 請求
WS 響應(yīng)

上面兩張圖為 ws 協(xié)議請求和響應(yīng)。

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

在看一下 ws 協(xié)議下的每幀數(shù)據(jù)組成：

每幀數(shù)據(jù)都包含 2byte 的頭信息。
FIN 表示是否為最后一幀
RSV1/2/3 為擴(kuò)展字段?？蛻舳伺c服務(wù)器可以通過約定這幾個字段的值實現(xiàn)協(xié)議上的附加操作， 比如是否開啟數(shù)據(jù)壓縮。
OP Code 為每一幀的操作類型。 比如當(dāng)前幀是操作幀還是數(shù)據(jù)幀
MASK 0/1 表示是否設(shè)置了掩碼
LENGTH 為數(shù)據(jù)包長度

在 2byte 頭信息之后帶上整個幀的真實數(shù)據(jù)。

Http2 協(xié)議

下一代 http 協(xié)議。 解決了諸多 http 下的問題， 被越來越廣泛的應(yīng)用。 我總結(jié)的也不太好， 詳細(xì)參見另一篇博客HTTP 2.0的那些事

App 下的理想網(wǎng)絡(luò)模型特點

App 的網(wǎng)絡(luò)場景要比 pc 上復(fù)雜很多， 也不穩(wěn)定的多。 對于 app 來說， 理想的網(wǎng)絡(luò)模型特點應(yīng)該要有：

  • 低延時
  • 安全
  • 雙向數(shù)據(jù)通道

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

廣告： 基于 OkHttp 實現(xiàn)的網(wǎng)絡(luò)工具庫BJNetwork

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • Spring Cloud為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見模式的工具（例如配置管理，服務(wù)發(fā)現(xiàn)，斷路器，智...
    卡卡羅2017閱讀 136,534評論 19贊 139
  • API定義規(guī)范 本規(guī)范設(shè)計基于如下使用場景： 請求頻率不是非常高：如果產(chǎn)品的使用周期內(nèi)請求頻率非常高，建議使用雙通...
    有涯逐無涯閱讀 2,922評論 0贊 6
  • 1. 網(wǎng)絡(luò)基礎(chǔ)TCP/IP HTTP基于TCP/IP協(xié)議族，HTTP屬于它內(nèi)部的一個子集。 把互聯(lián)網(wǎng)相關(guān)聯(lián)的協(xié)議集...
    yozosann閱讀 3,600評論 0贊 20
  • http協(xié)議有http0.9，http1.0，http1.1和http2三個版本，但是現(xiàn)在瀏覽器使用的是htt...
    一現(xiàn)_閱讀 1,993評論 0贊 3
  • 網(wǎng)絡(luò)請求是iOS項目的一個大部分,而且大部分的iOS的項目的網(wǎng)絡(luò)請求是根據(jù)AFN進(jìn)行的二次封裝,我們查看返回的結(jié)果...
    FR_Zhang閱讀 7,261評論 15贊 46

友情鏈接更多精彩內(nèi)容