物聯(lián)網(wǎng)四大合同物聯(lián)網(wǎng)合同ProtocolXMPPMQTTCoAPRESTfulHTTPTransportTCPTCPUDPTCPMessagingPublish/SubscribeRequest/ResponsePublish/SubscribeRequest/ResponseRequest/ResponseRequest/Response2G,3G,4GSuitability(1000snodes)ExcellentExcellentExcellentExcellentLLNSuitability(1000snodes)FairFairExcellentFairComputeResources10KsRAM/Flash10KsRAM/Flash10KsRAM/Flash10KsRAM/FlashSuccessStoriedRemotemanagementofconsumerwhitegoodsExtendingenterprisemessagingintoIoTapplicationsUtilityFieldAreaNetworksSmartEnergyProfile2(premiseenergymanagement/homeservices)

合同一：物聯(lián)網(wǎng)合同XMPP

XMPP是一種基于原則通用標(biāo)記語(yǔ)言的子集XML的合同，它繼承了在XML環(huán)境中靈活的發(fā)展性。因此，基于XMPP的應(yīng)用品有超強(qiáng)的可擴(kuò)展性。通過(guò)擴(kuò)展后來(lái)的XMPP能夠通過(guò)發(fā)送擴(kuò)展的信息來(lái)解決顧客的需求，以及在XMPP的頂端建立如內(nèi)容公布系統(tǒng)和基于地址的服務(wù)等應(yīng)用程序。并且，XMPP包含了針對(duì)服務(wù)器端的軟件合同，使之能與另一種進(jìn)行通話(huà)，這使得開(kāi)發(fā)者更容易建立客戶(hù)應(yīng)用程序或給一種配好系統(tǒng)添加功效。

基本網(wǎng)絡(luò)構(gòu)造

XMPP中定義了三個(gè)角色，客戶(hù)端，服務(wù)器，網(wǎng)關(guān)。通信能夠在這三者的任意兩個(gè)之間雙向發(fā)生。服務(wù)器同時(shí)承當(dāng)了客戶(hù)端信息統(tǒng)計(jì)，連接管理和信息的路由功效。網(wǎng)關(guān)承當(dāng)著與異構(gòu)即時(shí)通信系統(tǒng)的互聯(lián)互通，異構(gòu)系統(tǒng)能夠涉及SMS（短信），MSN，ICQ等。基本的網(wǎng)絡(luò)形式是單客戶(hù)端通過(guò)TCP/IP連接到單服務(wù)器，然后在之上傳輸XML。工作原理XMPP核心合同通信的基本模式就是先建立一種stream，然后協(xié)商一堆安全之類(lèi)的東西，中間通信過(guò)程就是客戶(hù)端發(fā)送XMLStanza，一種接一種的。服務(wù)器根據(jù)客戶(hù)端發(fā)送的信息以及程序的邏輯，發(fā)送XMLStanza給客戶(hù)端。但是這個(gè)過(guò)程并不是一問(wèn)一答的，任何時(shí)候都有可能從一方發(fā)信給另外一方。通信的最后階段是關(guān)閉流，關(guān)閉TCP/IP連接。

功效

傳輸?shù)氖桥c即時(shí)通訊有關(guān)的指令。在以前這些命令要么用2進(jìn)制的形式發(fā)送（例如QQ），要么用純文本指令加空格加參數(shù)加換行符的方式發(fā)送（例如MSN）。而XMPP傳輸?shù)募磿r(shí)通訊指令的邏輯與以往相仿，只是合同的形式變成了XML格式的純文本。

優(yōu)點(diǎn)

XMPP合同是自由、開(kāi)放、公開(kāi)的，并且易于理解。并且在客戶(hù)端、服務(wù)器、組件、源碼庫(kù)等方面，都已經(jīng)各自有多個(gè)實(shí)現(xiàn)。

缺點(diǎn)

網(wǎng)絡(luò)通信過(guò)程中數(shù)據(jù)冗余率非常高，網(wǎng)絡(luò)流量中70%都消耗在XMPP合同層了。對(duì)于物聯(lián)網(wǎng)來(lái)說(shuō)，大量計(jì)算能力有限且工作在低帶寬、不可靠網(wǎng)絡(luò)的遠(yuǎn)程傳感器和控制設(shè)備，省電、省流量是全部底層服務(wù)的一種核心技術(shù)指標(biāo)，XMPP合同看起來(lái)已經(jīng)落后了。

合同二：物聯(lián)網(wǎng)合同MQTT

