並非所有連線的裝置都設計為相等。雖然有些技術先進且堅固耐用，但有些則是簡單的感測器和家庭自動化系統，記憶體、能量、頻寬和計算能力有限。將網路引入資源受限的低功耗裝置並使其能夠有效通訊，需要開發人員實施特定型別的物聯網協議。這就是受限應用協議或 CoAP 出現的地方。
什麼是 CoAP？
CoAP 於 2014 年推出，是由 CoRE（受限資源環境）網際網路工程任務組 (IETF) 設計的輕量級 RESTful 協議。它通常用於機器對機器 (M2M) 應用程式，例如智慧能源和樓宇自動化裝置。
CoAP 是物聯網網路中低功耗物聯網裝置的高效通訊協議。它允許資源受限的感測器節點、家庭自動化工具和其他需要較少頻寬或計算能力的連線物件透過網際網路進行通訊。
CoAP 是用於建立和管理裝置、釋出/訂閱資料、在多個客戶端之間多播資料以及在客戶端請求時提供裝置描述的出色協議。
它還具有檢測裝置電源狀態的機制。此外，由於與 HTTP REST 操作在基礎架構上有相似之處，設計人員可以將他們對 RESTful 模式的理解運用到他們使用 CoAP 進行的 IoT 應用程式開發中。
CoAP 協議概覽
物聯網生態系統是一個快速發展的空間，即使是最傑出的設計人員和開發人員也很容易在 M2M 協議補丁、漏洞、第三方庫錯誤和實施缺陷的知識和管理方面被超越。
因此，物聯網裝置使用流行的 CoAP 協議來阻止 M2M 應用程式中的網路攻擊也就不足為奇了。它們支援非同步訊息交換，提供 URI 和內容型別支援，利用代理和快取功能，並且易於解析。但在我們深入研究 CoAP 協議之前，有必要了解其結構，它通常由以下實體組成：
- “Sender”——傳送訊息的實體。
- “接收者”——訊息的接收者或目的地。
- “客戶端”——請求的來源和響應的目的地。
- “端點”——參與 CoAP 協議的實體，通常與主機標識。
- “伺服器”——客戶端和接收者之間的連結。它接收來自客戶端的請求並將響應傳送回客戶端。
典型的 CoAP 協議可能看起來類似於 HTTP 協議，因為 CoAP 部署了使用者資料報協議 (UDP) 作為底層網路協議。反過來，UDP 會幫助客戶端發出請求，而伺服器會傳輸響應——就像在 HTTP 中發生的那樣。
兩層讓 CoAP 脫穎而出
請求/響應層根據請求/響應訊息處理請求/響應互動。
訊息層處理非同步訊息和使用者資料報協議 (UDP)。
如您所見，CoAP 協議不僅僅是 HTTP 協議的壓縮版本，而且是專為 IoT 設計的。 CoAP 支援四種類型的訊息，包括：
- 重置 (RST)
- 可確認 (CON)
- 不可確認 (NON)
- 確認（ACK）
這些訊息的主要交換對於請求/響應互動是透明的。 CoAP 是一個單一的協議，請求/響應和訊息作為 CoAP 頭的特徵。
CoAP 通常如何運作
CoAP 主要用於受限裝置，使執行器和感測器能夠在物聯網生態系統內高效通訊。這些應用程式透過將它們的資料作為系統的一部分提供來進行控制。該協議可以透過低網路開銷和低功耗在高擁塞和低頻寬場景中提供卓越的效能。 CoAP 還支援具有許多節點的網路。即使在基於 TCP 的協議 MQTT 無法在裝置之間交換資訊和有效通訊的情況下，它也可以繼續工作。
此外，CoAP 協議允許裝置在較差的訊號質量下執行並可靠地傳輸資料。這一特性還使衛星能夠方便地保持遠端通訊。這就是 M2M 開發服務中發生的情況。
CoAP訊息模型的構建
這是協議的最低層元素，因為它處理端點之間的 UDP 傳輸訊息。每個 CoAP 訊息都有一個唯一的 ID，這對於檢測訊息重複非常有用。平均而言，CoAP 訊息模型由三部分組成，其中兩部分是可選的：
- 一個二進位制頭
- 一組緊湊的選項（可選）
- 有效載荷（可選）
CoAP 協議指定了兩種型別的訊息：
可確認
這些在兩個端點之間傳輸的訊息是可靠的。這意味著客戶端確信訊息將到達伺服器。在 CoAP 中，使用可確認 (CON) 訊息型別程式碼獲得專用訊息。 Confirmable 訊息會重複傳送，直到另一方（即伺服器）傳送確認（ACK）訊息，該訊息包含與 Confirmable 訊息相同的 ID，但帶有 ACK 響應程式碼。
不可確認
這些訊息不需要來自客戶端的確認，而是始終在兩個端點之間攜帶請求或響應。對於應用要求，不可確認 (NON) 訊息會無限重複——例如，從感測器中重複讀取最終到達就足夠了。這樣的訊息必須包含有效載荷。
揭示“請求和響應”模型
這是協議的第二層。 使用 CON 或 NON 訊息傳送請求。 如果使用 CON 訊息傳送請求，則伺服器的響應取決於伺服器是否可以立即響應客戶端的請求：
- 如果伺服器可以及時響應，伺服器會向客戶端傳送一條包含錯誤程式碼或響應的 ACK 訊息，以及一個 Token 欄位，該欄位反映了請求中的 Token 欄位。 Token 不同於 Message-ID，它用於匹配兩個端點之間的請求和響應。
- 如果伺服器不能及時響應從客戶端收到的請求，另一方面，它會發送一個訊息欄位為空的 ACK 訊息。 一旦響應可用，伺服器就會向共享狀態的客戶端傳送 CON 訊息。
如果來自客戶端的請求攜帶不可確認訊息，則伺服器僅使用該型別的訊息進行響應。
什麼是訊息格式？
CoAP 訊息以二進位制形式編碼。 CoAP 訊息由固定大小的 CoAP 報頭組成，輔以有效載荷和以型別-長度-值 (TLV) 格式指定的選項。
雖然標頭指定了這些選項，但有效載荷由根據資料報長度計算選項長度之後的位元組組成。 CoAP 訊息佔用 UDP 資料報的資料部分以避免分段。
由於 CoAP 節省能源並簡化裝置之間的通訊，因此使用緊湊訊息。 CoAP 報頭的必填欄位是：
- 版本（CoAP 訊息格式的 2 位版本；有時縮寫為“VER”）
- 型別（對應於 RST、CON、NON 或 ACK 訊息型別的 2 位無符號整數）
- 令牌長度（一個 4 位欄位，指定“令牌”欄位的位元組長度；有時縮寫為“TKL”）
- 程式碼（一個 8 位欄位，提供有關請求或響應的更多資訊）
- Message-ID（與訊息關聯的唯一 ID，用 16 位值表示）
考慮 CoAP 安全性
安全是物聯網生態系統中的一個重大問題，並且有充分的理由：裝置透過網際網路連線，在它們之間交換各種資訊。無論所討論的物聯網裝置是用於個人用途還是商業用途，資料安全都至關重要。
CoAP 將 UDP 應用於傳輸資訊，並進一步依賴它進行資訊保護。最小的 CoAP 訊息長度為 4 個位元組，並使用兩種訊息型別（響應和請求），使用簡單的二進位制基本報頭格式。
後者是經過最佳化的 TLV 格式的選項，可提供高級別的通訊安全性。留在包中的頭中的任何位元組都被歸類為訊息體，這由資料報長度暗示。
交給你
在 M2M 應用程式中，從長遠來看，應用程式/XML、應用程式/八位位元組流或文字/純文字等通用網際網路媒體型別並沒有被證明對現實世界的應用程式有幫助。例如，智慧能源應用程式負載可能會請求更具體的型別，如 application/se+exi，因為它是作為 XML 攜帶的。
這就是為什麼需要更先進的物聯網協議的原因。 CoAP 在降低雲裝置連線成本方面發揮了關鍵作用，使物聯網裝置能夠在更大的網路上經濟高效且安全地傳送資料，同時消耗更少的電量。
隨著物聯網環境的發展，對關鍵協議的需求也在增長，以經濟高效且安全地實現跨裝置的資料傳輸。毫無疑問，CoAP 是一種支援 M2M 應用的智慧解決方案。由於它的產品種類繁多，讓我們希望它的用途在未來也能發展到物聯網的其他不同方面。
