coap協議總結

coap協議

一、coap協議基礎

1.1 什么是CoAp

? CoAP是受限制的應用協議(Constrained Application Protocol)的代名詞，但是對于小型設備而言，實作TCP和HTTP協議顯然是一個過分的要求，為了讓小設備可以接入互聯網，CoAP協議被設計出來， CoAP是一種應用層協議，它運行于 UDP協議之上而不是像HTTP那樣運行于TCP之上，CoAP協議非常小巧，最小的資料包僅為4位元組，CoAp是一個完整的二進制應用層協議，借鑒了HTTP協議的設計并簡化了協議包格式，降低了開發者的學習成本，

1.2 CoAp訊息結構

Version：版本號

T：message type—訊息型別

• CON—需要被確認的請求，如果CON請求被發送，那么對方必須做出回應，
• NON—不需要被確認的請求，如果NON請求被發送，那么對方不必做出回應，
• ACK—應答訊息，接受到CON訊息的回應，
• RST—復位訊息，當接收者接受到的訊息包含一個錯誤，接受者決議訊息或者不再關心發送者發送的內容，那么復位訊息將會被發送，

TKL：CoAP識別符號長度，CoAP協議中具有兩種功能相似的識別符號，一種為Message ID（報文編號），一種為Token（識別符號），其中每個報文均包含訊息編號，但是識別符號對于報文來說是非必須的，

Code：功能碼/回應碼，Code在CoAP請求報文和回應報文中具有不同的表現形式，Code占一個位元組，它被分成了兩部分，前3位一部分，后5位一部分，為了方便描述它被寫成了c.dd結構，其中0.XX表示CoAP請求的某種方法，而2.XX、4.XX或5.XX則表示CoAP回應的某種具體表現，

Message ID：報文編號

Token：識別符號具體內容，通過TKL指定Token長度，

options：CoAP選項類似于HTTP請求頭，它包括CoAP訊息本身，例如CoAP埠號，CoAP主機和CoAP查詢字串等，

1111 1111：CoAP報文和具體負載之間的分隔符，

playload：真正有用的被互動的資料，

? 除了Ver、T、TKE、Code、Message ID之外其他的都是可選的，這也是為什么最小的資料包僅4個位元組的原因，

1.3 CoAP協議特點

• 滿足受限環境下M2M的需求的協議
• CoAP協議基于UDP
• 異步訊息交換
• 輕量級的頭部，且決議復雜度低，
• 支持URI和Content-Type
• 能實作簡單的快取和資料代理
• 無狀態的HTTP映射，可以構建代理服務器，使CoAP資源可以用HTTP協議訪問，也可以使HTTP介面實作于CoAP協議之上
• 支持DTLS

二、Message Format

Message組成部分：

• 固定的4個位元組的頭部
• 0-8位元組的Token
• 0或者多個TLV（Type-Length-Value）格式的Option
• 可選的Payload

三、code

? Code部分被分成了兩部分，為了便于閱讀，Code被描述為c.dd形式，具體內容可參考RFC7252 #12.1.1 Method Codes，

3.1 請求

? 在CoAP請求中，Code被定義為CoAP請求方法，這些方法有GET、POST、PUT和DELETE，這些方法和HTTP協議非常相似，

【0.01】GET方法——用于獲得某資源
【0.02】POST方法——用于創建某資源
【0.03】PUT方法——用于更新某資源
【0.04】DELETE方法——用于洗掉某資源

（1）GET: GET方法檢索資訊的表示形式，當前對應于請求URI標識的資源，如果請求中包含接受選項，則表明回應的首選內容格式，如果請求中包含ETag選項，GET方法要求驗證ETag以及僅當驗證失敗時，才轉移表示，若成功，應使用2.05（內容）或2.03（有效）回應代碼出現在回應中，GET方法安全且冪等，

