前言
本文介紹什么是CoAP，以及如何在物聯網設備上使用它。CoAP是一種物聯網協議，具有一些專門為受約束的設備而設計的有趣功能。還有其他一些可用於構建物聯網解決方案的IoT協議，例如MQTT等。
物聯網是最有趣和最有前途的技術趨勢之一。在這個生態系統中，對象，人員，設備相互連接並交換數據。在此博客中，我們從多個角度介紹了物聯網和開發物聯網項目，並涵蓋了與物聯網相關的多個方面。
什么是CoAP協議？
如前所述，CoAP是一種物聯網協議。CoAP意思為Constrained Application Protocol，在RFC 7252中所定義。CoAP是一種低開銷的簡單協議，專門針對受限設備（例如微控制器）和受限網絡而設計。該協議用於M2M數據交換中，並且與HTTP非常相似，即使稍后我們將介紹重要的區別。
CoAP協議的主要特征是：
- 受限制的小型設備的Web傳輸協議(類似於HTTP)
- 異步消息交換
- 低開銷，非常易於解析
- URI和內容類型支持
- 代理和緩存功能
您可能會注意到，CoAP某些功能也與HTTP非常相似，但是不能將CoAP視為壓縮版本的HTTP協議，因為CoAP是專門為IoT設計的，並且更詳細地針對M2M，因此針對這些要求必須有所優化。
從抽象協議層，CoAP可以表示為：
正如你所看到的，CoAP協議有兩個不同的層：消息負載和請求/響應。消息層處理UDP和異步消息。請求/響應層基於請求/響應消息來管理請求/響應交互。
CoAP支持四種不同的消息類型：
- 可確認的 Confirmable(CON)
- 無法確認 Non-confirmable(NON)
- 確認 Acknowledgment
- 重置 Reset
在深入研究CoAP協議之前，以下必要的術語有助於我們更好的了解CoAP協議：
- 節點(Endpoint）：參與CoAP協議的實體。通常，將端點標識為主機
- 發件人(Sender)：發送消息的實體
- 收件人(Recipient)：接受消息的實體
- 客戶端(Client)：發送請求的實體和接受消息的實體
- 服務器(Server)：接收來自客戶端的請求並向客戶端發送回響應的實體
CoAP消息模型
這是CoAP的最低層。該層處理端點之間的UDP交換消息。每個CoAP消息都有一個唯一的ID。這對於檢測消息重復很有用。CoAP消息由以下部分構建：
- 二進制標志頭
- 可選項
- 載荷消息
稍后，我們將更詳細地描述消息格式。
如前所述，CoAP協議使用兩種消息：
- 確認消息
- 不可確認的消息
可確認消息是可靠消息。在兩個端點之間交換消息時，這些消息可能是可靠的。在CoAP中，使用確認消息（CON）獲得可靠的消息。使用這種消息，客戶端可以確保消息將到達服務器。反復發送確認消息，直到另一方發送確認消息（ACK）。ACK消息包含與確認消息（CON）相同的ID。
下圖顯示了消息交換過程：
如果服務器在管理傳入請求時遇到問題，則可以發送回Rest消息（RST）而不是Acknowledge消息（ACK）：
另一個消息類別是“不可確認（NON）”消息。這些是不需要服務器確認的消息。它們是不可靠的消息，或者換句話說，這些消息不包含必須傳遞給服務器的關鍵信息。包含從傳感器讀取的值的消息屬於此類別。
即使這些消息不可靠，它們也具有唯一的ID。
CoAP請求/響應模型
CoAP請求/響應是CoAP抽象層中的第二層。使用“確認”（CON）或“非確認”（NON）消息發送請求。根據服務器是否可以立即響應客戶端請求或答案（如果不可用），有幾種方案。
如果服務器可以立即響應客戶端請求，則如果使用確認消息（CON）承載了請求，則服務器將包含響應或錯誤代碼的確認消息發送回客戶端：
如您在CoAP消息中所注意到的，有一個令牌。令牌不同於消息ID，它用於匹配請求和響應。
如果服務器無法立即響應來自客戶端的請求，則它將發送帶有空響應的確認消息。一旦響應可用，服務器就會向客戶端發送一條新的Confirmable消息，其中包含響應。此時，客戶端發送回確認消息：
如果來自客戶端的請求是使用不可確認消息承載的，則服務器將使用不可確認消息進行應答。
CoAP消息格式
本段涵蓋了CoAP消息格式。到目前為止，我們已經討論了客戶端和服務器之間交換的各種消息。現在是時候分析消息格式了。受限的應用程序協議是受限環境中的關鍵，因此，它使用緊湊的消息。為了避免分段，消息占用UDP數據報的數據部分。一條消息由幾個部分組成：
Version(VER)(2 bits): CoAP版本號
Type(2 bits)
這描述了請求和響應着兩種消息類型上下文的數據包消息類型。
- 請求
- 0 : 可確認: 該消息需要相應的確認消息。
- 1 : 不可確認：此消息不需要確認消息。
- 響應
- 2 : 確認: 此消息是確認可確認消息的響應。
- 3 : 重置: 此消息表明它已收到消息，但無法處理。
Token Length(4 bits): 指示可變長度令牌字段的長度，其長度可以為0-8字節。
Request/Response(8 bits): CoAP請求/響應代碼
Message ID(16 bits): 用於檢測消息重復並將“確認/重置”類型的消息與“確認” /“不可確認”類型的消息進行匹配。：響應消息將具有與請求相同的消息ID。
CoAP安全方面
處理物聯網協議時的一個重要方面是安全性方面。如前所述，CoAP使用UDP傳輸信息。CoAP依靠UDP安全性方面來保護信息。由於HTTP使用基於TCP的TLS，因此CoAP使用基於UDP的數據報TLS。DTLS支持RSA，AES等。無論如何，我們應該考慮在某些受限設備中可能無法使用某些DTLS密碼套件。重要的是要注意，某些密碼套件引入了一些復雜性，並且受約束的設備可能沒有足夠的資源來管理它。
分割線君
🍁高質量的 IOT 技術教程，代碼主要源於國外開源物聯網平台ThingsBoard和對阿里雲物聯網平台的感悟
備注: 🔓 :表示公開瀏覽; 🔐 :表示需要加入作者知識星球才可瀏覽;
源碼解析系列
a.『 准備篇 』
b.『設備連接協議篇 』
- MQTT
協議 : MQTT
技術框架 : Netty
-
CoAP
協議 : CoAP
框架: Californium(cf)
IoT在線資源推薦
- 關於物聯網框架、開源庫、操作系統和平台的資源 https://phodal.github.io/awesome-iot/
- 一個很棒的物聯網項目和資源的列表 https://github.com/HQarroum/awesome-iot/
號外
致力於打造專業的物聯網技術圈，幫助朋友和同學在物聯網的風口上早日起飛 🛫️
主要內容有:
- 📢 ThingsBoard源碼解析
高達5k+的開源物聯網平台，物聯網解決方案的設備管理、數據收集、處理和可視化 - 🎐 應用於物聯網應用層技術領域的技術和實踐
並且你還可以得到：
- Java通信領域Netty技術的極大提升。
- MQTT, CoAP, Http2和網關協議的理論知識和指導。
- 手把手教你搭建高可用及高性能IoT平台。
版權說明
- ✍️ 穆書偉 (sanshengshui@github)
- 除非另行注明，這個項目中的所有內容采用Apache2.0（Apache-2.0）協議共享。
- 不少文章在原基礎上翻譯或演繹而來，頁面上方標注了原作者、原文鏈接以及原文采用的協議。如有版權疑問，請在 Issue 中提出。
- 如果引用本此項目教程代碼或者文章,請注明作者和github項目地址。
- 歡迎通過 Issue 或者 Pull Request 推薦你認為合適的資料，讓這份菜單更充實一些。
🍀🍀🍀🍀🍀🍀🍀
為什么要做這份菜單
在學習開源物聯網平台ThingsBoard和使用阿里雲物聯網平台的時候，讓我對物聯網這個領域產生了極大的興趣。我發現ThingsBoard的更新速度十分頻繁且代碼架構十分優秀，隨着未來十年內將會有數十億的設備將聯網和國內對物聯網領域的高熱度。眾多的開發人員經歷過Web2.0和移動互聯網的時代，但是對於未來的設備聯網這塊的知識十分缺乏，並且搜索引擎上大多數文章都比較的粗淺。此外，這些資料往往只涉及某些特定的話題，如果能有一份菜單將這些菜譜以特定的方式串起來，那么對於 IOT 學習者來說將會是極大的便利。尤其對於我這樣熱愛查閱社區資料勝過出版物的懶人🌚 隨着我的學習節奏還會不斷有新的菜譜加入進來。