物聯網相關協議MQTT，AMQP，Modbus，CoAp

因為最近項目涉及到與外部設備交互，所以有必要了解一下目前市面上的物聯網相關協議。

一、MQTT

MQTT（Message Queuing Telemetry Transport）消息隊列遙測傳輸，是一種發布/訂閱（Publish/Subscribe）模式的輕量級、可擴展的物聯網傳輸協議。

MQTT是基於二進制消息的發布/訂閱編程模式的消息協議，最早由IBM提出的，如今已經成為OASIS規范。由於規范很簡單，非常適合需要低功耗和網絡帶寬有限的IoT場景，比如：遙感數據，汽車，智能家居，智慧城市，醫療醫護等。

 MQTT它有三個主要特點。

1.采用二進制的消息內容編碼格式，所有二進制數據、JSON 和圖片等負載內容都可以方便傳輸。

2.協議頭很緊湊，協議交互也簡單，保證了網絡傳輸流量很小。
3.支持 3 種 QoS（Quality of Service，服務質量）級別，便於應用根據不同的場景需求靈活選擇。

這三個特點，讓 MQTT 協議非常適合計算能力有限、網絡帶寬低、信號不穩定的遠程設備，所以它成為了物聯網系統事實上的網絡協議標准。

所以MQTT遵循以下設計原則：

1. 精簡，不添加可有可無的功能。
2. 發布/訂閱（Pub/Sub）模式，方便消息在傳感器之間傳遞。
3. 允許用戶動態創建主題，零運維成本。
4. 把傳輸量降到最低以提高傳輸效率。
5. 把低帶寬、高延遲、不穩定的網絡等因素考慮在內。
6. 支持連續的會話控制。
7. 理解客戶端計算能力可能很低。
8. 提供服務質量管理。
9. 假設數據不可知，不強求傳輸數據的類型與格式，保持靈活性。

運用MQTT協議，設備可以很方便地連接到物聯網雲服務，管理設備並處理數據，最后應用到各種業務場景。

發布/訂閱模式

與請求/回答這種同步模式不同，發布/定義模式解耦了發布消息的客戶（發布者）與訂閱消息的客戶（訂閱者）之間的關系，這意味着發布者和訂閱者之間並不需要直接建立聯系。打個比方，你打電話給朋友，一直要等到朋友接電話了才能夠開始交流，是一個典型的同步請求/回答的場景；而給一個好友郵件列表發電子郵件就不一樣，你發好電子郵件該干嘛干嘛，好友們到有空了去查看郵件就是了，是一個典型的異步發布/訂閱的場景。它帶來了這些好處：

• 發布者與訂閱者不比了解彼此，只要認識同一個消息代理即可。
• 發布者和訂閱者不需要交互，發布者無需等待訂閱者確認而導致鎖定。
• 發布者和訂閱者不需要同時在線，可以自由選擇時間來消費消息。

 服務質量

為了滿足不同的場景，MQTT支持三種不同級別的服務質量（Quality of Service，QoS）為不同場景提供消息可靠性：

• 級別0：盡力而為。消息發送者會想盡辦法發送消息，但是遇到意外並不會重試。
• 級別1：至少一次。消息接收者如果沒有知會或者知會本身丟失，消息發送者會再次發送以保證消息接收者至少會收到一次，當然可能造成重復消息。
• 級別2：恰好一次。保證這種語義肯待會減少並發或者增加延時，不過丟失或者重復消息是不可接受的時候，級別2是最合適的。

服務質量是個老話題了。級別2所提供的不重不丟很多情況下是最理想的，不過往返多次的確認一定對並發和延遲帶來影響。級別1提供的至少一次語義在日志處理這種場景下是完全OK的，所以像Kafka這類的系統利用這一特點減少確認從而大大提高了並發。級別0適合雞肋數據場景，食之無味棄之可惜，就這么着吧。

消息類型

MQTT擁有14種不同的消息類型：

1. CONNECT：客戶端連接到MQTT代理
2. CONNACK：連接確認
3. PUBLISH：新發布消息
4. PUBACK：新發布消息確認，是QoS 1給PUBLISH消息的回復
5. PUBREC：QoS 2消息流的第一部分，表示消息發布已記錄
6. PUBREL：QoS 2消息流的第二部分，表示消息發布已釋放
7. PUBCOMP：QoS 2消息流的第三部分，表示消息發布完成
8. SUBSCRIBE：客戶端訂閱某個主題
9. SUBACK：對於SUBSCRIBE消息的確認
10. UNSUBSCRIBE：客戶端終止訂閱的消息
11. UNSUBACK：對於UNSUBSCRIBE消息的確認
12. PINGREQ：心跳
13. PINGRESP：確認心跳
14. DISCONNECT：客戶端終止連接前優雅地通知MQTT代理

 二、AMQP

除了 MQTT 協議外，還有其他采用發布 - 訂閱模式的網絡協議，比如 AMQP 協議。AMQP的全稱為：Advanced Message Queuing Protocol（高級消息隊列協議）