（2）POST: POST方法要求封裝在要求得到處理，POST執行的實際功能方法由源服務器確定，并取決于目標資源，通常會導致創建新資源或目標資源正在更新，如果已在服務器上創建資源，則回傳回應服務器應具有2.01（已創建）回應代碼，應以一個或多個順序包含新資源的URI位置路徑和/或位置查詢選項（第5.10.7節），如果POST成功，但不會導致在上創建新資源在服務器上，回應應具有2.04（已更改）回應代碼，如果POST成功并導致目標資源被占用洗掉后，回應應具有2.02（已洗掉）回應代碼，POST既不安全也不冪等 ，

（3）PUT: PUT方法請求由請求標識的資源使用隨附的表示法更新或創建URI，表示的格式由媒體型別和內容指定Content-Format選項中提供的編碼（如果提供），如果請求URI處存在資源，則隨附的表示形式應該被認為是該資源的修改版，并且是2.04（已更改）應回傳回應代碼，如果沒有資源，然后服務器可以使用該URI創建一個新資源，結果是2.01（創建的）回應代碼，如果無法創建資源或修改后，應發送適當的錯誤回應代碼，通過包含If-Match可以對PUT進行進一步的限制或“如果不匹配”請求中的選項，PUT是不安全的，但是冪等的，

（4）DELETE: DELETE方法請求由請求URI被洗掉，2.02（已洗掉）回應代碼應為成功使用時或如果資源不存在之前使用請求，DELETE是不安全的，但是是冪等的

3.2 回應

? 回應代碼分為3類：

2-成功：成功接收，理解并請求公認，
4-客戶端錯誤：請求包含錯誤的語法或無法實作，
5-服務器錯誤：服務器未能履行表面上有效的命令請求

? 在CoAP回應中，Code被定義為CoAP回應碼，類似于HTTP 200 OK等等，

【2.01】Created.回復POST或者PUT，
【2.02】Deleted.回復DELETE，有些情況下的POST，
【2.03】Valid.Indicate that the response identified by the entity-tag identified by the included ETag Option is valid.則，Response必須帶ETag Option，　
【2.04】Changed.回復POST和PUT，
【2.05】Content.類似于HTTP 200 OK–服務器成功處理了請求回復GET，

【4.00】Bad Request 請求錯誤，服務器無法處理，類似于HTTP 400，
【4.01】Unauthorized 沒有范圍權限，類似于HTTP 401，
【4.02】Bad Option 請求中包含錯誤選項，
【4.03】Forbidden 服務器拒絕請求，類似于HTTP 403，
【4.04】Not Found 服務器找不到資源，類似于HTTP 404，
【4.05】Method Not Allowed 非法請求方法，類似于HTTP 405，
【4.06】Not Acceptable 請求選項和服務器生成內容選項不一致，類似于HTTP 406，
【4.12】Precondition Failed 請求引數不足，類似于HTTP 412，
【4.15】Unsuppor Conten-Type 請求中的媒體型別不被支持，類似于HTTP 415，

【5.00】Internal Server Error 服務器內部錯誤，類似于HTTP 500，
【5.01】Not Implemented 服務器無法支持請求內容，類似于HTTP 501，
【5.02】Bad Gateway 服務器作為網關時，收到了一個錯誤的回應，類似于HTTP 502，
【5.03】Service Unavailable 服務器過載或者維護停機，類似于HTTP 503，
【5.04】Gateway Timeout 服務器作為網關時，執行請求時發生超時錯誤，類似于HTTP 504，
【5.05】Proxying Not Supported 服務器不支持代理功能，

四、Token

4.1 Token生成方法

? 令牌用于將回應與請求匹配，令牌Value為0 ~ 8位元組的序列，(注意每條訊息攜帶一個令牌，即使它的長度為零，)每個請求帶有客戶端生成的令牌，服務器必須回顯（不包含）修改），令牌旨在用作客戶端本地識別符號區分并發請求；它可以稱為“請求ID”，

方法一：MD5加鹽法（HASH+SALT），實作一人一密，

