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

合同一：物聯網合同XMPP

XMPP是一種基于原則通用標記語言的子集XML的合同，它繼承了在XML環境中靈活的發展性。因此，基于XMPP的應用品有超強的可擴展性。通過擴展后來的XMPP能夠通過發送擴展的信息來解決顧客的需求，以及在XMPP的頂端建立如內容公布系統和基于地址的服務等應用程序。并且，XMPP包含了針對服務器端的軟件合同，使之能與另一種進行通話，這使得開發者更容易建立客戶應用程序或給一種配好系統添加功效。

基本網絡構造

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

功效

傳輸的是與即時通訊有關的指令。在以前這些命令要么用2進制的形式發送（例如QQ），要么用純文本指令加空格加參數加換行符的方式發送（例如MSN）。而XMPP傳輸的即時通訊指令的邏輯與以往相仿，只是合同的形式變成了XML格式的純文本。

優點

XMPP合同是自由、開放、公開的，并且易于理解。并且在客戶端、服務器、組件、源碼庫等方面，都已經各自有多個實現。

缺點

網絡通信過程中數據冗余率非常高，網絡流量中70%都消耗在XMPP合同層了。對于物聯網來說，大量計算能力有限且工作在低帶寬、不可靠網絡的遠程傳感器和控制設備，省電、省流量是全部底層服務的一種核心技術指標，XMPP合同看起來已經落后了。

合同二：物聯網合同MQTT

MQTT（MessageQueuingTelemetryTransport，消息隊列遙測傳輸）是IBM開發的一種即時通訊合同，有可能成為物聯網的重要構成部分。該合同支持全部平臺，幾乎能夠把全部聯網物品和外部連接起來，被用來當做傳感器和致動器（例如通過Twitter讓房屋聯網）的通信合同。

MQTT介紹

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

·遙感數據

·汽車

·智能家居

·智慧都市

·醫療醫護

由于物聯網的環境是非常特別的，因此MQTT遵照下列設計原則：

1.精簡，不添加可有可無的功效。

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

3.允許顧客動態創立主題，零運維成本。

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

5.把低帶寬、高延遲、不穩定的網絡等因素考慮在內。

6.支持持續的會話控制。

7.理解客戶端計算能力可能很低。

8.提供服務質量管理。

9.假設數據不可知，不強求傳輸數據的類型與格式，保持靈活性。

運用MQTT合同，設備能夠很方便地連接到物聯網云服務，管理設備并解決數據，最后應用到多個業務場景，以下圖所示：

公布/訂閱模式

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

熟悉編程的同窗一定非常熟悉這種設計模式了，由于它帶來了這些好處：

·公布者與訂閱者不必理解彼此，只要認識同一種消息代理即可。

·公布者和訂閱者不需要交互，公布者無需等待訂閱者確認而造成鎖定。

·公布者和訂閱者不需要同時在線，能夠自由選擇時間來消費消息。

主題

MQTT是通過主題對消息進行分類的，本質上就是一種UTF-8的字符串，但是能夠通過反斜杠表達多個層級關系。主題并不需要創立，直接使用就是了。

主題還能夠通過通配符進行過濾。其中，+能夠過濾一種層級，而#只能出現在主題最后表達過濾任意級別的層級。

舉個例子：

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

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

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

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

服務質量

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

·級別0：極力而為。消息發送者會想盡方法發送消息，但是碰到意外并不會重試。

·級別1：最少一次。消息接受者如果沒有知會或者知會本身丟失，消息發送者會再次發送以確保消息接受者最少會收到一次，固然可能造成重復消息。

·級別2：正好一次。確保這種語義必定會減少并發或者增加延時，但是丟失或者重復消息是不可接受的時候，級別2是最適宜的。

服務質量是個老話題了。級別2所提供的不重不丟諸多狀況下是最抱負的，但是來回多次確實認一定對并發和延遲帶來影響。級別1提供的最少一次語義在日志解決這種場景下是完全OK的，因此像Kafka這類的系統運用這一特點減少確認從而大大提高了并發。級別0適合雞肋數據場景，食之無味棄之可惜，就這樣著吧。

消息類型

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

1.CONNECT：客戶端連接到MQTT代理

2.CONNACK：連接確認

3.PUBLISH：新公布消息

4.PUBACK：新公布消息確認，是QoS1給PUBLISH消息的回復

5.PUBREC：QoS2消息流的第一部分，表達消息公布已統計

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

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

8.SUBSCRIBE：客戶端訂閱某個主題

9.SUBACK：對于SUBSCRIBE消息確實認

10.UNSUBSCRIBE：客戶端終止訂閱的消息

11.UNSUBACK：對于UNSUBSCRIBE消息確實認

12.PINGREQ：心跳

13.PINGRESP：確認心跳

14.DISCONNECT：客戶端終止連接前優雅地告知MQTT代理

從現有的移動端（Android）消息推送方案中，也能夠看出MQTT合同和XMPP合同的優缺點

方案1、使用GCM服務（谷歌CloudMessaging）

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

優點：谷歌提供的服務、原生、簡樸，無需實現和布署服務端。

缺點：Android版本限制（必須不不大于2.2版本），該服務在國內不夠穩定、需要顧客綁定谷歌帳號，受限于谷歌。

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

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

優點：合同成熟、強大、可擴展性強、現在重要應用于許多聊天系統中，且已有開源的Java版的開發實例androidpn。

缺點：合同較復雜、冗余（基于XML）、費流量、費電，布署硬件成本高。

方案3、使用MQTT合同

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

優點：合同簡潔、小巧、可擴展性強、省流量、省電，現在已經應用到公司領域，且已有C++版的服務端組件rsmb。

缺點：不夠成熟、實現較復雜、服務端組件rsmb不開源，布署硬件成本較高。

方案4、使用HTTP輪循方式

介紹：定時向HTTP服務端接口（WebServiceAPI）獲取最新消息。

優點：實現簡樸、可控性強，布署硬件成本低。

缺點：實時性差。

合同三：物聯網合同CoAP

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

CoAP應用

CoAP采用與HTTP合同相似的請求響應工作模式。CoAP合同共有4中不同的消息類型。CON——需要被確認的請求，如果CON請求被發送，那么對方必須做出響應。NON——不需要被確認的請求，如果NON請求被發送，那么對方不必做出回應。ACK——應答消息，接受到CON消息的響應。RST——復位消息，當接受者接受到的消息包含一種錯誤，接受者解析消息或者不再關心發送者發送的內容，那么復位消息將會被發送。CoAP消息格式使用簡樸的二進制格式，最小為4個字節。一種消息=固定長度的頭部header+可選個數的option+負載payload。Payload的長度根據數據報長度來計算。重要是一對一的合同舉個例子：

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

合同四：物聯網合同RESTfulHTTP

REST指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是RESTful。

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