CoAP 協議解析說明（轉）

 

---

CoAP 協議全面分析

 

HTTP與COAP 請求與響應示例

HTTP請求（文本格式）

POST https://getman.cn/echo HTTP/1.1
User-Agent: Fiddler
Host: getman.cn
Content-Length: 9

{temp:22}

HTTP響應（文本格式）

HTTP/1.1 200 OK
Server: NWSs
Date: Thu, 07 Dec 2017 14:38:25 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Cache-Control: private, no-cache
Vary: Accept-Encoding
X-Powered-By: PHP/7.1.7
Access-Control-Allow-Origin: *
X-NWS-LOG-UUID: 6bac6a30-99fb-4441-8c04-fe0f6556e5b7
X-Daa-Tunnel: hop_count=2
Content-Length: 298

POST /echo HTTP/1.1
X-DAA-TUNNEL: hop_count=2
X-TENCENT-UA: Qcloud
QVIA: 7f0000016285484627467c8660a39b6bbf1af144
X-NWS-LOG-UUID: 6bac6a30-99fb-4441-8c04-fe0f6556e5b7
X-FORWARDED-PROTO: https
X-FORWARDED-FOR: 223.73.213.93
USER-AGENT: Fiddler
CONTENT-LENGTH: 9
HOST: getman.cn

{temp:22}

COAP請求與響應

• COAP SPEC裏面例子（二進制格式） 
  

• COAP firebox copper插件log（已把二進制解析爲文本，能夠直觀的瞭解該協議所包含內容）

COAP請求與響應都會放在COAP Message裏面。

HTTP 與 COAP協議都是經過4個請求方法（GET, PUT, POST, DELETE）對服務器端資源進行操做。 二者之間明顯的區別在於HTTP是經過文本描述方式描述協議包內容，協議包裏面會包含一些空格符，換行符等,協議包可讀性很強。而COAP是經過定義 二進制各位段功能來描述協議包內容。 所以COAP協議包大小更小，更緊湊。COAP協議最小的協議包只有4B。 協議包須要通過解析後才能知道里面具體內容，另還有一個明顯的區別是傳統的HTTP協議是主機與web服務器之間是單向通訊的（用websocket除外）。而CoAP系統中CoAP Client與CoAP server是能夠雙向通訊，雙方均可以主動向對方發送請求。

COAP協議背景

在物聯網應用裏面， 設備與設備之間都存在網絡裏面，它們須要互相進行網絡通訊。 但因爲一般物聯網設備都是資源限制型的，有限的CPU能力，有限RAM,有限的flash，有限的網絡帶寬， 針對此類特殊場景，COAP協議借鑑了HTTP協議機制並簡化了協議包格式。簡潔地實現了物聯網設備之間M2M通訊。

COAP協議特色

1. 基於消息模型，定義了4個消息類型，以消息爲數據通訊載體，經過交換網絡消息來實現設備間數據通訊
2. 對CoAP Server雲端設備資源操做都是經過請求與響應機制來完成，相似HTTP，設備端可經過4個請求方法（GET, PUT, POST, DELETE）對服務器端資源進行操做。 請求與響應的數據包都是放在CoAP消息裏面進行傳輸的
3. 基於消息的雙向通訊（M2M），CoAP Client與CoAP server雙方均可以獨立向對方發送請求.雙方可當client或者server角色。
4. 協議包輕量級，最小長度僅爲4B。
5. 支持可靠傳輸，數據重傳，塊傳輸。 確保數據可靠到達。
6. 支持IP多播, 便可以同時向多個設備發送請求（好比CoAP client搜索CoAP Server）
7. 非長鏈接通訊，適用於低功耗物聯網場景

COAP具體協議介紹

協議框架

CoAP默認運行在UDP上，但它也支持運行在SMS,TCP等數據傳輸層上。本文主要是基於UDP上的CoAP協議介紹

1.消息模型 Messages

---

COAP協議通訊是經過在UDP上傳輸消息類完成。UDP比做公路話，消息就是公路上汽車。

COAP定義了4種類型消息，來實現設備端與雲端之間雙向通訊

1. 須要確認消息   CON
2. 不須要確認消息  NON （適用於消息會重複頻繁的發送，丟掉消息不對業務產生影響）
3. 確認應答消息   ACK
4. 復位消息  RST

基於4種消息類型，能夠實現2種傳輸質量。便可靠消息傳輸 與 不可靠消息傳輸。

怎麼是可靠消息傳輸？

主要是經過確認及重傳機制來實現的，客戶端發送消息後，須要等待服務器收到通知， 若是在規定時間內，沒有收到須要從新發送數據。 可靠傳輸是基於CON消息傳輸的，服務器端收到CON類型的消息後，須要返回ACK消息，客戶端到在指定時間ACK_TIMEOUT內收到ACK消息後，才表明這個消息以可靠到服務器端。