? 所謂加鹽（SALT）其實就是生成HASH時給予一個干擾，使結果與標準的HASH結果不同，從而對抗彩虹表，比如說用戶密碼‘88888888’，加一個鹽（一個隨機字串）‘q1we2rt3y6u8io7p’，拼接到一起在計算MD5，結果值就變了，這樣即使用戶使用弱密碼，也能一定程度上防御彩虹攻擊，但是如果每個密碼加的鹽都是一樣的，那么就又回到了之前的問題了，
? 一人一密
? 我們要實作，相同的站點，不同用戶的相同的密碼口令不同，這樣就能有效的對付碰撞和統計攻擊，例如：加自定義的鹽，密碼拼接用戶名或者時間戳在計算MD5，

方法二：

（1） 用戶請求時攜帶此token(分為三部分,header密文, payload密文,簽名)到服務端,服務端決議第一部分(header密文),用base64解密,可以知道用了什么演算法，

（2）服務端使用原來的秘鑰與密文(header密文+"."+payload密文)同樣進行HS256運算,然后用生成的簽名與token攜帶的簽名進行比對,若一致說明token合法,不一致說明原文被修改

（3）判斷是否過期,客戶端通過用base64解密第二部分(payload密文),可以知道荷載中授權時間,以及有效期.通過這個與當前時間對比發現token是否過期，

4.2 報文分析

五、option

? 請求和回應都可能包含一個或多個選項的串列，例如，請求中的URI是在幾個選項中傳輸的，而將在HTTP中的HTTP頭中攜帶的元資料也作為選項提供，

5.1 Critical/Elective

? 選項分為兩類:“Critical”和“Elective”，它們之間的區別在于端點無法識別的選項是如何處理的:

• Critical Option：接收方必須可以理解的 Option，不然訊息沒法正常處理
• Elective Option：接收方不識別該 Option 時，能夠忽略，不影響訊息的正常處理

5.2 Proxy Unsafe or Safe-to-Forward and NoCacheKey

? 根據Proxy對于未被識別的Option的處理分為Unsafe or Safe-to-Forward Option，

? 除了將一個選項標記為Critical/Elective外，還根據代理在不識別該選項時如何處理該選項進行分類，為此目的，一個選項可以被認為是不安全的轉發(不安全設定)或安全的轉發(不安全設定)，此外，對于標記為Safe-to-Forward的選項，該選項編號指示它是否打算成為請求中Cache-Key的一部分，如果某些NoCacheKey位是0，則為0;如果所有的NoCacheKey都是1，則它不是，

注意:Cache-Key指示僅適用于那些不將給定選項作為請求選項實作，而只依賴于Unsafe/Safe-to-Forward指示的代理，例如，對于ETag，實際上使用請求選項作為Cache-Key的一部分是非常低效的，但如果ETag不是通過代理實作的，這是最好的方法，因為回應將根據請求選項的存在而不同，實作ETag請求選項的一個更有用的代理是不使用ETag作為Cache-Key的一部分，NoCacheKey以3位表示，因此8個碼點中只有1個是合格的NoCacheKey，而8個碼點中有7個似乎是更可能的情況，

注意：

• 對于不能識別的非重要選項，無聲的忽略該選項，
• 在Con Request中的不能識別的重要選項，需要回傳4.02（請求中包含錯誤選項），且攜帶該選項用于診斷，
• 在Con Response中或者附帶回應資料中不能識別的重要選項，必須拒絕接受這個Response，
• 在Non（不需應答訊息）中不能識別的選項，必須拒絕接受這個訊息（回傳reset并忽略non），
• Rejecting a Confirmable message is effected by sending a matching，Reset message and otherwise ignoring it.（拒絕可確認訊息是通過發送匹配來實作的，重置訊息而忽略它，）

5.3 Length

? 選項值被定義為具有特定的長度，通常是上界和下界的形式，如果請求中的選項值的長度超出了定義的范圍，則必須將該選項視為未識別的選項，

5.4 Option Number

