物聯網常用的網路協議：MQTT、AMQP、HTTP、CoAP、LwM2M

物聯網設備間溝通的語言，就是網路協議，
設備間想相互交流，通信雙方必須使用同一種“語言”，比如說你和中國人問好說’你好‘、日本人問好要說‘こんにちは’、和英國人問好要說‘hello’.
說起網路協議，你可能馬上就想到了 HTTP 協議，是的，在日常的 Web 開發中，我們總是需要跟它打交道，因為 HTTP 協議是互聯網的主流網路協議，類似地，應用在互聯網中的網路協議，還有收發電子郵件的 POP3 、SMTP 和 IMAP 協議，以及用于區塊鏈中的 P2P 協議，

具體需要用什么協議我們需要根據物聯網的特點來做決定物聯網的網路通信特點是物聯網設備很大可能作業在不可靠、高延遲的網路環境中，
比如共享單車，使用 NB-IoT 這樣的通信技術，本身的通信速率就只有不到幾十 Kbps；要是被人停在城市的角落里，信號可能很不穩定，假設你使用 HTTP 協議，就需要單車先發出連接請求，然后等待服務器的回應（下發開鎖指令），這樣一來，受網路通信質量的影響，很可能連接經常中斷，而需要單車與服務器互動多次，那用戶可能就要等很長時間，對于這種場景來說，不只是 HTTP，其他跟 HTTP 一樣單向的、同步的網路協議，都不是理想的技術方案，

物聯網系統中，設備數量多，而且互動非常復雜，比如家里的環境監測，溫度、濕度、光照、二訊訓碳、甲醛含量……這些都需要不同的設備測量，而且每個房間用到的設備也不同，如果讓云平臺的服務對每個設備分別做權限控制和資料閾值設定，這會非常麻煩，因為當資料的“生產者”和“消費者”直接互動時，要是沒有中間角色基于共同的目標協調，雙方的耦合度會很大，導致系統很難實作，這時候，需要把家為一個整體來處理，互動邏輯就會變得簡單多了，設備經常需要根據實際使用環境做增加、減少等調整，

正是因為這些特點，物聯網系統在選擇網路通信的協議時，一般采用

發布 - 訂閱模式

發布 - 訂閱模式包含三個角色，分別是發布者、經紀人和訂閱者，它們的關系如下圖所示，

訊息傳遞的程序可以分為三步：
1.發布者負責生產資料，發布者發送某個主題的資料給經紀人，發布者不知道訂閱者，
2.訂閱經紀人管理的某個或者某幾個主題，
3.當經紀人接收到某個主題的資料時，將資料發送給這個主題的所有訂閱者，

比如說當使用美團外賣點一分午餐，這時候發布訂單給外賣訂單中心服務器時，外賣訂單中心收到訂單之后，再把訂單發送給店家

發布 - 訂閱模式之所以適合物聯網系統因為在物聯網場景中，一個傳感器資料需要觸發多個服務或者終端執行動作，
比如紅外傳感器，當它檢測到有人體靠近時，就需要觸發一系列動作：通知攝像頭拍照，聲光報警器執行報警，推送訊息給主人的手機等，
怎么滿足這種需求呢？我們最好讓攝像頭、聲光報警器和手機都訂閱“人體靠近”這個主題訊息，當紅外傳感器被觸發時，它發送人體靠近的訊息，然后這些設備就能同時收到這個訊息，接著完成系統定義的那些動作，這就是發布 - 訂閱模式的作業方式，

那么，具體有什么網路協議采用的是發布 - 訂閱通信模式呢？MQTT 協議就是其中的佼佼者，

MQTT

MQTT它有三個主要特點：

1.采用二進制的訊息內容編碼格式，所以二進制資料、JSON 和圖片等負載內容都可以方便傳輸，
2.協議頭很緊湊，協議互動也簡單，保證了網路傳輸流量很小，
3.支持 3 種 QoS（Quality of Service，服務質量）級別，便于應用根據不同的場景需求靈活選擇，

這三個特點，讓 MQTT 協議非常適合計算能力有限、網路帶寬低、信號不穩定的遠程設備，所以它成為了物聯網系統事實上的網路協議標準，

AMQP