怎麼是不可靠消息傳輸？

客戶端只管發送消息， 無論服務器端有沒有收到，所以可能存在丟包。不可靠傳輸是基於NON消息傳輸的。服務器端收到NON類型的消息後，不用回覆ACK消息。

2.資源請求/響應模型 Requests/Responses

---

對於物聯網，服務器上的資源能夠簡單的認爲是物聯網設備的實時運行影子， 經過訪問服務器上資源就能夠實現與設備間數據的交互。 上面談到的消息模型好比汽車話， 資源請求及響應比如汽車上貨物。 資源請求及響應內容最終會被放在CoAP消息包裏面。CoAP請求與響應，相似HTTP，且根據RESTful架構設計的。 CoAP客戶端發出請求，CoAP服務端進行請求處理而後發送響應。

COAP 請求Request方法： 請求方法與HTTP協議相似，有4個。 GET, PUT, POST, DELETE， 全部的請求方法都會放在CoAP CON/NON消息裏面進行傳輸。

COAP 請求響應Response代碼： 響應內容也與HTTP協議相似。 主要有以下3類：

• Success 2.xx 表明客戶端請求被成功接收並被成功處理
• Client Error 4.xx 表明客戶端請求有錯誤，好比參數錯誤等
• Server Error 5.xx 表明服務器在執行客戶端請求時出錯。

全部的請求服務器響應能夠放在CoAP CON/NON/ACK消息裏面進行傳輸。針對CoAP 帶CON消息請求，響應若是快速處理完（有些請求的處理須要耗時多，服務器沒法當即響應），則可直接放在ACK消息包裏面返回。對於沒法當即響應的，服務器帶資源ready後，會單獨發一個響應消息包給客戶端

服務器上可訪問資源統一用URL來定位（好比/deviceID/temp 訪問某個設備的溫度信息）。客戶端經過某個資源的URL來訪問服務器具體資源，經過4個請求方法（GET,PUT,POST,DELETE）完成對服務器上資源增刪改查操做。

舉個例子： 好比某個設備須要從服務器端查詢當前溫度信息。

• 請求消息（CON）： GET /temperature , 請求內容會被包在CON消息裏面
• 響應消息 (ACK)： 2.05 Content "22.5 C" ，響應內容會被放在ACK消息裏面

3.消息報文定義 Messages Define

---

Header（必須）：固定4個byte

• Ver : 2bit， 表明版本信息，當前是1
• T： 2bit， 表明該消息類型， CON, NON. ACK, RST
• TKL: 4bit，token長度， 當前支持0~8B長度，其餘長度保留未來擴展用
• Code：8bit，分紅前3bit（0~7）和後5bit（0~31），前3bit表明類型。 0表明空消息或者請求碼， 2開頭表明響應碼，取值以下：

0.00 Indicates an Empty message
0.01-0.31 Indicates a request.
1.00-1.31 Reserved
2.00-5.31 Indicates a response.
6.00-7.31 Reserved

• Message ID：16bit， 表明消息MID，每一個消息都有一個ID ，重發的消息MID不變。

token（可選）

也叫作請求ID。把響應與以前的請求關聯起來。有時候客戶端發送出請求帶上token，服務器端有時不能當即響應， 當服務器端準備好數據後，會單獨發送一個消息給客戶端， 這時候客戶端須要判斷這個消息是針對以前的哪一個請求回覆的，token用途就在這裏，經過token，客戶端收到響應後，取出TOKEN，就能夠知道該響應是針對以前哪一個請求回覆的。

option（可選，0個或者多個）

請求消息 與迴應消息均可以0~多個options。 主要用於描述請求或者響應對應的各個屬性，相似參數或者特徵描述。

payload（可選）

實際攜帶數據內容， 如有， 前面加payload 標誌 OxFF.

 

option 介紹

格式

當一個消息報文裏面有多個option時，每一個option須要按照該option在協議裏面對應的編號順序排列下來。而且每一個option索引是經過增量來計算的。option Delta 表明相對於前面一個option編號的增量。

舉個例子 
假設前面一個option編號爲20， 當前option編號爲25，則當前option的增量Delta就設置爲5 
增量最大可佔用2個byte， 計算方式以下
當option Delta = 0~12時，只佔4bit。
當option Delta =13 則佔1B， 實際數字是option Delta【extended】 - 13 
當option Delta =14 則佔2B ， 實際數字是option Delta【extended】 - 269

COAP 支持OPTION編號列表， 是HTTP協議 options 子集。

舉例 Uri-Host:服務器主機名稱，如californium.eclipse.org 
Uri-Port:服務器端口號，默認爲5683 
Uri-Path:資源路路徑，如\temperature 
Uri-Query:訪問資源參數，例如?v=1&t=2