? 選項由選項號標識，選項號還提供了一些額外的語意資訊，例如，奇數表示關鍵選項，而偶數表示可選選項，注意，這不僅僅是一種約定，它是協議的一個特征:一個選項是Critical/Elective，取決于它的Option Number是偶數還是奇數，并且，選項號是用位掩碼構造的，用來指示一個選項是“Critical”還是“Elective”、“Unsafe”還是“ Safe-to-Forward”，并且，在 Safe-to-Forward的情況下，提供一個Cache-Key指示如下圖所示，在下面的文本中，位掩碼表示為一個單位元組，該單位元組應用于無符號整數表示的選項數的最低有效位元組，當第7位(最低有效位)為1時，一個選項是Critical(當0時同樣是optional)，當第6位為1時，一個選項是Unsafe(同樣，當0時是安全轉發的)，當第6位為0時，即，該選項不是不安全的，當且僅當第3-5位全部設定為1時，它不是一個Cache-Key (NoCacheKey);所有其他的位組合意味著它確實是一個Cache-Key，

不同的Option有不同Option Number來表示，

Critical = (onum & 1);
UnSafe = (onum & 2);
NoCacheKey = ((onum & 0x1e) == 0x1c);

5.5 Option Format

一般情況下Option部分包含Option Delta、Option Length和Option Value三部分，

? 【Option Delta】表示Option的增量，當前的Option的具體編號等于之前所有Option Delta的總和，
? 【Option Length】表示Option Value的具體長度，
? 【Option Value】表示Option具體內容

選項中的欄位定義如下：
選項Delta：4位無符號整數，介于0和12之間的值表示期權增量，保留三個值以用于特殊結構體：
13：8位無符號整數緊跟在初始位元組之后，表示期權差值減去13，
14：跟隨網路位元組順序的16位無符號整數初始位元組，表示Option Delta減去269，
15：為有效負載標記保留，如果該欄位設定為此值，但整個位元組不是有效載荷標記，這必須被處理為訊息格式錯誤，

選項長度：4位無符號整數，介于0和12之間的值，指示選項值的長度，以位元組為單位，三個價值觀保留用于特殊構造：
13：選項值前面有一個8位無符號整數，并且表示期權長度減去13，
14：以網路位元組順序排列的16位無符號整數位于選項值，指示選項長度減去269，
15：保留供將來使用，如果該欄位設定為此值，必須將其作為訊息格式錯誤進行處理，

值：正好是“選項長度”位元組的序列，長度和選項值的格式取決于相應的選項，即可以定義可變長度值，

5.6 Option Definitions

? 下表總結了各個CoAP選項，并在本節的小節中進行了解釋，在該表中，C、U和N列分別表示屬性Critical、UnSafe和NoCacheKey，由于NoCacheKey只對安全轉發(沒有標記為不安全)的選項有意義，因此列中填充了一個短橫線表示不安全選項，

5.6.1 Uri-Host, Uri-Port, Uri-Path, and Uri-Query

? 在這些option中，Uri-Host、Uri-Port、Uri-Path和Uri-Query等和資源“位置”和引數有關，

? 【3】Uri-Host:CoAP主機名稱，例如iot.eclipse.org
? 【7】Uri-Port:CoAP埠號，默認為5683
? 【11】Uri-Path:資源路由或路徑，例如\temperature，資源路徑采用UTF8字串形式，長度不計第一個""，
? 【15】Uri-Query:訪問資源引數，例如?value1=1&value2=2，引數與引數之間使用“&”分隔，Uri-Query和Uri-Path之間采用“?”分隔，

5.6.2 Content-Format

? Content-Format選項指示訊息有效負載的表示格式，表示格式是作為一個數字內容格式識別符號給出的，該識別符號在“CoAP ContentFormats”注冊表中定義，如果沒有該選項，則不會假定任何默認值，即任何表示訊息有效負載的表示格式都是不確定的，Internet媒體型別由字串標識，例如“application/xml”，

5.6.3 Accept

? CoAP Accept選項可用于指示客戶端可接受的內容格式，表示格式由數字內容格式識別符號給出，該識別符號在“CoAP內容格式”注冊表(章節12.3)中定義，如果沒有給出Accept選項，則客戶端不會表示首選項(因此不會假定默認值)，客戶端希望服務器回傳的表示是指定的Content-Format，如果可用，服務器將回傳首選的Content-Format，如果首選的ContentFormat不能回傳，則必須發送4.06“不可接受”作為回應，除非另一個錯誤代碼優先此回應，