除了 MQTT 協議外，還有其他采用發布 - 訂閱模式的網路協議，比如 AMQP 協議，
雖然 AMQP 協議擁有龐大的特性集，比較重，不適合計算資源有限、對功耗要求嚴苛的物聯網設備，但是它可以滿足后臺系統對于可靠性和可擴展性的要求，因此，它在物聯網的平臺系統中應用廣泛，

剛才我介紹了發布 - 訂閱模式的很多好處，但是凡事都有例外，也有一些物聯網應用場景，并不適合使用這種模式，比如，現在小區里面都有智能快遞柜，當你輸入取件碼后，服務器會向對應的柜門發送開門指令，在發布 - 訂閱模式下，服務器知道指令發送成功了，但是它無法知道柜門是否真的打開了，這時，你就需要讓柜門能夠向服務器反饋一下命令的執行結果，當然，你也可以讓服務器訂閱一個“柜門關閉”的主題訊息，然后等待柜門發布這個訊息，但是這樣的話就非常繁瑣、不夠直接，在這種場景下，另一種通信模式就能派上用場了，那就是

請求 - 回應模式，

請求 - 回應模式有兩個角色，一個是客戶端，另一個是服務器，
客戶端是請求資料或者服務的一方，服務器則用來接收客戶端的請求，并提供相應的資料或者服務，服務器在收到請求后，會獲取資料，對資源資料（比如資料庫）進行加工處理，準備好回應，然后回傳給客戶端，
請求 - 回應模式是無狀態的通信方式，每個完整的請求 - 回應都是相互獨立的，進一步細分的話，它還可以分為同步和異步兩種，你可以看下這張圖片，

HTTP

HTTP 就是請求 - 回應模式的的代表，HTTP/2 協議還引入了異步請求 - 回應模式，客戶端可以對請求設定不同的優先級，服務器可以根據優先級決定先回應哪個請求，
雖然 HTTP 協議的報文格式非常重，光是報文頭就能達到 KB 大小，不太適合資源有限的嵌入式設備，但在一些計算資源和網路資源都比較充足的物聯網設備上，HTTP 協議仍然是一個可選項，而且它和現有的 Web 系統兼容，可以利用已有的 Web 服務器資源，

CoAP

那么有沒有跟 HTTP 協議類似，但是設計輕量，可以用于資源受限的物聯網設備的協議呢？
有的，那就是 CoAP（Constrained Application Protocol）協議，
跟 HTTP 協議一樣，CoAP 協議同樣有 GET、POST、PUT、DELETE 等方法和回應狀態碼，同樣使用 URI 而不是 Topic 來標識資源，
比如我們需要訪問服務器 iotdemo.com 下面的 bedroom/temp 這個資源，那完整的資源地址是：

coap://iotdemo.com:5683/bedroom/temp

CoAP 的訊息采用二進制格式，支持可確認訊息和不可確認訊息兩種 QoS 級別，可確認訊息（Confirmable Message）與 MQTT 協議的 QoS 1 類似，不可確認訊息（Non-confirmable Message）對應 MQTT 協議的 QoS 0 級別，
另外，CoAP 協議基于的傳輸層協議是 UDP，而不是 HTTP 、 MQTT 協議的 TCP 協議，所以對于設備的計算資源要求更低，傳感器設備一般只需要上傳資料，不用隨時接收服務器的控制命令，這都說明 CoAP 協議適合電池供電的傳感器設備，
LwM2M
說完 CoAP，我再介紹一下跟它有關

LwM2M

LwM2M 協議定義在 CoAP 協議之上，不過它在訊息傳輸的基礎上更進一步，因為它基于 IPSO （IP-base Smart Object）對設備模型進行了標準化，提供了一組輕量級設備管理和互動介面協議，
LwM2M 協議目前主要的實作是 C 語言的 Wakaama 和 Java 語言的 Leshan，相對來說應用還比較少，CoAP 協議的應用場景同樣適合 LwM2M 協議，如果你希望在 CoAP 協議的基礎上更方便地實作設備的管理，可以考慮 LwM2M 協議，
通信模式的共存

學習筆記總結自‘物聯網開發實戰’–郭朝斌
–筆記只用于學習交流，請不要用于商業用途，