限應(yīng)用協(xié)議( CoAP ) 是一種基于 UDP 的專用互聯(lián)網(wǎng)應(yīng)用協(xié)議，其定義見RFC 7252（發(fā)布于 2014 年）。它使那些被稱為“節(jié)點”的受限設(shè)備能夠使用類似的協(xié)議與更廣泛的互聯(lián)網(wǎng)進行通信。

CoAP 的設(shè)計用途包括：同一受限網(wǎng)絡(luò)（例如低功耗、有損網(wǎng)絡(luò)）上的設(shè)備之間、設(shè)備與互聯(lián)網(wǎng)上的一般節(jié)點之間，以及通過互聯(lián)網(wǎng)連接的不同受限網(wǎng)絡(luò)上的設(shè)備之間。CoAP 也可通過其他機制使用，例如移動通信網(wǎng)絡(luò)上的短信 (SMS)。

CoAP 是一種應(yīng)用層協(xié)議，旨在用于資源受限的互聯(lián)網(wǎng)設(shè)備，例如無線傳感器網(wǎng)絡(luò)節(jié)點。CoAP 旨在輕松轉(zhuǎn)換為HTTP，以簡化與 Web 的集成，同時還能滿足諸如多播支持、極低開銷和簡單性等特殊要求。多播、低開銷和簡單性對于物聯(lián)網(wǎng)(IoT) 和機器對機器(M2M) 通信至關(guān)重要，因為這些通信往往是嵌入式的，并且內(nèi)存和功耗遠低于傳統(tǒng)的互聯(lián)網(wǎng)設(shè)備。因此，效率至關(guān)重要。CoAP 可以在大多數(shù)支持 UDP 或 UDP 類似協(xié)議的設(shè)備上運行。

互聯(lián)網(wǎng)工程任務(wù)組 ( IETF ) 受限RESTful環(huán)境工作組 ( CoRE ) 已完成該協(xié)議的主要標準化工作。為了使該協(xié)議適用于物聯(lián)網(wǎng) (IoT) 和 M2M 應(yīng)用，協(xié)議中添加了各種新功能。

規(guī)格

該協(xié)議的核心在RFC  7252中指定。目前已提出了各種擴展，特別是：

• RFC  7641 (2015) 觀察受限應(yīng)用協(xié)議中的資源
• RFC  7959 (2016) 受限應(yīng)用協(xié)議 (CoAP) 中的塊傳輸
• RFC  8323 (2018) 基于 TCP、TLS 和WebSockets 的CoAP（受限應(yīng)用協(xié)議）
• RFC  8974 (2021) 受限應(yīng)用協(xié)議 (CoAP) 中的擴展令牌和無狀態(tài)客戶端

消息格式

CoAP 使用兩種消息類型：請求和響應(yīng)，并采用簡單的二進制報頭格式。CoAP 默認綁定到UDP，也可選擇綁定到DTLS，從而提供高級別的通信安全性。綁定到 UDP 時，整個消息必須包含在單個數(shù)據(jù)報中。當與RFC 4944 中定義的6LoWPAN一起使用時，消息應(yīng)包含在單個IEEE 802.15.4幀中，以最大限度地減少碎片化。

如果省略令牌、選項和有效載荷字段，即僅包含 CoAP 報頭，則最小的 CoAP 消息長度為 4 個字節(jié)。報頭后跟令牌值（0 到 8 個字節(jié)），令牌值之后可能跟以優(yōu)化的類型-長度-值格式的選項列表。報頭、令牌和選項（如有）之后的任何字節(jié)都被視為消息有效載荷，其前綴為一個字節(jié)的“有效載荷標記”（0xFF）。有效載荷的長度由數(shù)據(jù)報長度決定。

CoAP消息

CoAP群組通信

在許多 CoAP 應(yīng)用領(lǐng)域中，能夠?qū)⒍鄠€ CoAP 資源作為一個組進行尋址，而不是單獨尋址每個資源至關(guān)重要（例如，通過切換電燈開關(guān)觸發(fā)的單個 CoAP 請求打開房間內(nèi)所有支持 CoAP 的燈）。為了滿足這一需求，IETF 以實驗性 RFC 的形式開發(fā)了一個 CoAP 可選擴展：CoAP 的組通信 - RFC 7390 。 此擴展依靠 IP 多播將 CoAP 請求傳遞給所有組成員。使用多播具有某些優(yōu)勢，例如減少將請求傳遞給成員所需的數(shù)據(jù)包數(shù)量。然而，多播也有其局限性，例如可靠性差和緩存不友好。CoAP 組通信的另一種方法是使用單播而不是多播，這依賴于一個創(chuàng)建組的中介?？蛻舳藢⑵浣M請求發(fā)送到中介，中介又將各個單播請求發(fā)送給組成員，收集來自他們的回復(fù)，并將聚合的回復(fù)發(fā)送回客戶端。

安全

CoAP 定義了四種安全模式：

• NoSec，其中DTLS被禁用
• PreSharedKey：啟用 DTLS 后，會有一個預(yù)共享密鑰列表，每個密鑰都包含一個可用于通信的節(jié)點列表。設(shè)備必須支持 AES 密碼套件。
• RawPublicKey，啟用 DTLS 后，設(shè)備使用不帶證書的非對稱密鑰對，該密鑰對在帶外進行驗證。設(shè)備必須支持 AES 密碼套件和橢圓曲線算法進行密鑰交換。
• 證書，其中啟用了 DTLS 并且設(shè)備使用X.509證書進行驗證。

已有研究通過將安全關(guān)聯(lián)實現(xiàn)為 CoAP 資源（而非將 DTLS 用作 CoAP 流量的安全包裝器）來優(yōu)化 DTLS。研究表明，與未優(yōu)化的實現(xiàn)相比，DTLS 的性能提升高達 6.5 倍。

除了 DTLS 之外，RFC8613還定義了受限 RESTful 環(huán)境的對象安全 ( OSCORE ) 協(xié)議，該協(xié)議為應(yīng)用層的 CoAP 提供安全性。

安全問題

盡管協(xié)議標準包含了減輕DDoS放大攻擊威脅的規(guī)定，但這些規(guī)定并未在實踐中得到實施，導(dǎo)致超過 580,000 個目標主要位于中國，攻擊速度高達 320 Gbit/s。