雖然 AMQP 協議擁有龐大的特性集，比較重，不適合計算資源有限、對功耗要求嚴苛的物聯網設備，但是它可以滿足后台系統對於可靠性和可擴展性的要求。因此，它在物聯網的平台系統中應用廣泛。

MQTT的發布 - 訂閱模式的很多好處，但是凡事都有例外，也有一些物聯網應用場景，並不適合使用這種模式。比如，現在小區里面都有智能快遞櫃，當你輸入取件碼后，服務器會向對應的櫃門發送開門指令。在發布 - 訂閱模式下，服務器知道指令發送成功了，但是它無法知道櫃門是否真的打開了。這時，你就需要讓櫃門能夠向服務器反饋一下命令的執行結果。當然，你也可以讓服務器訂閱一個“櫃門關閉”的主題消息，然后等待櫃門發布這個消息。但是這樣的話就非常繁瑣、不夠直接。在這種場景下，另一種通信模式就能派上用場了，那就是請求 - 響應模式。

請求 - 響應模式有兩個角色，一個是客戶端，另一個是服務器。
客戶端是請求數據或者服務的一方。服務器則用來接收客戶端的請求，並提供相應的數據或者服務。服務器在收到請求后，會獲取數據，對資源數據（比如數據庫）進行加工處理，准備好響應，然后返回給客戶端。
請求 - 響應模式是無狀態的通信方式，每個完整的請求 - 響應都是相互獨立的。進一步細分的話，它還可以分為同步和異步兩種。

三、Modbus

什么是Modbus？

Modbus是MODICON公司最先倡導的一種軟的通訊規約，經過大多數公司 的實際應用，逐漸被認可，成為一種標准的通訊規約，只要按照這種規約進行數據通訊或傳輸，不同的系統就可以通訊。目前，在RS232/RS485通訊過程中，更是廣泛采用這種規約。    常用的Modbus通訊規約有兩種，一種是ModbusASCII，一種是Modbus RTU。
 一般來說，通訊數據量少而且主要是文本的通訊則采用Modbus ASCII規約，通訊數據數據量大而且是二進制數值時，多采用Modbus RTU規約。

在實際的應用過程中，為了解決某一個特殊問題，人們喜歡自己修改Modbus規約來滿足自己的需要（事實上，人們經常使用自己定義的規約來通訊，這樣能解決問題，但不太規范）。更為普通的用法是，少量修改規約，但將規約格式附在軟件說明書一起，或直接放在幫助中，這樣就方便了用戶的通訊。Modbus-TCP主要應用於基於以太網TCP/IP通信的控制網絡中。

 

通過此協議，控制器相互之間、或控制器經由網絡(如以太網)可以和其它設備之間進行通信。Modbus協議使用的是主從通訊技術，即由主設備主動查詢和操作從設備。一般將主控設備方所使用的協議稱為Modbus Master，從設備方使用的協議稱為Modbus Slave。典型的主設備包括工控機和工業控制器等;典型的從設備如PLC可編程控制器等。Modbus通訊物理接口可以選用串口(包括RS232和RS485)，也可以選擇以太網口。其通信遵循以下的過程：

 

●　主設備向從設備發送請求

 

●　從設備分析並處理主設備的請求，然后向主設備發送結果

 

●　如果出現任何差錯，從設備將返回一個異常功能碼

Modbus協議具有以下幾個特點：

(1)標准、開放，用戶可以免費、放心地使用Modbus協議，不需要交納許可證費，也不會侵犯知識產權。

(2)Modbus可以支持多種電氣接口，如RS-232、RS-485等，還可以在各種介質上傳送，如雙絞線、光纖、無線等。

(3)Modbus的幀格式簡單、緊湊，通俗易懂。用戶使用容易，廠商開發簡單。

 

四、CoAp

CoAP（Constrained Application Protocol）約束應用協議。跟 HTTP 協議類似，但是設計輕量，可以用於資源受限的物聯網設備的協議。跟 HTTP 協議一樣，CoAP 協議同樣有 GET、POST、PUT、DELETE 等方法和響應狀態碼，同樣使用 URI 而不是 Topic 來標識資源。比如我們需要訪問服務器 test.com 下面的 abc/temp 這個資源，那完整的資源地址是：test.com/abc/temp。

CoAP 的消息采用二進制格式，支持可確認消息和不可確認消息兩種 QoS 級別。可確認消息（Confirmable Message）與 MQTT 協議的 QoS 1 類似，不可確認消息（Non-confirmable Message）對應 MQTT 協議的 QoS 0 級別。

另外，CoAP 協議基於的傳輸層協議是 UDP，而不是 HTTP 、 MQTT 協議的 TCP 協議，所以對於設備的計算資源要求更低。傳感器設備一般只需要上傳數據，不用隨時接收服務器的控制命令，這都說明 CoAP 協議適合電池供電的傳感器設備。