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