MQTT（MessageQueuingTelemetryTransport，消息隊(duì)列遙測(cè)傳輸）是IBM開(kāi)發(fā)的一種即時(shí)通訊合同，有可能成為物聯(lián)網(wǎng)的重要構(gòu)成部分。該合同支持全部平臺(tái)，幾乎能夠把全部聯(lián)網(wǎng)物品和外部連接起來(lái)，被用來(lái)當(dāng)做傳感器和致動(dòng)器（例如通過(guò)Twitter讓房屋聯(lián)網(wǎng)）的通信合同。

MQTT介紹

MQTT是基于二進(jìn)制消息的公布/訂閱編程模式的消息合同，最早由IBM提出的，如今已經(jīng)成為OASIS規(guī)范。由于規(guī)范很簡(jiǎn)樸，非常適合需要低功耗和網(wǎng)絡(luò)帶寬有限的IoT場(chǎng)景，例如：

·遙感數(shù)據(jù)

·汽車(chē)

·智能家居

·智慧都市

·醫(yī)療醫(yī)護(hù)

由于物聯(lián)網(wǎng)的環(huán)境是非常特別的，因此MQTT遵照下列設(shè)計(jì)原則：

1.精簡(jiǎn)，不添加可有可無(wú)的功效。

2.公布/訂閱（Pub/Sub）模式，方便消息在傳感器之間傳遞。

3.允許顧客動(dòng)態(tài)創(chuàng)立主題，零運(yùn)維成本。

4.把傳輸量降到最低以提高傳輸效率。

5.把低帶寬、高延遲、不穩(wěn)定的網(wǎng)絡(luò)等因素考慮在內(nèi)。

6.支持持續(xù)的會(huì)話(huà)控制。

7.理解客戶(hù)端計(jì)算能力可能很低。

8.提供服務(wù)質(zhì)量管理。

9.假設(shè)數(shù)據(jù)不可知，不強(qiáng)求傳輸數(shù)據(jù)的類(lèi)型與格式，保持靈活性。

運(yùn)用MQTT合同，設(shè)備能夠很方便地連接到物聯(lián)網(wǎng)云服務(wù)，管理設(shè)備并解決數(shù)據(jù)，最后應(yīng)用到多個(gè)業(yè)務(wù)場(chǎng)景，以下圖所示：

公布/訂閱模式

與請(qǐng)求/回答這種同時(shí)模式不同，公布/訂閱模式解耦了公布消息的客戶(hù)（公布者）與訂閱消息的客戶(hù)（訂閱者）之間的關(guān)系，這意味著公布者和訂閱者之間并不需要直接建立聯(lián)系。打個(gè)比方，你打電話(huà)給朋友，始終要等到朋友接電話(huà)了才干夠開(kāi)始交流，是一種典型的同時(shí)請(qǐng)求/回答的場(chǎng)景；而給一種好友郵件列表發(fā)電子郵件就不同，你發(fā)好電子郵件該干嘛干嘛，好友們到有空了去查看郵件就是了，是一種典型的異步公布/訂閱的場(chǎng)景。

熟悉編程的同窗一定非常熟悉這種設(shè)計(jì)模式了，由于它帶來(lái)了這些好處：

·公布者與訂閱者不必理解彼此，只要認(rèn)識(shí)同一種消息代理即可。

·公布者和訂閱者不需要交互，公布者無(wú)需等待訂閱者確認(rèn)而造成鎖定。

·公布者和訂閱者不需要同時(shí)在線，能夠自由選擇時(shí)間來(lái)消費(fèi)消息。

主題

MQTT是通過(guò)主題對(duì)消息進(jìn)行分類(lèi)的，本質(zhì)上就是一種UTF-8的字符串，但是能夠通過(guò)反斜杠表達(dá)多個(gè)層級(jí)關(guān)系。主題并不需要?jiǎng)?chuàng)立，直接使用就是了。

主題還能夠通過(guò)通配符進(jìn)行過(guò)濾。其中，+能夠過(guò)濾一種層級(jí)，而#只能出現(xiàn)在主題最后表達(dá)過(guò)濾任意級(jí)別的層級(jí)。

舉個(gè)例子：

·building-b/floor-5：代表B樓5層的設(shè)備。

·+/floor-5：代表任何一種樓的5層的設(shè)備。

·building-b/#：代表B樓全部的設(shè)備。

注意，MQTT允許使用通配符訂閱主題，但是并不允許使用通配符廣播。

服務(wù)質(zhì)量

為了滿(mǎn)足不同的場(chǎng)景，MQTT支持三種不同級(jí)別的服務(wù)質(zhì)量（QualityofService，QoS）為不同場(chǎng)景提供消息可靠性：

·級(jí)別0：極力而為。消息發(fā)送者會(huì)想盡方法發(fā)送消息，但是碰到意外并不會(huì)重試。

