為什么 MQTT 是適合物聯(lián)網的網絡協(xié)議
發(fā)布時間：2021-08-28
瀏覽次數(shù)：312
為什么 MQTT 是適合物聯(lián)網的網絡協(xié)議
物聯(lián)網 (IoT) 設備必須連接互聯(lián)網。通過連接到互聯(lián)網，設備就能相互協(xié)作，以及與后端服務協(xié)同工作?；ヂ?lián)網的基礎網絡協(xié)議是 TCP/IP。MQTT（消息隊列遙測傳輸） 是基于 TCP/IP 協(xié)議棧而構建的，已成為 IoT 通信的標準。
MQTT 初由 IBM 于上世紀 90 年代晚期發(fā)明和開發(fā)。它初的用途是將石油管道上的傳感器與衛(wèi)星的相鏈接。顧名思義，它是一種支持在各方之間異步通信的消息協(xié)議。異步消息協(xié)議在空間和時間上將消息發(fā)送者與接收者分離，因此可以在不可靠的網絡環(huán)境中進行擴展。雖然叫做消息隊列遙測傳輸，但它與消息隊列毫無關系，而是使用了一個發(fā)布和訂閱的模型。在 2014 年末，它正式成為了一種 OASIS 開放標準，而且在一些流行的編程語言中受到支持（通過使用多種開源實現(xiàn)）。
為何選擇 MQTT
MQTT 是一種輕量級的、靈活的網絡協(xié)議，致力于為 IoT 開發(fā)人員實現(xiàn)適當?shù)钠胶猓?/span>
這個輕量級協(xié)議可在嚴重受限的設備硬件和高延遲/帶寬有限的網絡上實現(xiàn)。
它的靈活性使得為 IoT 設備和服務的多樣化應用場景提供支持成為可能。
為了了解為什么 MQTT 如此適合 IoT 開發(fā)人員，我們首先來分析一下為什么其他流行網絡協(xié)議未在 IoT 中得到成功應用。
為什么不選擇HTTP
大多數(shù)開發(fā)人員已經熟悉 HTTP Web 服務。那么為什么不讓 IoT 設備連接到 Web 服務？設備可采用 HTTP 請求的形式發(fā)送其數(shù)據，并采用 HTTP 響應的形式從系統(tǒng)接收更新。這種請求和響應模式存在一些嚴重的局限性：
1.HTTP 是一種同步協(xié)議?？蛻舳诵枰却掌黜憫?。Web 瀏覽器具有這樣的要求，但它的代價是沒了可伸縮性。在 IoT 領域，大量設備以及很可能不可靠或高延遲的網絡使得同步通信成為問題。異步消息協(xié)議更適合 IoT 應用程序。傳感器發(fā)送讀數(shù)，讓網絡確定將其傳送到目標設備和服務的佳路線和時間。
2.HTTP 是單向的?？蛻舳吮仨毎l(fā)起連接。在 IoT 應用程序中，設備或傳感器通常是客戶端，這意味著它們無法被動地接收來自網絡的命令。
3.HTTP 是一種 1-1 協(xié)議?？蛻舳税l(fā)出請求，服務器進行響應。將消息傳送到網絡上的所有設備上，不但很困難，而且成本很高，而這是 IoT 應用程序中的一種常見使用情況。
這個很重要，比如說GET和POST方法，這兩個是很常用的，GET就是獲取什么內容，而POST就是向服務器發(fā)送什么數(shù)據。當然還有其他的，比如HTTP 1.1中還有：DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8個方法（HTTP Method歷史：HTTP 0.9 只有GET方法；HTTP 1.0 有GET、POST、HEAD三個方法）。
請求URL:
這里填寫的URL是不包含IP地址或者域名的，是主機本地文件對應的目錄地址，所以我們一般看到的就是“/”。
版本version：
格式是HTTP/<major>.<minor>這樣的格式，比如說HTTP/1.1.這個版本就是我們使用的HTTP協(xié)議的版本，現(xiàn)在使用的一般是HTTP/1.1
狀態(tài)碼status:
狀態(tài)碼是三個數(shù)字，是請求過程中所發(fā)生的情況，比如說200是成功，404是找不到文件。
原因短語reason-phrase：
是狀態(tài)碼的可讀版本，狀態(tài)碼就是一個數(shù)字，如果你事先不知道這個數(shù)字什么意思，可以先查看一下原因短語。
首部header：
注意這里的header我們不是叫做頭，而是叫做首部?？赡苡辛銈€首部也可能有多個首部，每個首部包含一個名字后面跟著一個冒號，然后是一個可選的空格，接著是一個值，然后換行。
實體的主體部分entity-body：
它具有以下主要的幾項特性：
1、使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布和應用程序之間的解耦；
2、消息傳輸不需要知道負載內容；
3、使用 TCP/IP 提供網絡連接；
4、有三種消息發(fā)布的服務質量：
QoS 0：“多一次”，消息發(fā)布完全依賴底層 TCP/IP 網絡。分發(fā)的消息可能丟失或重復。例如，這個等級可用于環(huán)境傳感器數(shù)據，單次的數(shù)據丟失沒關系，因為不久后還會有第二次發(fā)送。
QoS 1：“至少一次”，確保消息可以到達，但消息可能會重復。
QoS 2：“只有一次”，確保消息只到達一次。例如，這個等級可用在一個計費系統(tǒng)中，這里如果消息重復或丟失會導致不正確的收費。
5、小型傳輸，開銷很?。ü潭ㄩL度的頭部是 2 字節(jié)），協(xié)議交換小化，以降低網絡流量；
6、使用 Last Will 和 Testament 特性通知有關各方客戶端異常中斷的機制；
MQTT 協(xié)議在網絡中定義了兩種實體類型：一個消息代理和一些客戶端。代理是一個服務器，它從客戶端接收所有消息，然后將這些消息路由到相關的目標客戶端。客戶端是能夠與代理交互來發(fā)送和接收消息的任何事物?？蛻舳丝梢允乾F(xiàn)場的 IoT 傳感器，或者是數(shù)據中心內處理 IoT 數(shù)據的應用程序。
客戶端連接到代理。它可以訂閱代理中的任何消息 “主題”。此連接可以是簡單的 TCP/IP 連接，也可以是用于發(fā)送敏感消息的加密 TLS 連接。
客戶端通過將消息和主題發(fā)送給代理，發(fā)布某個主題范圍內的消息。
代理然后將消息轉發(fā)給所有訂閱該主題的客戶端。
因為 MQTT 消息是按主題進行組織的，所以應用程序開發(fā)人員能靈活地指定某些客戶端只能與某些消息交互。例如，傳感器將在 “sensor_data” 主題范圍內發(fā)布讀數(shù)，并訂閱 “config_change” 主題。將傳感器數(shù)據保存到后端數(shù)據庫中的數(shù)據處理應用程序會訂閱 “sensor_data” 主題。管理控制臺應用程序能接收系統(tǒng)管理員的命令來調整傳感器的配置，比如靈敏度和采樣頻率，并將這些更改發(fā)布到 “config_change” 主題。
同時，MQTT 是輕量級的。它有一個用來指定消息類型的簡單標頭，有一個基于文本的主題，還有一個任意的二進制有效負載。應用程序可對有效負載采用任何數(shù)據格式，比如 JSON、XML、加密二進制或 Base64，只要目標客戶端能夠解析該有效負載。
物聯(lián)網 (IoT) 設備必須連接互聯(lián)網。通過連接到互聯(lián)網，設備就能相互協(xié)作，以及與后端服務協(xié)同工作?；ヂ?lián)網的基礎網絡協(xié)議是 TCP/IP。MQTT（消息隊列遙測傳輸） 是基于 TCP/IP 協(xié)議棧而構建的，已成為 IoT 通信的標準。
MQTT 初由 IBM 于上世紀 90 年代晚期發(fā)明和開發(fā)。它初的用途是將石油管道上的傳感器與衛(wèi)星的相鏈接。顧名思義，它是一種支持在各方之間異步通信的消息協(xié)議。異步消息協(xié)議在空間和時間上將消息發(fā)送者與接收者分離，因此可以在不可靠的網絡環(huán)境中進行擴展。雖然叫做消息隊列遙測傳輸，但它與消息隊列毫無關系，而是使用了一個發(fā)布和訂閱的模型。在 2014 年末，它正式成為了一種 OASIS 開放標準，而且在一些流行的編程語言中受到支持（通過使用多種開源實現(xiàn)）。
為何選擇 MQTT
MQTT 是一種輕量級的、靈活的網絡協(xié)議，致力于為 IoT 開發(fā)人員實現(xiàn)適當?shù)钠胶猓?/span>
這個輕量級協(xié)議可在嚴重受限的設備硬件和高延遲/帶寬有限的網絡上實現(xiàn)。
它的靈活性使得為 IoT 設備和服務的多樣化應用場景提供支持成為可能。
為了了解為什么 MQTT 如此適合 IoT 開發(fā)人員，我們首先來分析一下為什么其他流行網絡協(xié)議未在 IoT 中得到成功應用。
為什么不選擇HTTP
大多數(shù)開發(fā)人員已經熟悉 HTTP Web 服務。那么為什么不讓 IoT 設備連接到 Web 服務？設備可采用 HTTP 請求的形式發(fā)送其數(shù)據，并采用 HTTP 響應的形式從系統(tǒng)接收更新。這種請求和響應模式存在一些嚴重的局限性：
1.HTTP 是一種同步協(xié)議?？蛻舳诵枰却掌黜憫?。Web 瀏覽器具有這樣的要求，但它的代價是沒了可伸縮性。在 IoT 領域，大量設備以及很可能不可靠或高延遲的網絡使得同步通信成為問題。異步消息協(xié)議更適合 IoT 應用程序。傳感器發(fā)送讀數(shù)，讓網絡確定將其傳送到目標設備和服務的佳路線和時間。
2.HTTP 是單向的?？蛻舳吮仨毎l(fā)起連接。在 IoT 應用程序中，設備或傳感器通常是客戶端，這意味著它們無法被動地接收來自網絡的命令。
3.HTTP 是一種 1-1 協(xié)議?？蛻舳税l(fā)出請求，服務器進行響應。將消息傳送到網絡上的所有設備上，不但很困難，而且成本很高，而這是 IoT 應用程序中的一種常見使用情況。
4.HTTP 是一種有許多標頭和規(guī)則的重量級協(xié)議。它不適合受限的網絡。
這個很重要，比如說GET和POST方法，這兩個是很常用的，GET就是獲取什么內容，而POST就是向服務器發(fā)送什么數(shù)據。當然還有其他的，比如HTTP 1.1中還有：DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8個方法（HTTP Method歷史：HTTP 0.9 只有GET方法；HTTP 1.0 有GET、POST、HEAD三個方法）。
請求URL:
這里填寫的URL是不包含IP地址或者域名的，是主機本地文件對應的目錄地址，所以我們一般看到的就是“/”。
版本version：
格式是HTTP/<major>.<minor>這樣的格式，比如說HTTP/1.1.這個版本就是我們使用的HTTP協(xié)議的版本，現(xiàn)在使用的一般是HTTP/1.1
狀態(tài)碼status:
狀態(tài)碼是三個數(shù)字，是請求過程中所發(fā)生的情況，比如說200是成功，404是找不到文件。
原因短語reason-phrase：
是狀態(tài)碼的可讀版本，狀態(tài)碼就是一個數(shù)字，如果你事先不知道這個數(shù)字什么意思，可以先查看一下原因短語。
首部header：
注意這里的header我們不是叫做頭，而是叫做首部?？赡苡辛銈€首部也可能有多個首部，每個首部包含一個名字后面跟著一個冒號，然后是一個可選的空格，接著是一個值，然后換行。
實體的主體部分entity-body：
實體的主體部分包含一個任意數(shù)據組成的數(shù)據塊，并不是所有的報文都包含實體的主體部分，有時候只是一個空行加換行就結束了。
它具有以下主要的幾項特性：
1、使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布和應用程序之間的解耦；
2、消息傳輸不需要知道負載內容；
3、使用 TCP/IP 提供網絡連接；
4、有三種消息發(fā)布的服務質量：
QoS 0：“多一次”，消息發(fā)布完全依賴底層 TCP/IP 網絡。分發(fā)的消息可能丟失或重復。例如，這個等級可用于環(huán)境傳感器數(shù)據，單次的數(shù)據丟失沒關系，因為不久后還會有第二次發(fā)送。
QoS 1：“至少一次”，確保消息可以到達，但消息可能會重復。
QoS 2：“只有一次”，確保消息只到達一次。例如，這個等級可用在一個計費系統(tǒng)中，這里如果消息重復或丟失會導致不正確的收費。
5、小型傳輸，開銷很?。ü潭ㄩL度的頭部是 2 字節(jié)），協(xié)議交換小化，以降低網絡流量；
6、使用 Last Will 和 Testament 特性通知有關各方客戶端異常中斷的機制；
在MQTT協(xié)議中，一個MQTT數(shù)據包由：固定頭（Fixed header）、 可變頭（Variable header）、 消息體（payload）三部分構成。MQTT的傳輸格式非常精小，小的數(shù)據包只有2個bit，且無應用消息頭。
MQTT 協(xié)議在網絡中定義了兩種實體類型：一個消息代理和一些客戶端。代理是一個服務器，它從客戶端接收所有消息，然后將這些消息路由到相關的目標客戶端。客戶端是能夠與代理交互來發(fā)送和接收消息的任何事物?？蛻舳丝梢允乾F(xiàn)場的 IoT 傳感器，或者是數(shù)據中心內處理 IoT 數(shù)據的應用程序。
客戶端連接到代理。它可以訂閱代理中的任何消息 “主題”。此連接可以是簡單的 TCP/IP 連接，也可以是用于發(fā)送敏感消息的加密 TLS 連接。
客戶端通過將消息和主題發(fā)送給代理，發(fā)布某個主題范圍內的消息。
代理然后將消息轉發(fā)給所有訂閱該主題的客戶端。
因為 MQTT 消息是按主題進行組織的，所以應用程序開發(fā)人員能靈活地指定某些客戶端只能與某些消息交互。例如，傳感器將在 “sensor_data” 主題范圍內發(fā)布讀數(shù)，并訂閱 “config_change” 主題。將傳感器數(shù)據保存到后端數(shù)據庫中的數(shù)據處理應用程序會訂閱 “sensor_data” 主題。管理控制臺應用程序能接收系統(tǒng)管理員的命令來調整傳感器的配置，比如靈敏度和采樣頻率，并將這些更改發(fā)布到 “config_change” 主題。
同時，MQTT 是輕量級的。它有一個用來指定消息類型的簡單標頭，有一個基于文本的主題，還有一個任意的二進制有效負載。應用程序可對有效負載采用任何數(shù)據格式，比如 JSON、XML、加密二進制或 Base64，只要目標客戶端能夠解析該有效負載。
