Update Log:

2017/12/21 發布初版
2018/06/14 更清晰的，更全面的描述了CoAP協議關鍵內容
阿裏雲代金券分享，最高1888，阿裏雲雙11活動優惠力度大，有打算購買雲服務器的小夥伴建議近期買劃算，助力大家低成本上雲，能省就省。
點擊獲取阿裏雲代金券1888

深圳博達智聯出品，轉載需要原文轉載並註明出處
深圳博達智聯，專註於提供量身定制的物聯網設備雲平臺端到端整體解決方案

COAP協議全面分析

##HTTP與COAP 請求與響應示例
###HTTP請求（文本格式）

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

{temp:22}
1
2
3
4
5
6
###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

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}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
###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協議機制並簡化了協議包格式。簡潔地實現了物聯網設備之間通信。

##COAP協議特點

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

###協議框架

運行在UDP上

###1.消息模型 Messages
COAP協議通信是通過在UDP上傳輸消息類完成。UDP比作公路話，消息就是公路上汽車。

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

1. 需要確認消息 CON
2. 不需要確認消息 NON （適用於消息會重復頻繁的發送，丟掉消息不對業務產生影響）
3. 確認應答消息 ACK
4. 復位消息 RST
1
2
3
4
基於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（07）和後5bit（031），前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
1
2
3
4
5
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： 代表向服務器端訂閱一個主題。
oberser value 為 1： 代表向服務器端移除一個已訂閱主題。

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

舉個例子

客戶端向服務器端登記感興趣的主題 /temperature
當temperature發生狀態改變時，服務器端主動通知到客戶端。
客戶端根據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安全加密算法。

做安全加密，需要根據應用場景需要，對應只上報數據，且數據敏感度不高場景，可以不考慮加入安全層。

###7.參考協議
COAP基本協議RFC7252
塊傳輸協議 RFC7959
訂閱與發布 RFC7641

轉載請註明出處

獲取物聯網設備端及web應用服務平臺端源代碼
https://www.adminiot.com.cn/modules/1.html

了解更多物聯網技術資訊，物聯網開放代碼，IOT解決方案請訪問
www.adminiot.com.cn
---------------------
作者：博達智聯
來源：CSDN
原文：https://blog.csdn.net/robert_tina/article/details/78864345
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！

COAP協議全面分析--轉載