4.塊傳輸

---

須要傳輸大量數據時，好比一個大文件，須要採用分塊傳輸，把文件拆解成多個塊進行傳輸。擴展的塊傳輸協議在COAP基礎協議上增長了3個options， 2個response codes 用於塊傳輸大小協商及控制。

 

block option結構

有三部分組成：
SZX: Block Size，佔用2bit，取值範圍0~6，對應每一個block 大小爲2xx（SZX+4），即範圍（16 ~ 1024），以Byte爲單位
M: More Flag，佔用1bit， 表明是否還有剩下數據塊未傳輸。若是設置爲0，表明數據塊都已傳輸出去
NUM: Block Number， 佔用0~3Byte，表明當前塊編號，以0開始， 如咱們要傳10個數據塊，則數據塊的編號爲0~9

option block1： 主要用於客戶端發出請求時，分塊傳輸，好比須要上傳一個大的數據包到服務器上。
option block2： 主要用於服務器端響應時，分塊傳輸， 好比設備端發起資源發現式，因爲服務器上資源較多，就要啓動分塊傳輸。

Size option

主要用於向對方說明，此次塊傳輸須要傳送的數據總數量。
Size1 option： 表明客戶度發出請求裏面資源總的大小。
Size2 option： 表明服務器端響應資源總的大小。

如何啓動塊傳輸？

當請求消息或者響應消息裏面有出息 block1/block2 option時，表明這是塊傳輸通訊。須要根據option block 裏面M標識，決定是否繼續進行塊傳輸。

示例
第一個消息，客戶端發起發現資源請求信息CON並設置Block2：0(NUM)/0(M)/64（SZX）告訴服務器端，能接受最大block size爲64.
第二個消息。服務器端回覆確認消息ACK，並設置Block2：0/1/64，告訴客戶端，block size已接受爲64， 且後面還有數據，當前傳輸塊編號是0. size2：1094， 告訴客戶端，接下來總的數據大小是1094B。
第三個消息，客戶端發起請求獲取下一個block。設置Block2：1/0/64.告訴服務器端下一個要獲取的block編號是1.

5.訂閱與發佈

---

MQTT協議是基於訂閱與發佈模型的，coap經過擴展協議方式也簡單的實現了訂閱與發佈模型。

當一個客戶端須要按期去查詢服務器端某個資源的最新狀態時，訂閱與發佈模型就很是有用，不用這個模型，客戶端就要週期的不斷髮送請求到服務器端。

模型框架

關鍵概念 主題Subject： 表明CoAP服務器上的某個資源resource，該資源狀態隨時可能發生變化 觀察者Observer：表明對某個coap資源最新狀態感興趣的客戶端CoAP Client 登記Registration： 觀察者須要向服務器CoAP server登記感興趣的主題Subject。 
通知Notification：當CoAP觀察到某個主題發生狀態變化時，CoAP服務器會主動向該主題下的已登記的觀察者列表裏面的每一個觀察者發送其訂閱的主題最新狀態數據。 備註：若是已訂閱某個主題的CoAP client對CoAP server Notification沒法確認，則會從主題訂閱列表裏面移除掉。

訂閱與發佈協議在COAP基礎協議上增長了1個Observe option， 其值爲整數，經過該options來實現訂閱與發佈模型管理

在get請求消息裏面
oberser value 爲 0： 表明向CoAP服務器端訂閱一個主題。 
oberser value 爲 1： 表明向CoAP服務器端移除一個已訂閱主題。

在notification消息裏面
oberser value 表明 主題發生變化時，檢測到順序，以便客戶端能夠知道狀態變化的前後。

舉個例子

1. 客戶端向服務器端登記感興趣的主題 /temperature 
2. 當temperature發生狀態改變時，服務器端主動通知到客戶端。 
3. 客戶端根據token，就能夠與以前訂閱主題關聯起來，以此肯定是哪一個主題訂閱的。

一個CoAP Client能夠分次向CoAP server訂閱多個資源主題。 一個CoAP server上的主題能夠被多個觀察者（CoAP Client）訂閱。 這樣就經過了CoAP server實現了CoAP Client之間直接數據轉發通訊。

能夠經過靈活設計服務器上的資源連接，來實現對某個主題的條件訂閱（相似觸發器或者閥值等）。 好比訂閱主題是: <coap://server/temperature/critical?above=42>， 當溫度超過42，CoAP Server須要發送通知。

6.安全

---

COAP使用DTLS來作安全傳輸層，該層運行於UDP之上.
 
當前考慮使用DTLS時，須要考慮設備終端資源受限狀況， 有些資源有限設備沒法運行DTLS安全加密算法。

作安全加密，須要根據應用場景須要，對應只上報數據，且數據敏感度不高場景，能夠不考慮加入安全層。