MQTT協(xié)議

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

MQTT協(xié)議的優(yōu)勢是可以支持所有平臺，它幾乎可以把所有的聯(lián)網(wǎng)物品和互聯(lián)網(wǎng)連接起來。

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

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

2、消息傳輸不需要知道負載內(nèi)容；

3、使用 TCP/IP 提供網(wǎng)絡連接；

4、有三種消息發(fā)布的服務質(zhì)量：

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

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

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

5、小型傳輸，開銷很?。ü潭ㄩL度的頭部是 2 字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡流量；

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

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

下圖是MQTT為可靠傳遞消息的三種消息發(fā)布服務質(zhì)量

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

下圖是MQTT的發(fā)布／訂閱消息模式

CoAP協(xié)議

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

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

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

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

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

主要是一對一的協(xié)議

舉個例子：

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

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

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

CoAP與MQTT的區(qū)別

MQTT和CoAP都是行之有效的物聯(lián)網(wǎng)協(xié)議，但兩者還是有很大區(qū)別的，比如MQTT協(xié)議是基于TCP，而CoAP協(xié)議是基于UDP。從應用方向來分析，主要區(qū)別有以下幾點：

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

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

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

HTTP協(xié)議

http的全稱是HyperText Transfer Protocol，超文本傳輸協(xié)議，這個協(xié)議的提出就是為了提供和接收HTML界面，通過這個協(xié)議在互聯(lián)網(wǎng)上面?zhèn)鞒鰓eb的界面信息。

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

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

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

方法method：

這個很重要，比如說GET和POST方法，這兩個是很常用的，GET就是獲取什么內(nèi)容，而POST就是向服務器發(fā)送什么數(shù)據(jù)。當然還有其他的，比如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協(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ù)據(jù)組成的數(shù)據(jù)塊，并不是所有的報文都包含實體的主體部分，有時候只是一個空行加換行就結(jié)束了。

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

請求報文：

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的區(qū)別

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

XMPP協(xié)議

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

它繼承了在XML環(huán)境中靈活的發(fā)展性?？捎糜诜疹悓崟r通訊、表示和需求響應服務中的XML數(shù)據(jù)元流式傳輸。XMPP以Jabber協(xié)議為基礎，而Jabber是即時通訊中常用的開放式協(xié)議。

基本網(wǎng)絡結(jié)構(gòu)

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

服務器同時承擔了客戶端信息記錄，連接管理和信息的路由功能。網(wǎng)關承擔著與異構(gòu)即時通信系統(tǒng)

的互聯(lián)互通，異構(gòu)系統(tǒng)可以包括SMS（短信），MSN，ICQ等?；镜木W(wǎng)絡形式是單客戶端通過

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

功能

傳輸?shù)氖桥c即時通訊相關的指令。在以前這些命令要么用2進制的形式發(fā)送（比如QQ），

要么用純文本指令加空格加參數(shù)加換行符的方式發(fā)送（比如MSN）。而XMPP傳輸?shù)募磿r通訊指令

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

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