·級(jí)別1：最少一次。消息接受者如果沒(méi)有知會(huì)或者知會(huì)本身丟失，消息發(fā)送者會(huì)再次發(fā)送以確保消息接受者最少會(huì)收到一次，固然可能造成重復(fù)消息。

·級(jí)別2：正好一次。確保這種語(yǔ)義必定會(huì)減少并發(fā)或者增加延時(shí)，但是丟失或者重復(fù)消息是不可接受的時(shí)候，級(jí)別2是最適宜的。

服務(wù)質(zhì)量是個(gè)老話(huà)題了。級(jí)別2所提供的不重不丟諸多狀況下是最抱負(fù)的，但是來(lái)回多次確實(shí)認(rèn)一定對(duì)并發(fā)和延遲帶來(lái)影響。級(jí)別1提供的最少一次語(yǔ)義在日志解決這種場(chǎng)景下是完全OK的，因此像Kafka這類(lèi)的系統(tǒng)運(yùn)用這一特點(diǎn)減少確認(rèn)從而大大提高了并發(fā)。級(jí)別0適合雞肋數(shù)據(jù)場(chǎng)景，食之無(wú)味棄之可惜，就這樣著吧。

消息類(lèi)型

MQTT擁有14種不同的消息類(lèi)型：

1.CONNECT：客戶(hù)端連接到MQTT代理

2.CONNACK：連接確認(rèn)

3.PUBLISH：新公布消息

4.PUBACK：新公布消息確認(rèn)，是QoS1給PUBLISH消息的回復(fù)

5.PUBREC：QoS2消息流的第一部分，表達(dá)消息公布已統(tǒng)計(jì)

6.PUBREL：QoS2消息流的第二部分，表達(dá)消息公布已釋放

7.PUBCOMP：QoS2消息流的第三部分，表達(dá)消息公布完畢

8.SUBSCRIBE：客戶(hù)端訂閱某個(gè)主題

9.SUBACK：對(duì)于SUBSCRIBE消息確實(shí)認(rèn)

10.UNSUBSCRIBE：客戶(hù)端終止訂閱的消息

11.UNSUBACK：對(duì)于UNSUBSCRIBE消息確實(shí)認(rèn)

12.PINGREQ：心跳

13.PINGRESP：確認(rèn)心跳

14.DISCONNECT：客戶(hù)端終止連接前優(yōu)雅地告知MQTT代理

從現(xiàn)有的移動(dòng)端（Android）消息推送方案中，也能夠看出MQTT合同和XMPP合同的優(yōu)缺點(diǎn)

方案1、使用GCM服務(wù)（谷歌CloudMessaging）

介紹：谷歌推出的云消息服務(wù)，即第二代的G2DM。

優(yōu)點(diǎn)：谷歌提供的服務(wù)、原生、簡(jiǎn)樸，無(wú)需實(shí)現(xiàn)和布署服務(wù)端。

缺點(diǎn)：Android版本限制（必須不不大于2.2版本），該服務(wù)在國(guó)內(nèi)不夠穩(wěn)定、需要顧客綁定谷歌帳號(hào)，受限于谷歌。

方案2、使用XMPP合同（Openfire+Spark+Smack）

介紹：基于XML合同的通訊合同，前身是Jabber，現(xiàn)在已由IETF國(guó)際原則化組織完畢了原則化工作。

優(yōu)點(diǎn)：合同成熟、強(qiáng)大、可擴(kuò)展性強(qiáng)、現(xiàn)在重要應(yīng)用于許多聊天系統(tǒng)中，且已有開(kāi)源的Java版的開(kāi)發(fā)實(shí)例androidpn。

缺點(diǎn)：合同較復(fù)雜、冗余（基于XML）、費(fèi)流量、費(fèi)電，布署硬件成本高。

方案3、使用MQTT合同

介紹：輕量級(jí)的、基于代理的“公布/訂閱”模式的消息傳輸合同。

優(yōu)點(diǎn)：合同簡(jiǎn)潔、小巧、可擴(kuò)展性強(qiáng)、省流量、省電，現(xiàn)在已經(jīng)應(yīng)用到公司領(lǐng)域，且已有C++版的服務(wù)端組件rsmb。

缺點(diǎn)：不夠成熟、實(shí)現(xiàn)較復(fù)雜、服務(wù)端組件rsmb不開(kāi)源，布署硬件成本較高。

方案4、使用HTTP輪循方式

介紹：定時(shí)向HTTP服務(wù)端接口（WebServiceAPI）獲取最新消息。

優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)樸、可控性強(qiáng)，布署硬件成本低。

缺點(diǎn)：實(shí)時(shí)性差。

合同三：物聯(lián)網(wǎng)合同CoAP

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

