對於物聯網，最重要的是在互聯網中設備與設備的通訊，現在物聯網在internet通信中比較常見的通訊協議包括：HTTP、websocket、XMPP、COAP、MQTT
1、HTTP和websocket
在互聯網時代，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的方式，協議開銷代價太大。如果讓一個單片機去實現這樣的協議，性能會很吃力。
2、XMPP
由於物聯網設備通信的模式和互聯網中的即時通訊應用非常相似，互聯網中常用的即時通訊協議也被大量運用於物聯網系統構建中，這其中的典型是XMPP。
XMPP是基於XML的協議，由於其開放性和易用性，在互聯網及時通訊應用中運用廣泛。相對HTTP，XMPP在通訊的業務流程上是更適合物聯網系統的，開發者不用花太多心思去解決設備通訊時的業務通訊流程，相對開發成本會更低。但是HTTP協議中的安全性以及計算資源消耗的硬傷並沒有得到本質的解決。前段時間報出的黑客輕鬆破解的TCL洗衣機，正是採用XMPP協議。
無論是HTTP、websocket還是XMPP，在設計時都是根據互聯網應用場景設計的，雖然很多廠商把他們應用在物聯網系統中，但是必然會水土不服，這些協議的通病就是根本無法適用物聯網設備的多樣性，無法適用很多物聯網設備對低功耗、低成本的需求，難以在極低資源的物聯網設備中運用。能不能有協議既可以借用web技術的設計思想，同時又能適應惡劣的物聯網設備運行環境呢？
3、COAP
COAP協議的設計目標就是在低功耗低速率的設備上實現物聯網通信。coap和HTTP協議一樣，採用URL標示需要發送的數據，在協議格式的設計上也基本是參考HTTP協議，非常容易理解。同時做了以下幾點優化：
1. 採用UDP而不是TCP。這省去了TCP建立連接的成本及協議棧的開銷。
2. 將數據包頭部都採用二進制壓縮，減小數據量以適應低網絡速率場景。
3. 發送和接收數據可以異步進行，這樣提升了設備響應速度。
COAP協議就像一個針對物聯網場景的http移植品，很多設計保留了HTTP協議的影子，擁有web背景的開發者也能快速上手。但是由於很多物聯網設備隱藏在局域網內部，coap設備作爲服務器無法被外部設備尋址，在ipv6沒有普及之前，coap只能適用於局域網內部（如wifi）通信，這也很大限制了它的發展。
4、MQTT協議
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都是設備進行數據通訊和交換的通道，規定的是通訊的格式；而通訊的內容的統一纔是實現互聯互通的關鍵。
5、DDS
DDS（Data Distribution Service for Real-Time Systems），面向實時系統的數據分佈服務，這是大名鼎鼎的OMG組織提出的協議，其權威性應該能證明該協議的未來應用前景。
適用範圍：分佈式高可靠性、實時傳輸設備數據通信。目前DDS已經廣泛應用於國防、民航、工業控制等領域。
特點：
• 以數據爲中心
• 使用無代理的發佈/訂閱消息模式，點對點、點對多、多對多
• 提供多大21種QoS服務質量策略
協議主要實現：
• OpenDDS 是一個開源的 C++ 實現
• OpenSplice DDS
DDS很好地支持設備之間的數據分發和設備控制，設備和雲端的數據傳輸，同時DDS的數據分發的實時效率非常高，能做到秒級內同時分發百萬條消息到衆多設備。DDS在服務質量（QoS）上提供非常多的保障途徑，這也是它適用於國防軍事、工業控制這些高可靠性、可安全性應用領域的原因。但這些應用都工作在有線網絡下，在無線網絡，特別是資源受限的情況下，沒有見到過實施案例。