物聯網傳輸協議 - REST/HTTP

在繁雜的物聯網應用中，如何根據自己的業務需求，來選擇合適且高效的應用層通信傳輸協議。是一個復雜且需要知識儲備的事情。

接下來我們將講解一下目前常見的一些物聯網通信傳輸協議。

REST/HTTP

在物聯網的應用層面，經常通過 REST/HTTP 開放物聯網中資源，實現服務被其他應用所調用。其用于實現客戶端和服務器之間交互的松耦合，降低了客戶端和服務器之間的交互延遲。

快速入門

在 HTTP 通信協議中和其他許多的協議相同，用于客戶端和服務器之間的通信。

HTTP 通信中，整體通信過程一定是由客戶端發出請求，服務端來響應請求。

HTTP 是一種無狀態協議。也就是說請求和響應都不會做持久化處理。

HTTP 請求

我們需要先了解一下 HTTP 請求的格式與規范。

首先，如果我們想向服務端發送請求，我們就需要一個標志來知道向誰發送請求，畢竟互聯網這么大，誰也不知道隨機定位會去哪兒。

就像我們的電話號碼一樣，如果我想給朋友打一個電話，我就需要輸入一串唯一的電話號碼。

在請求時，我們要帶上我們請求的方法，其主要為所做事情的一個分類縮寫。用于精確區分具體功能，簡化接口架構復雜性。 基于RESTful 的 HTTP API 請求方法解釋如下：

GET - 用于獲取資源

POST - 用于添加資源

PUT - 用于更新資源 （ 整體資源 ）

PATCH - 用于更新資源（ 資源內的部分 ）

DELETE - 用于刪除資源

當客戶端向服務端發送請求時，發送的HTTP 報文就叫做請求報文。

HTTP請求報文由 報文頭部 、空行、報文主體三部分組成。如圖所示：

報文頭部包含請求行 ( 包含請求方法、HTTP版本和URI )、各種頭部字段（ 稍后講解 ）。

空行（ CR+LF ）為一個區分頭部和請求行的標志符號。

報文主體包含一些所需要傳輸的數據或為空。

一個完整的HTTP GET 方法的請求報文如下：

HTTP 響應

當服務端接收客戶端發送的請求后，要根據業務情況進行返回響應報文。

HTTP 響應報文的格式和請求報文大體類似。也是由報文頭部 、空行、報文主體三部分組成。如圖所示：

報文頭部包含響應狀態行（ 響應狀態碼和HTTP 版本 ）

完成的HTTP 響應報文如下：

HTTP 的狀態碼是服務端對客戶端請求的返回結果，用來標記服務端對于該請求的處理情況。

一些日常常見的狀態碼：

2xx

200 OK / 請求成功

3xx

301 Moved Permanently / 被請求的資源已永久移動到新位置，并且將來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。

304 Not Modified / 如果客戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）并沒有改變，則服務器應當返回這個狀態碼。

4xx

400 Bad Request / 1. 語義有誤，當前請求無法被服務器理解。 2. 請求參數有誤。

401 Unauthorized / 當前請求需要用戶驗證。

403 Forbidden / 服務器已經理解請求，但是拒絕執行它。

404 Not Found / 請求失敗，請求所希望得到的資源未被在服務器上發現。

5xx

500 Internal Server Error / 服務器遇到了不知道如何處理的情況。

503 Service Unavailable / 服務器沒有準備好處理請求。 常見原因是服務器因維護或重載而停機。

504 Gateway Timeout / 當服務器作為網關，不能及時得到響應時返回此錯誤代碼。

推薦一個有意思的網站，如果你記不住一些狀態碼，可以去該網站查找。

https://http.cat/

HTTP 頭部

在發送請求報文和接收響應報文時我們經常會發現報文頭部會有許許多多的頭部字段，接下來我們將會對一些常見的字段進行講解。

HTTP 頭部字段時由名稱和值構成的一個類似 K-V 結構，中間用冒號分隔。

字段名 ： 字段值

有一些字段在請求和響應中都會有，稱其為通用頭部字段。常見如下：

Cache-Control 控制緩存的行為

Connection 逐跳首部、連接的管理

Date 創建報文的日期時間

Pragma 報文指令

Trailer 報文末端的首部一覽

Transfer-Encoding 指定報文主體的傳輸編碼方式

Upgrade 升級為其他協議

Via 代理服務器的相關信息

Warning 錯誤通知

客戶端向服務端發送報文時攜帶的字段。主要用于標記一下語言、響應格式等信息。

Accept 用戶代理可處理的媒體類型

Accept-Charset 優先的字符集

Accept-Encoding 優先的內容編碼

Accept-Language 優先的語言（自然語言）

Authorization Web認證信息

Expect 期待服務器的特定行為

From 用戶的電子郵箱地址

Host 請求資源所在服務器

服務端向客戶端響應報文所附加的字段。主要用于補充響應的附加內容等。

Accept-Ranges 是否接受字節范圍請求

Age 推算資源創建經過時間

ETag 資源的匹配信息

Proxy-Authenticate 代理服務器對客戶端的認證信息

主要針對請求報文和響應報文的字段。補充了例如內容類型、內容長度等

Content-Encoding 實體主體適用的編碼方式

Content-Type 實體主體的媒體類型

Expires 實體主體過期的日期時間

Content-Language 實體主體的自然語言

Content-Length 實體主體的大小（單位：字節）

HTTP 的優缺點

當大家大致了解HTTP協議后，我們將對其進行簡單的總結。來分析一下 HTTP 協議的優缺點。

好的方面：

簡單、靈活和易于擴展

擁有成熟的生態規范

無狀態協議。利于實現分布式集群化。

不好的方面：

明文傳輸，所有數據可以輕松獲取。

無法效驗通信雙方的身份。導致惡意訪問。

無法證明報文的完整，有可能被篡改。

HTTP IoT TCP/IP

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。