5.6.4 ETag

? ETag：是物體標簽(Entity Tag)的縮寫，ETag一般不以明文形式回應給客戶端，在資源的各個生命周期中，它都具有不同的值，用于標識出資源的狀態，當資源發生變更時，如果其頭資訊中一個或者多個發生變化，或者訊息物體發生變化那么ETag也隨之發生變化，ETag值的變更說明資源狀態已經被修改，往往可以通過時間戳就可以得到ETag頭資訊，服務器計算ETag值，并在相應客戶端請求時將它回傳給客戶端，

（1）ETag作為回應選項

? 回應中的ETag選項提供物體標簽的當前值(即，在請求被處理后)，用于“標記表示”，如果沒有Location-選項，則標記表示是目標資源的選定表示，如果存在一個或多個Location-選項，并因此指示了一個位置URI，則標記的表示形式將被位置URI的GET請求檢索到，

? ETag回應選項可以包含在任何有標記表示的回應中(例如，它在4.04或4.00回應中沒有意義)，ETag選項在回應中不能出現超過一次，

? ETag選項沒有默認值;如果它不在回應中，服務器就不會對標記表示的物體標記做出任何宣告，

（2）ETag作為請求選項

? 在GET請求中，端點可以為一個或多個存盤回應指定一個ETag Option實體，該端點以前從資源中獲得一個或多個表示，并且已經通過這些表示獲得了ETag回應選項，如果給定的一個ETags是當前表示的，即有效的，服務器可以發出一個2.03有效回應來代替2.05內容回應;然后在回應選項中回傳這個特定的ETag，實際上，客戶端可以確定存盤的表示是否為當前的，而不需要再次傳輸它們，

六、TLV header

? 所謂通訊協議就是指通信雙方對資料傳送控制的一種約定，約定中包括對資料格式，同步方式，傳送速度，傳送步驟，糾錯方式以及控制字符定義等問題做出統一規定，通信雙方必須共同遵守，倘若一方不遵守，便會直接導致資料不能被決議！更通俗來講，它可以理解兩個節點之間為了協同作業實作資訊交換，協商一定的規則和約定，例如規定位元組序，各個欄位型別等，

• Tag：標記；
• Length：一般為value的長度，也可以是整個TLV的長度；
• Value：真正的資料長度，

七、傳輸特性

7.1 Message的可靠傳輸

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ogZhWKrf-1628236557105)(C:\Users\H000021\AppData\Roaming\Typora\typora-user-images\image-20210806152440645.png"/>名稱默認值ACK_TIMEOUT2 secondACK_RANDOM_FACTOR1.5MAX_RETRANSMIT4NSTART1DEFAULT_LEISURE5sPROBING_RATE1 byte/second

• ACK_TIMEOUT*ACK_RANDOM_FACTOR：初始的ACK保護時間（重傳保護時間），隨后的MAX_RETRANSMIT次重傳都乘以2
• NSTART：最大并發的處于活動狀態的Message數目
• DEFAULT_LEISURE：Server休閑時間，用于收到多播Request時，何時回傳Response的隨機時間的計算（上限）
• PROBING_RATE：經過MAX_RETRANSMIT次的Request最終未收到Response后，Requester發送對端的平均速率小于該值

7.2 Request/Respones模型

CoAP Request和Response的語法通過Message承載

可靠傳輸Request的回應方式有兩種：

同步可靠回應模式： 通過Con msg的ACK攜帶Response

異步可靠回應模式：當Server不能立即回應Request時，可以先通過空Ack msg回應Client，當Server準備好后，通過新的CON Msg將resonse發送給Client

非可靠傳輸Request和Response

7.2.1 同步可靠回應模式（piggybacked Response）

7.2.2 異步可靠回應模式（separate Response）

7.3 非可靠回應模式

備好后，通過新的CON Msg將resonse發送給Client

非可靠傳輸Request和Response

7.2.1 同步可靠回應模式（piggybacked Response）

7.2.2 異步可靠回應模式（separate Response）

7.3 非可靠回應模式

附錄：一張表看懂coap