IoT物聯(lián)網(wǎng)CoAP協(xié)議是什么意思

這篇文章主要為大家分析了IoT物聯(lián)網(wǎng)CoAP協(xié)議是什么意思的相關(guān)知識點，內(nèi)容詳細易懂，操作細節(jié)合理，具有一定參考價值。如果感興趣的話，不妨跟著跟隨小編一起來看看，下面跟著小編一起深入學習“IoT物聯(lián)網(wǎng)CoAP協(xié)議是什么意思”的知識吧。

CoAP是受限制的應用協(xié)議(Constrained Application Protocol)的縮寫。在IoT物聯(lián)網(wǎng)場景，為了讓小設備可以接入互聯(lián)網(wǎng)，CoAP協(xié)議被設計出來。CoAP是一種應用層協(xié)議，它運行于UDP協(xié)議之上而不是像HTTP那樣運行于TCP之上。CoAP協(xié)議非常小巧，最小的數(shù)據(jù)包僅為4字節(jié)。

CoAP是一種面向網(wǎng)絡的協(xié)議，采用了與HTTP類似的特征，核心內(nèi)容為資源抽象、REST式交互以及可擴展的頭選項等。為了克服HTTP對于受限環(huán)境的劣勢，CoAP既考慮到數(shù)據(jù)報長度的最優(yōu)化，又考慮到提供可靠通信。一方面，CoAP提供URI，REST 式的方法如GET，POST，PUT和DELETE，以及可以獨立定義的頭選項提供的可擴展性。另一方面，CoAP基于輕量級的UDP協(xié)議，并且允許IP多播。為了彌補UDP傳輸?shù)牟豢煽啃裕珻oAP定義了帶有重傳機制的事務處理機制。并且提供資源發(fā)現(xiàn)機制，并帶有資源描述。

協(xié)議特點

• 基于消息模型

• 請求/響應模型

• 雙向通信

• 輕量、低功耗

• 支持可靠傳輸

• 支持IP多播

• 非長連接通信，支持受限設備

• 支持觀察模式

• 支持異步通信

協(xié)議內(nèi)容

CoAP是一個完整的二進制應用層協(xié)議，消息格式緊湊，默認運行在UDP上。

CoAP報文

• 【Ver】版本編號。
  

• 【T】報文類型，CoAP協(xié)議定了4種不同形式的報文，CON報文，NON報文，ACK報文和RST報文。
  

• 【TKL】CoAP標識符長度。CoAP協(xié)議中具有兩種功能相似的標識符，一種為Message ID(報文編號)，一種為Token(標識符)。其中每個報文均包含消息編號，但是標識符對于報文來說是非必須的。
  

• 【Code】功能碼/響應碼。Code在CoAP請求報文和響應報文中具有不同的表現(xiàn)形式，Code占一個字節(jié)，它被分成了兩部分，前3位一部分，后5位一部分，為了方便描述它被寫成了c.dd結(jié)構(gòu)。其中0.XX表示CoAP請求的某種方法，而2.XX、4.XX或5.XX則表示CoAP響應的某種具體表現(xiàn)。
  

• 【Message ID】報文編號。
  

• 【Token】標識符具體內(nèi)容，通過TKL指定Token長度。
  

• 【Option】報文選項，通過報文選項可設定CoAP主機，CoAP URI，CoAP請求參數(shù)和負載媒體類型等等。
  

• 【1111 1111B】CoAP報文和具體負載之間的分隔符。
  

請求方法

• 0.01 GET：獲取資源

• 0.02 POST：創(chuàng)建資源

• 0.03 PUT：更新資源

• 0.04 DELETE：刪除資源

響應碼

Success 2.xx

這一類型的狀態(tài)碼，代表請求已成功被服務器接收、理解、并接受。

• 2.01 Created

• 2.02 Deleted

• 2.03 Valid

• 2.04 Changed

• 2.05 Content

Client Error 4.xx

這類的狀態(tài)碼代表了客戶端看起來可能發(fā)生了錯誤，妨礙了服務器的處理。

• 4.00 Bad Request

• 4.01 Unauthorized

• 4.02 Bad Option

• 4.03 Forbidden

• 4.04 Not Found

• 4.05 Method Not Allowed

• 4.06 Not Acceptable

• 4.12 Precondition Failed

• 4.13 Request Entity Too Large

• 4.15 Unsupported Content-Format

Server Error 5.xx

這類狀態(tài)碼代表了服務器在處理請求的過程中有錯誤或者異常狀態(tài)發(fā)生，也有可能是服務器的軟硬件資源無法完成對請求的處理。

• 5.00 Internal Server Error

• 5.01 Not Implemented

• 5.02 Bad Gateway

• 5.03 Service Unavailable

媒體類型

工作模式

CoAP參考了很多HTTP的設計思路，同時也根據(jù)受限資源限制設備的具體情況改良了諸多的設計細節(jié)，增加了很多實用的功能。

消息類型

• CON：需要被確認的請求，如果CON請求被發(fā)送，那么對方必須做出響應。
  

• NON：不需要被確認的請求，如果NON請求被發(fā)送，那么對方不必做出回應。
  

• ACK：應答消息，接受到CON消息的響應。
  

• RST：復位消息，當接收者接收到的消息包含一個錯誤，接收者解析消息或者不再關(guān)心發(fā)送者發(fā)送的內(nèi)容，那么復位消息將會被發(fā)送。
  

請求/響應模型

1.攜帶模式

2.分離模式

3.非確認模式

CoAP協(xié)議的URI

在HTTP的世界中，正式RESTFul協(xié)議由于其簡單性和適用性，在WEB應用中越來越受歡迎，這樣的道理同樣適用于CoAP。一個CoAP資源可以被一個URI所描述，例如一個設備可以測量溫度，那么這個溫度傳感器的URI被描述為：CoAP://machine.address:5683/sensors/temperature。

CoAP的默認UDP端口號為5683

HTTP和CoAP對比

• HTTP代表超文本傳輸協(xié)議，CoAP代表約束應用協(xié)議；

• HTTP協(xié)議的傳輸層采用了TCP，CoAP協(xié)議的傳輸層使用UDP；

• CoAP協(xié)議是HTTP協(xié)議的簡化版；

• CoAP協(xié)議和HTTP協(xié)議一樣使用請求/響應模型，擁有相同的方法；

• CoAP開銷更低，并支持多播；

• CoAP專為資源構(gòu)成應用而設計，如：IoT/WSN/M2M等...

CoAP和MQTT對比

• MQTT協(xié)議使用發(fā)布/訂閱模型，CoAP協(xié)議使用請求/響應模型；

• MQTT是長連接，CoAP協(xié)議是無連接；

• MQTT通過中間代理傳遞消息的多對多協(xié)議，CoAP協(xié)議是Server和Client之間消息傳遞的單對單協(xié)議；

• MQTT不支持帶有類型或者其它幫助Clients理解的標簽消息，CoAP內(nèi)置內(nèi)容協(xié)商和發(fā)現(xiàn)支持，允許設備彼此窺測以找到交換數(shù)據(jù)的方式。

關(guān)于“IoT物聯(lián)網(wǎng)CoAP協(xié)議是什么意思”就介紹到這了,更多相關(guān)內(nèi)容可以搜索億速云以前的文章，希望能夠幫助大家答疑解惑，請多多支持億速云網(wǎng)站！