序言
　　物聯(lián)網(wǎng)終端的種類非常多，包括物聯(lián)網(wǎng)網(wǎng)關(guān)、通信模塊以及大量的行業(yè)終端，其中尤以行業(yè)終端的種類最為豐富。通信模塊是物聯(lián)網(wǎng)應(yīng)用終端的基礎(chǔ)。物聯(lián)網(wǎng)的行業(yè)終端種類繁多，體積、處理能力、對外接口等各不相同，通信模塊將成為物聯(lián)網(wǎng)智能服務(wù)通道的統(tǒng)一承載體，嵌入各種行業(yè)終端，為各行各業(yè)提供物聯(lián)網(wǎng)的智能通道服務(wù)。而在通信中，通信協(xié)議尤其重要，是指雙方實體完成通信或服務(wù)所必須遵循的規(guī)則和約定，而且根據(jù)終端環(huán)境的不同對通信協(xié)議的要求完全不一致。
　　那么物聯(lián)網(wǎng)都有哪些通信協(xié)議？你都了解嗎？他們適用的環(huán)境又是如何？
　　與互聯(lián)網(wǎng)時代 TCP/IP，HTTP 一統(tǒng)天下的局面不同，物聯(lián)網(wǎng)的通信環(huán)境有 Ethernet， Wi-Fi， RFID， NFC（近距離無線通信）， Zigbee， 6LoWPAN（IPV6 低速無線版本），Bluetooth， GSM， GPRS， GPS， 3G， 4G 等網(wǎng)絡(luò)，而每一種通信應(yīng)用協(xié)議都有一定適用范圍。AMQP、JMS、REST/HTTP 都是工作在以太網(wǎng)，COAP 協(xié)議是專門為資源受限設(shè)備開發(fā)的協(xié)議，而 DDS 和 MQTT 的兼容性則強很多。
　　這兒舉個智能家居的例子，說明下這些協(xié)議側(cè)重應(yīng)用方向。智能家居中智能燈光控制，可以使用 XMPP 協(xié)議控制燈的開關(guān)；智能家居的電力供給，發(fā)電廠的發(fā)動機組的監(jiān)控可以使用 DDS 協(xié)議；當(dāng)電力輸送到千家萬戶時，電力線的巡查和維護，可以使用 MQTT 協(xié)議；家里的所有電器的電量消耗，可以使用 AMQP 協(xié)議，傳輸?shù)皆贫嘶蚣彝ゾW(wǎng)關(guān)中進行分析；最后用戶想把自家的能耗查詢服務(wù)公布到互聯(lián)網(wǎng)上，那么可以使用 REST/HTTP 來開放 API 服務(wù)。
　　下面我們將一一詳細(xì)介紹下這些協(xié)議：
　　1.REST（松耦合服務(wù)調(diào)用）
　　REST 即表述性狀態(tài)傳遞 （英文：Representational State Transfer，簡稱 REST） 是 Roy Fielding 博士在 2000 年他的博士論文中提出來的一種軟件架構(gòu)風(fēng)格。它是一種針對網(wǎng)絡(luò)應(yīng)用的設(shè)計和開發(fā)方式，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。
　　而 REST 被應(yīng)用于物聯(lián)網(wǎng)主要是基于 HTTP web 服務(wù)的轉(zhuǎn)化，因為 REST 模式的 Web 服務(wù)與復(fù)雜的 SOAP 和 XML-RPC 對比來講明顯的更加簡潔，越來越多的 web 服務(wù)開始采用 REST 風(fēng)格設(shè)計和實現(xiàn)。
　　特點：
　　給一切物體一個 ID
　　連接物體在一起
　　使用標(biāo)準(zhǔn)方法
　　資源多重表述
　　無狀態(tài)通信
　　REST 其實是互聯(lián)網(wǎng)中服務(wù)調(diào)用 API 封裝風(fēng)格，物聯(lián)網(wǎng)中數(shù)據(jù)采集到物聯(lián)網(wǎng)應(yīng)用系統(tǒng)中，在物聯(lián)網(wǎng)應(yīng)用系統(tǒng)中，可以通過開放 REST API 的方式，把數(shù)據(jù)服務(wù)開放出去，被互聯(lián)網(wǎng)中其他應(yīng)用所調(diào)用，所以它非常利于服務(wù)平臺與物聯(lián)終端的獨立開發(fā)，但它的通訊數(shù)據(jù)量與 API 內(nèi)容密切相關(guān)，且是一種無狀態(tài)通信，對安全機制需要重新設(shè)計。
　　2.CoAP 協(xié)議
　　由于物聯(lián)網(wǎng)中的很多設(shè)備都是資源受限型的，即只有少量的內(nèi)存空間和有限的計算能力，所以傳統(tǒng)的 HTTP 協(xié)議應(yīng)用在物聯(lián)網(wǎng)上就顯得過于龐大而不適用。 IETF 的 CoRE 工作組提出了一種基于 REST 架構(gòu)的 CoAP 協(xié)議。
　　CoAP 是一種應(yīng)用層協(xié)議，它運行于 UDP 協(xié)議之上而不是像 HTTP 那樣運行于 TCP 之上。CoAP 協(xié)議非常的小巧，最小的數(shù)據(jù)包僅為 4 字節(jié)。
　　CoAP 協(xié)議是否可以替換 HTTP 協(xié)議？
　　CoAP 并不能替代 HTTP 協(xié)議，但是對于那些小設(shè)備 （256KB Flash 32KB RAM 20MHz 主頻） 而言 CoAP 的確是一個好的解決方案。
　　CoAP 消息類型
　　CoAP 采用和 HTTP 協(xié)議相同的請求響應(yīng)工作模式。CoAP 協(xié)議共有 4 中不同的消息類型。
　　CON——需要被確認(rèn)的請求，如果 CON 請求被發(fā)送，那么對方必須做出響應(yīng)。
　　NON——不需要被確認(rèn)的請求，如果 NON 請求被發(fā)送，那么對方不必做出回應(yīng)。
　　ACK——應(yīng)答消息，如果接受到 CON 消息的響應(yīng)。
　　RST——復(fù)位消息，當(dāng)接收者接受到的消息包含一個錯誤，接受者解析消息或者不再關(guān)心發(fā)送者發(fā)送的內(nèi)容，那么復(fù)位消息將會被發(fā)送。
　　CoAP 消息結(jié)構(gòu)
　　一個 CoAP 消息最小為 4 個字節(jié)，以下是 CoAP 協(xié)議不同部分的描述。
　　【版本 Version】：類似于 IPv6 和 IPv6，僅僅是一個版本號。
　　【消息類型 Message Type】：CON，NON，ACK，RST。這些消息類型相當(dāng)于 HTTP 協(xié)議的 PUTGET 等
　　【消息 ID Message ID】：每個 CoAP 消息都有一個 ID，在一次會話中 ID 總是保持不變。但是在這個會話之后該 ID 會被回收利用。
　　【標(biāo)記 Token】：標(biāo)記是 ID 的另一種表現(xiàn)、
　　【選項 Options】：CoAP 選項類似于 HTTP 請求頭，它包括 CoAP 消息本身，例如 CoAP 端口號，CoAP 主機和 CoAP 查詢字符串等。
　　【負(fù)載 Payload】：真正有用的被交互的數(shù)據(jù)。
　　在當(dāng)前由 PC 機組成的世界，信息交換是通過 TCP 和應(yīng)用層協(xié)議 HTTP 實現(xiàn)的。但是對于小型設(shè)備而言，實現(xiàn) TCP 和 HTTP 協(xié)議顯然是一個過分的要求。為了讓小設(shè)備可以接入互聯(lián)網(wǎng)，CoAP 協(xié)議被設(shè)計出來。
　　3.MQTT 協(xié)議 （低帶寬）
　　MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協(xié)議），是一種基于發(fā)布 / 訂閱 （publish/subscribe） 模式的 “輕量級” 通訊協(xié)議，該協(xié)議構(gòu)建于 TCP/IP 協(xié)議上，由 IBM 在 1999 年發(fā)布。MQTT 最大優(yōu)點在于，可以以極少的代碼和有限的帶寬，為連接遠(yuǎn)程設(shè)備提供實時可靠的消息服務(wù)。做為一種低開銷、低帶寬占用的即時通訊協(xié)議，使其在物聯(lián)網(wǎng)、小型設(shè)備、移動應(yīng)用等方面有較廣泛的應(yīng)用。
　　MQTT 協(xié)議運行在 TCP/IP 或其他網(wǎng)絡(luò)協(xié)議，提供有序、無損、雙向連接。其特點包括：
　　1） 使用的發(fā)布 / 訂閱消息模式，它提供了一對多消息分發(fā)，以實現(xiàn)與應(yīng)用程序的解耦。
　　2） 對負(fù)載內(nèi)容屏蔽的消息傳輸機制。
　　3） 對傳輸消息有三種服務(wù)質(zhì)量 （QoS）：
　　最多一次，這一級別會發(fā)生消息丟失或重復(fù)，消息發(fā)布依賴于底層 TCP/IP 網(wǎng)絡(luò)。即：《=1 至多一次，這一級別會確保消息到達(dá)，但消息可能會重復(fù)。即：》=1
　　只有一次，確保消息只有一次到達(dá)。即：=1。在一些要求比較嚴(yán)格的計費系統(tǒng)中，可以使用此級別
　　4） 數(shù)據(jù)傳輸和協(xié)議交換的最小化 （協(xié)議頭部只有 2 字節(jié)），以減少網(wǎng)絡(luò)流量
　　5） 通知機制，異常中斷時通知傳輸雙方
　　適用范圍：在低帶寬、不可靠的網(wǎng)絡(luò)下提供基于云平臺的遠(yuǎn)程設(shè)備的數(shù)據(jù)傳輸和監(jiān)控。
　　協(xié)議實現(xiàn)方式
　　實現(xiàn) MQTT 協(xié)議需要：客戶端和服務(wù)器端
　　MQTT 協(xié)議中有三種身份：發(fā)布者 （Publish）、代理 （Broker）（服務(wù)器）、訂閱者 （Subscribe）。其中，消息的發(fā)布者和訂閱者都是客戶端，消息代理是服務(wù)器，消息發(fā)布者可以同時是訂閱者。
　　MQTT 傳輸?shù)南⒎譃椋褐黝} （Topic） 和負(fù)載 （payload） 兩部分
　　Topic，可以理解為消息的類型，訂閱者訂閱 （Subscribe） 后，就會收到該主題的消息內(nèi)容（payload）
　　payload，可以理解為消息的內(nèi)容，是指訂閱者具體要使用的內(nèi)容
　　MQTT 協(xié)議一般適用于設(shè)備數(shù)據(jù)采集到端 （Device-》Server，Device-》Gateway），集中星型網(wǎng)絡(luò)架構(gòu) （hub-and-spoke），不適用設(shè)備與設(shè)備之間通信，設(shè)備控制能力弱，另外實時性較差，一般都在秒級。
　　4.DDS 協(xié)議 （高可靠性、實時）
　　數(shù)據(jù)分發(fā)服務(wù) DDS（Data Distribution Service）是對象管理組織 （OMG） 在 HLA 及 CORBA 等標(biāo)準(zhǔn)的基礎(chǔ)上制定的新一代分布式實時通信中間件技術(shù)規(guī)范，DDS 采用發(fā)布 / 訂閱體系架構(gòu)，強調(diào)以數(shù)據(jù)為中心，提供豐富的 QoS 服務(wù)質(zhì)量策略，能保障數(shù)據(jù)進行實時、高效、靈活地分發(fā)，可滿足各種分布式實時通信應(yīng)用需求。DDS 信息分發(fā)中間件是一種輕便的、能夠提供實時信息傳送的中間件技術(shù)。
　　特點：
　　靈活的發(fā)布 / 訂閱模式
　　完整 DDS 規(guī)范 QoS 服務(wù)質(zhì)量策略
　　已擴展的 QoS 服務(wù)質(zhì)量策略
　　互操作
　　強實時
　　跨平臺