CoAP應(yīng)用

CoAP采用與HTTP合同相似的請(qǐng)求響應(yīng)工作模式。CoAP合同共有4中不同的消息類(lèi)型。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)接受者接受到的消息包含一種錯(cuò)誤，接受者解析消息或者不再關(guān)心發(fā)送者發(fā)送的內(nèi)容，那么復(fù)位消息將會(huì)被發(fā)送。CoAP消息格式使用簡(jiǎn)樸的二進(jìn)制格式，最小為4個(gè)字節(jié)。一種消息=固定長(zhǎng)度的頭部header+可選個(gè)數(shù)的option+負(fù)載payload。Payload的長(zhǎng)度根據(jù)數(shù)據(jù)報(bào)長(zhǎng)度來(lái)計(jì)算。重要是一對(duì)一的合同舉個(gè)例子：

例如某個(gè)設(shè)備需要從服務(wù)器端查詢(xún)現(xiàn)在溫度信息。請(qǐng)求消息（CON）：GET/temperature,請(qǐng)求內(nèi)容會(huì)被包在CON消息里面響應(yīng)消息(ACK)：2.05Content“22.5C”，響應(yīng)內(nèi)容會(huì)被放在ACK消息里面CoAP與MQTT的區(qū)別MQTT和CoAP都是行之有效的物聯(lián)網(wǎng)合同，但兩者還是有很大區(qū)別的，例如MQTT合同是基于TCP，而CoAP合同是基于UDP。從應(yīng)用方向來(lái)分析，重要區(qū)別有下列幾點(diǎn)：1、MQTT合同不支持帶有類(lèi)型或者其它協(xié)助Clients理解的標(biāo)簽信息，也就是說(shuō)全部MQTTClients必須要懂得消息格式。而CoAP合同則相反，由于CoAP內(nèi)置發(fā)現(xiàn)支持和內(nèi)容協(xié)商，這樣便能允許設(shè)備互相窺測(cè)以找到數(shù)據(jù)交換的方式。2、MQTT是長(zhǎng)連接而CoAP是無(wú)連接。MQTTClients與Broker之間保持TCP長(zhǎng)連接，這種情形在NAT環(huán)境中也不會(huì)產(chǎn)生問(wèn)題。如果在NAT環(huán)境下使用CoAP的話(huà)，那就需要采用某些NAT穿透性手段。3、MQTT是多個(gè)客戶(hù)端通過(guò)中央代理進(jìn)行消息傳遞的多對(duì)多合同。它重要通過(guò)讓客戶(hù)端公布消息、代理決定消息路由和復(fù)制來(lái)解耦消費(fèi)者和生產(chǎn)者。MQTT就是相稱(chēng)于消息傳遞的實(shí)時(shí)通訊總線。CoAP基本上就是一種在Server和Client之間傳遞狀態(tài)信息的單對(duì)單合同。

合同四：物聯(lián)網(wǎng)合同RESTfulHTTP

REST指的是一組架構(gòu)約束條件和原則。滿(mǎn)足這些約束條件和原則的應(yīng)用程序或設(shè)計(jì)就是RESTful。

Web應(yīng)用程序最重要的REST原則是，客戶(hù)端和服務(wù)器之間的交互在請(qǐng)求之間是無(wú)狀態(tài)的。從客戶(hù)端到服務(wù)器的每個(gè)請(qǐng)求都必須包含理解請(qǐng)求所必需的信息。如果服務(wù)器在請(qǐng)求之間的任何時(shí)間點(diǎn)重啟，客戶(hù)端不會(huì)得到告知。另外，無(wú)狀態(tài)請(qǐng)求能夠由任何可用服務(wù)器回答，這十分適合云計(jì)算之類(lèi)的環(huán)境?？蛻?hù)端能夠緩存數(shù)據(jù)以改善性能。RESTful的核心是定義可表達(dá)流程元素/資源的對(duì)象。在REST中，每一種對(duì)象都是通過(guò)URL來(lái)表達(dá)的，對(duì)象顧客負(fù)責(zé)將狀態(tài)信息打包進(jìn)每一條消息內(nèi)，方便對(duì)象的解決總是無(wú)狀態(tài)的。RESTful的第二大問(wèn)題是組合管理及流程綁定。公司對(duì)正規(guī)的（基于SOAP）SOA最大的反對(duì)聲之一便是，這種等級(jí)的發(fā)現(xiàn)和綁定靈活性局限性以適應(yīng)復(fù)雜性。SoAP合同：SoAP(簡(jiǎn)樸對(duì)象訪問(wèn)合同)是交換數(shù)據(jù)的一種合同規(guī)范，是一種輕量的、簡(jiǎn)樸的、基