MQTT協(xié)議

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

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

它具有以下主要的幾項(xiàng)特性：

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

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

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

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

QoS 0：“最多一次”，消息發(fā)布完全依賴底層 TCP/IP 網(wǎng)絡(luò)。分發(fā)的消息可能丟失或重復(fù)。例如，這個(gè)等級(jí)可用于環(huán)境傳感器數(shù)據(jù)，單次的數(shù)據(jù)丟失沒關(guān)系，因?yàn)椴痪煤筮€會(huì)有第二次發(fā)送。

QoS 1：“至少一次”，確保消息可以到達(dá)，但消息可能會(huì)重復(fù)。

QoS 2：“只有一次”，確保消息只到達(dá)一次。例如，這個(gè)等級(jí)可用在一個(gè)計(jì)費(fèi)系統(tǒng)中，這里如果消息重復(fù)或丟失會(huì)導(dǎo)致不正確的收費(fèi)。

5、小型傳輸，開銷很小（固定長(zhǎng)度的頭部是 2 字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量；

6、使用 Last Will 和 Testament 特性通知有關(guān)各方客戶端異常中斷的機(jī)制；

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

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

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

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

CoAP協(xié)議

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

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

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

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

一個(gè)消息=固定長(zhǎng)度的頭部header + 可選個(gè)數(shù)的option + 負(fù)載payload。Payload的長(zhǎng)度根據(jù)數(shù)據(jù)報(bào)長(zhǎng)度來計(jì)算。

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

舉個(gè)例子：

比如某個(gè)設(shè)備需要從服務(wù)器端查詢當(dāng)前溫度信息。

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

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

CoAP與MQTT的區(qū)別

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

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

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

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

HTTP協(xié)議

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

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

請(qǐng)求報(bào)文格式：(注意這里有個(gè)換行)

響應(yīng)報(bào)文格式：(注意這里有個(gè)換行)

方法method：

這個(gè)很重要，比如說GET和POST方法，這兩個(gè)是很常用的，GET就是獲取什么內(nèi)容，而POST就是向服務(wù)器發(fā)送什么數(shù)據(jù)。當(dāng)然還有其他的，比如HTTP 1.1中還有：DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8個(gè)方法（HTTP Method歷史：HTTP 0.9 只有GET方法；HTTP 1.0 有GET、POST、HEAD三個(gè)方法）。

請(qǐng)求URL:

這里填寫的URL是不包含IP地址或者域名的，是主機(jī)本地文件對(duì)應(yīng)的目錄地址，所以我們一般看到的就是“/”。

版本version：

格式是HTTP/.這樣的格式，比如說HTTP/1.1.這個(gè)版本代表的就是我們使用的HTTP協(xié)議的版本，現(xiàn)在使用的一般是HTTP/1.1

狀態(tài)碼status:

狀態(tài)碼是三個(gè)數(shù)字，代表的是請(qǐng)求過程中所發(fā)生的情況，比如說200代表的是成功，404代表的是找不到文件。

原因短語reason-phrase：

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

首部header：

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

實(shí)體的主體部分entity-body：

實(shí)體的主體部分包含一個(gè)任意數(shù)據(jù)組成的數(shù)據(jù)塊，并不是所有的報(bào)文都包含實(shí)體的主體部分，有時(shí)候只是一個(gè)空行加換行就結(jié)束了。

下面我們舉個(gè)簡(jiǎn)單的例子：

請(qǐng)求報(bào)文：

GET /index.html HTTP/1.1

Accept: text/*

Host:www.myweb.com

響應(yīng)報(bào)文：

HTTP/1.1 200 OK

Content-type: text/plain

Content-length: 3

HTTP與CoAP的區(qū)別

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

XMPP協(xié)議

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

它繼承了在XML環(huán)境中靈活的發(fā)展性。可用于服務(wù)類實(shí)時(shí)通訊、表示和需求響應(yīng)服務(wù)中的XML數(shù)據(jù)元流式傳輸。XMPP以Jabber協(xié)議為基礎(chǔ)，而Jabber是即時(shí)通訊中常用的開放式協(xié)議。

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

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

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

的互聯(lián)互通，異構(gòu)系統(tǒng)可以包括SMS（短信），MSN，ICQ等。基本的網(wǎng)絡(luò)形式是單客戶端通過

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

功能

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

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

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

舉個(gè)例子看看所謂的XML（標(biāo)準(zhǔn)通用標(biāo)記語言的子集）流是什么樣子的？