MQTT協議

MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）最早是IBM開發的一個即時通訊協議，MQTT協議是為大量計算能力有限且工作在低帶寬、不可靠網絡的遠程傳感器和控制設備通訊而設計的一種協議。

MQTT協議的優勢是可以支持所有平臺，它幾乎可以把所有的聯網物品和互聯網連接起來。

它具有以下主要的幾項特性：

1、使用發布/訂閱消息模式，提供一對多的消息發布和應用程序之間的解耦；

2、消息傳輸不需要知道負載內容；

3、使用 TCP/IP 提供網絡連接；

4、有三種消息發布的服務質量：

QoS 0：“最多一次”，消息發布完全依賴底層 TCP/IP 網絡。分發的消息可能丟失或重復。例如，這個等級可用于環境傳感器數據，單次的數據丟失沒關系，因為不久后還會有第二次發送。

QoS 1：“至少一次”，確保消息可以到達，但消息可能會重復。

QoS 2：“只有一次”，確保消息只到達一次。例如，這個等級可用在一個計費系統中，這里如果消息重復或丟失會導致不正確的收費。

5、小型傳輸，開銷很小（固定長度的頭部是 2 字節），協議交換最小化，以降低網絡流量；

6、使用 Last Will 和 Testament 特性通知有關各方客戶端異常中斷的機制；

在MQTT協議中，一個MQTT數據包由：固定頭（Fixed header）、 可變頭（Variable header）、 消息體（payload）三部分構成。MQTT的傳輸格式非常精小，最小的數據包只有2個bit，且無應用消息頭。

下圖是MQTT為可靠傳遞消息的三種消息發布服務質量

發布/訂閱模型允許MQTT客戶端以一對一、一對多和多對一方式進行通訊。

下圖是MQTT的發布／訂閱消息模式

CoAP協議

CoAP是受限制的應用協議(Constrained Application Protocol)的代名詞。由于目前物聯網中的很多設備都是資源受限型的，所以只有少量的內存空間和有限的計算能力，傳統的HTTP協議在物聯網應用中就會顯得過于龐大而不適用。因此，IETF的CoRE工作組提出了一種基于REST架構、傳輸層為UDP、網絡層為6LowPAN（面向低功耗無線局域網的IPv6）的CoAP協議。

CoAP采用與HTTP協議相同的請求響應工作模式。CoAP協議共有4中不同的消息類型。

CON——需要被確認的請求，如果CON請求被發送，那么對方必須做出響應。NON——不需要被確認的請求，如果NON請求被發送，那么對方不必做出回應。ACK——應答消息，接受到CON消息的響應。RST——復位消息，當接收者接受到的消息包含一個錯誤，接受者解析消息或者不再關心發送者發送的內容，那么復位消息將會被發送。

CoAP消息格式使用簡單的二進制格式，最小為4個字節。

一個消息=固定長度的頭部header + 可選個數的option + 負載payload。Payload的長度根據數據報長度來計算。

主要是一對一的協議

舉個例子：

比如某個設備需要從服務器端查詢當前溫度信息。

a.請求消息（CON）： GET /temperature , 請求內容會被包在CON消息里面

b.響應消息 (ACK)： 2.05 Content “22.5 C” ，響應內容會被放在ACK消息里面

CoAP與MQTT的區別

MQTT和CoAP都是行之有效的物聯網協議，但兩者還是有很大區別的，比如MQTT協議是基于TCP，而CoAP協議是基于UDP。從應用方向來分析，主要區別有以下幾點：

1、MQTT協議不支持帶有類型或者其它幫助Clients理解的標簽信息，也就是說所有MQTT Clients必須要知道消息格式。而CoAP協議則相反，因為CoAP內置發現支持和內容協商，這樣便能允許設備相互窺測以找到數據交換的方式。

2、MQTT是長連接而CoAP是無連接。MQTT Clients與Broker之間保持TCP長連接，這種情形在NAT環境中也不會產生問題。如果在NAT環境下使用CoAP的話，那就需要采取一些NAT穿透性手段。

3、MQTT是多個客戶端通過中央代理進行消息傳遞的多對多協議。它主要通過讓客戶端發布消息、代理決定消息路由和復制來解耦消費者和生產者。MQTT就是相當于消息傳遞的實時通訊總線。CoAP基本上就是一個在Server和Client之間傳遞狀態信息的單對單協議。

HTTP協議

http的全稱是HyperText Transfer Protocol，超文本傳輸協議，這個協議的提出就是為了提供和接收HTML界面，通過這個協議在互聯網上面傳出web的界面信息。

HTTP協議的兩個過程，Request和Response，兩個都有各自的語言格式，我們看下是什么。

請求報文格式：(注意這里有個換行)

響應報文格式：(注意這里有個換行)

方法method：

這個很重要，比如說GET和POST方法，這兩個是很常用的，GET就是獲取什么內容，而POST就是向服務器發送什么數據。當然還有其他的，比如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/.這樣的格式，比如說HTTP/1.1.這個版本代表的就是我們使用的HTTP協議的版本，現在使用的一般是HTTP/1.1

狀態碼status:

狀態碼是三個數字，代表的是請求過程中所發生的情況，比如說200代表的是成功，404代表的是找不到文件。

原因短語reason-phrase：

是狀態碼的可讀版本，狀態碼就是一個數字，如果你事先不知道這個數字什么意思，可以先查看一下原因短語。

首部header：

注意這里的header我們不是叫做頭，而是叫做首部。可能有零個首部也可能有多個首部，每個首部包含一個名字后面跟著一個冒號，然后是一個可選的空格，接著是一個值，然后換行。

實體的主體部分entity-body：

實體的主體部分包含一個任意數據組成的數據塊，并不是所有的報文都包含實體的主體部分，有時候只是一個空行加換行就結束了。

下面我們舉個簡單的例子：

請求報文：

GET /index.html HTTP/1.1

Accept: text/*

Host:www.myweb.com

響應報文：

HTTP/1.1 200 OK

Content-type: text/plain

Content-length: 3

HTTP與CoAP的區別

CoAP是6LowPAN協議棧中的應用層協議，基于REST（表述性狀態傳遞）架構風格，支持與REST進行交互。通常用戶可以像使用HTTP協議一樣用CoAP協議來訪問物聯網設備。而且CoAP消息格式使用簡單的二進制格式，最小為4個字節。HTTP使用報文格式對于嵌入式設備來說需要傳輸數據太多，太重，不夠靈活。

XMPP協議

XMPP（可擴展通訊和表示協議）是一種基于可擴展標記語言（XML）的協議，

它繼承了在XML環境中靈活的發展性。可用于服務類實時通訊、表示和需求響應服務中的XML數據元流式傳輸。XMPP以Jabber協議為基礎，而Jabber是即時通訊中常用的開放式協議。

基本網絡結構

XMPP中定義了三個角色，客戶端，服務器，網關。通信能夠在這三者的任意兩個之間雙向發生。

服務器同時承擔了客戶端信息記錄，連接管理和信息的路由功能。網關承擔著與異構即時通信系統

的互聯互通，異構系統可以包括SMS（短信），MSN，ICQ等。基本的網絡形式是單客戶端通過

TCP/IP連接到單服務器，然后在之上傳輸XML。

功能

傳輸的是與即時通訊相關的指令。在以前這些命令要么用2進制的形式發送（比如QQ），

要么用純文本指令加空格加參數加換行符的方式發送（比如MSN）。而XMPP傳輸的即時通訊指令

的邏輯與以往相仿，只是協議的形式變成了XML格式的純文本。

舉個例子看看所謂的XML（標準通用標記語言的子集）流是什么樣子的？