目錄
1、HTTP和websocket
2、XMPP
3、COAP
4、MQTT協定
5、DDS
對于物聯網，最重要的是在網際網路中裝置與裝置的通訊，現在物聯網在internet通信中比較常見的通訊協定包括：HTTP、websocket、XMPP、COAP、MQTT
在網際網路時代，TCP/IP協定已經一統江湖，現在的物聯網的通信架構也是建構在傳統網際網路基礎架構之上。在目前的網際網路通信協定中，HTTP協定由于開發成本低，開放程度高，幾乎占據大半江山，是以很多廠商在建構物聯網系統時也基于http協定進行開發。包括google主導的physic web項目，都是期望在傳統web技術基礎上建構物聯網協定标準。
HTTP協定是典型的CS通訊模式，由用戶端主動發起連接配接，向伺服器請求XML或JSON資料。該協定最早是為了适用web浏覽器的上網浏覽場景和設計的，目前在PC、手機、pad等終端上都應用廣泛，但并不适用于物聯網場景。在物聯網場景中其有三大弊端：
1. 由于必須由裝置主動向伺服器發送資料，難以主動向裝置推送資料。對于單單的資料采集等場景還勉強适用，但是對于頻繁的操控場景，隻能推過裝置定期主動拉取的的方式，實作成本和實時性都大打折扣。
2. 安全性不高。web的不安全都是婦孺皆知，HTTP是明文協定，在很多要求高安全性的物聯網場景，如果不做很多安全準備工作（如采用https等），後果不堪設想…
3. 不同于使用者互動終端如pc、手機，物聯網場景中的裝置多樣化，對于運算和存儲資源都十分受限的裝置，http協定實作、XML/JSON資料格式的解析，都是“mission impossible”
HTTP的連接配接問題，HTTP用戶端和伺服器之間的互動是采用請求/應答模式，在用戶端請求時，會建立一個HTTP連接配接，然後發送請求消息，服務端給出應答消息，然後連接配接就關閉了。（後來的HTTP1.1支援持久連接配接）
因為TCP連接配接的建立過程是有開銷的，如果使用了SSL/TLS開銷就更大。
在浏覽器裡，一個網頁包含許多資源，包括HTML，CSS，JavaScript，圖檔等等，這樣在加載一個網頁時要同時打開連接配接到同一伺服器的多個連接配接。
HTTP消息頭問題，現在的用戶端會發送大量的HTTP消息頭，由于一個網頁可能需要50-100個請求，就會有相當大的消息頭的資料量。
HTTP通信方式問題，HTTP的請求/應答方式的會話都是用戶端發起的，缺乏伺服器通知用戶端的機制，在需要通知的場景，如聊天室，遊戲，用戶端應用需要不斷地輪詢伺服器。
當然，依然有不少廠商由于開發友善的原因，選擇基于HTTP協定構架物聯網系統，在裝置資源允許的情況下，怎麼避免上面提到的資料推送實時性低的問題呢？
websocket是一個可行的辦法。websocket是HTML5提出的基于TCP之上的可支援全雙工通信的協定标準，其在設計上基本遵循HTTP的思路，對于基于HTTP協定的物聯網系統是一個很好的補充。
但是問題是：http+websocket的方式，協定開銷代價太大。如果讓一個單片機去實作這樣的協定，性能會很吃力。
由于物聯網裝置通信的模式和網際網路中的即時通訊應用非常相似，網際網路中常用的即時通訊協定也被大量運用于物聯網系統建構中，這其中的典型是XMPP。
XMPP是基于XML的協定，由于其開放性和易用性，在網際網路及時通訊應用中運用廣泛。相對HTTP，XMPP在通訊的業務流程上是更适合物聯網系統的，開發者不用花太多心思去解決裝置通訊時的業務通訊流程，相對開發成本會更低。但是HTTP協定中的安全性以及計算資源消耗的硬傷并沒有得到本質的解決。前段時間報出的黑客輕松破解的TCL洗衣機，正是采用XMPP協定。
無論是HTTP、websocket還是XMPP，在設計時都是根據網際網路應用場景設計的，雖然很多廠商把他們應用在物聯網系統中，但是必然會水土不服，這些協定的通病就是根本無法适用物聯網裝置的多樣性，無法适用很多物聯網裝置對低功耗、低成本的需求，難以在極低資源的物聯網裝置中運用。能不能有協定既可以借用web技術的設計思想，同時又能适應惡劣的物聯網裝置運作環境呢？
COAP協定的設計目标就是在低功耗低速率的裝置上實作物聯網通信。coap和HTTP協定一樣，采用URL标示需要發送的資料，在協定格式的設計上也基本是參考HTTP協定，非常容易了解。同時做了以下幾點優化：
1. 采用UDP而不是TCP。這省去了TCP建立連接配接的成本及協定棧的開銷。
2. 将資料標頭部都采用二進制壓縮，減小資料量以适應低網絡速率場景。
3. 發送和接收資料可以異步進行，這樣提升了裝置響應速度。
COAP協定就像一個針對物聯網場景的http移植品，很多設計保留了HTTP協定的影子，擁有web背景的開發者也能快速上手。但是由于很多物聯網裝置隐藏在區域網路内部，coap裝置作為伺服器無法被外部裝置尋址，在ipv6沒有普及之前，coap隻能适用于區域網路内部（如wifi）通信，這也很大限制了它的發展。
MQTT協定就很好的解決了coap存在的問題。MQTT協定是由IBM開發的即時通訊協定，相比來說比較适合物聯網場景的通訊協定。MQTT協定采用釋出/訂閱模式，所有的物聯網終端都通過TCP連接配接到雲端，雲端通過主題的方式管理各個裝置關注的通訊内容，負責将裝置與裝置之間消息的轉發。
1.使用釋出/訂閱消息模式，提供一對多的消息釋出，解除應用程式耦合。
2.對負載内容屏蔽的消息傳輸。
3.使用 TCP/IP 提供網絡連接配接。
4.有三種消息釋出服務品質：
"至多一次"，消息釋出完全依賴底層 TCP/IP 網絡。會發生消息丢失或重複。這一級别可用于如下情況，環境傳感器資料，丢失一次讀記錄無所謂，因為不久後還會有第二次發送。
"至少一次"，確定消息到達，但消息重複可能會發生。
"隻有一次"，確定消息到達一次。這一級别可用于如下情況，在計費系統中，消息重複或丢失會導緻不正确的結果。
5.小型傳輸，開銷很小（固定長度的頭部是 2 位元組），協定交換最小化，以降低網絡流量。
6.使用 Last Will 和 Testament 特性通知有關各方用戶端異常中斷的機制。
MQTT在協定設計時就考慮到不同裝置的計算性能的差異，是以所有的協定都是采用二進制格式編解碼，并且編解碼格式都非常易于開發和實作。最小的資料包隻有2個位元組，對于低功耗低速網絡也有很好的适應性。有非常完善的QOS機制，根據業務場景可以選擇最多一次、至少一次、剛好一次三種消息送達模式。運作在TCP協定之上，同時支援TLS（TCP+SSL）協定，并且由于所有資料通信都經過雲端，安全性得到了較好地保障。
目前的物聯網通信協定真的是百花齊放，沒有任何協定能夠在市場上占有統治地位。但要實作物聯網裝置互聯互通（不同廠商、不同平台、不同架構），關鍵點并不在上述接入協定或通訊協定的統一，而在于上層業務應用層協定的統一。無論是wifi、藍牙、亦或是mqtt、http都是裝置進行資料通訊和交換的通道，規定的是通訊的格式；而通訊的内容的統一才是實作互聯互通的關鍵。
DDS（Data Distribution Service for Real-Time Systems），面向實時系統的資料分布服務，這是大名鼎鼎的OMG組織提出的協定，其權威性應該能證明該協定的未來應用前景。
适用範圍：分布式高可靠性、實時傳輸裝置資料通信。目前DDS已經廣泛應用于國防、民航、工業控制等領域。
特點：
• 以資料為中心
• 使用無代理的釋出/訂閱消息模式，點對點、點對多、多對多
• 提供多大21種QoS服務品質政策
協定主要實作：
• OpenDDS 是一個開源的 C++ 實作
• OpenSplice DDS
DDS很好地支援裝置之間的資料分發和裝置控制，裝置和雲端的資料傳輸，同時DDS的資料分發的實時效率非常高，能做到秒級内同時分發百萬條消息到衆多裝置。DDS在服務品質（QoS）上提供非常多的保障途徑，這也是它适用于國防軍事、工業控制這些高可靠性、可安全性應用領域的原因。但這些應用都工作在有線網絡下，在無線網絡，特别是資源受限的情況下，沒有見到過實施案例。