物聯網協議之CoAP協議開發學習筆記之協議詳解

時間 2019-11-08

標籤聯網協議 coap 開發學習筆記詳解简体版

原文原文鏈接

哪有什麼天生如此，只是咱們每天堅持。 -Zhiyuangit

續上篇文章《物聯網協議之CoAP協議開發學習筆記》沒看過的同窗能夠出門左轉。https://segmentfault.com/a/11...
在進入正題以前強烈建議先看一下關於CoAP協議的一些術語，我已經爲你們準備好了github

這篇文章咱們進入正題詳解一下CoAP協議：json

CoAP協議的交互模型

CoAP協議的交互模型與HTTP的客戶端/服務端模型相似。
然而，在M2M的交互場景中，一個使用CoAP協議的設備一般既是客戶端又是服務端。
CoAP中的請求與HTTP協議中的請求相同，是由客戶端發起的，請求一個位於服務端的資源（用URI標識），執行一個動做（用Method Code標識）。而後服務端發回一個響應，帶有一個響應代碼（Response Code），這個響應中有可能也包含一個資源的表現（附帶響應格式）。segmentfault

與HTTP協議不一樣的是，CoAP的交互是異步的，構建於面向數據報的傳輸協議，如UDP。
交互是經過一個消息層來實現的，消息層提供了可選的可靠性支持（採用指數回退）。
CoAP協議中定義了四種類型的消息： CON, NON, ACK和RST。(下文有介紹)這四種類型的消息中包含有請求和響應標識碼，標識着這些消息是請求仍是響應。請求能夠包含在CON和NON兩種類型中，而響應則除了能夠包含在CON和NON之中，還能夠包含在附帶響應的ACK中。安全

從邏輯上，能夠把CoAP協議劃分爲兩層：服務器

消息層
消息層，用於處理UDP數據包和異步；
請求/響應層
請求/響應層，使用Method和Response Code，具體見圖1。

固然，CoAP是一個協議，消息和請求/響應僅僅是其頭部特性。網絡

CoAP的四種消息類型

CON——須要被確認的請求，若是CON請求被髮送，那麼對方必須作出響應。
NON——不須要被確認的請求，若是NON請求被髮送，那麼對方沒必要作出迴應。
ACK——應答消息，接受到CON消息的響應。
RST——復位消息，當接收者接受到的消息包含一個錯誤，接受者解析消息或者再也不關心發送者發送的內容，那麼復位消息將會被髮送。

CoAP消息結構

CoAP的消息格式是很緊湊的，默認運行在UDP上（每一個CoAP消息都是UDP數據包中的數據部分）。
CoAP也能夠運行在DTLS協議上（見9.1節）和其它傳輸協議上，例如SMS，TCP或SCTP，這些不屬於本文檔的範疇（CoAP不支持UDP-lite[RFC3828]和UDP zero checksum[RFC6936]）。app

CoAP消息用二進制格式進行編碼。 這個消息格式以一個固定4個字節的頭部開始。
此後是一個長度在0到8字節之間的Token。Token值以後是0個或多個Type-Length-Value(TLV)格式的選項(Option)。以後到整個數據報的結尾都是payload部分，payload能夠爲空。eclipse

頭部字段定義以下：異步

版本號(Ver)
2-bit無符號整型，表明CoAP版本號。本文檔(7252)的實現必須設置這個字段爲0b01。其它的值爲從此其它版本保留。對於帶有未知版本號的消息，必須忽略。
類型(T)
2-bit無符號整型。表明這個消息的類型是：CON(0), NON(1), ACK(2),或RST(3)。
Token長度(TKL)
4-bit無符號整型。表示變長的Token字段(0-8字節）的長度。長度9-15是保留的，不能設置長度爲9-15。若是設置了長度爲9-15，必須被看成消息格式錯誤來處理。
列代碼(Code)
8-bit無符號整型。拆分爲3-bit的分類信息和5-bit詳細信息。
寫做」c.dd」。c是3-bit長，能夠是一個從0到7的數字，dd是5-bit長，它一個兩位的數字，從00到31。
分類信息c能夠表明是一個請求（0），一個成功的響應（2），一個客戶端錯誤響應（4），或者一個服務端錯誤響應（5）。
全部其它的值都是保留的。代碼0.00是一個特殊的狀況，表示一個空的消息。當消息是一個請求時，Code字段表示請求方法。當響應時，Code字段表明響應代碼。Code字段全部可取的值都在下文CoAP代碼表中定義了。
消息ID(Message ID)
16-bit無符號整型，網絡字節序。用於檢測消息重複以及匹配ACK/RST類型的消息和CON/NON類型的消息。生成消息ID和匹配消息的規則在第4章中講述。
Token值
頭部以後是Token值，能夠有0到8個字節，由Token長度字段指定。這個Token值用於將某個請求和對應的響應關聯。
Options
頭部和Token以後，是0個或多個選項（見3.1節）。一個選項以後，有多是消息結束，也多是另外一個選項，也多是payload標識符和payload部分。
payload部分
在頭部、token和選項以後，是payload部分（能夠沒有payload）。
若是有payload，而且長度不爲0，那麼payload以前有一個固定長度爲一個字節的payload標識符（0xFF），它標誌着選項部分的結束和payload部分的開始。
payload部分從標識符以後開始，一直到這個UDP數據報結束，也就是說，payload部分的長度能夠根據UDP數據報的長度計算出來。
若是沒有payload標識符，那麼就表明這是一個0長度的payload。若是存在payload標識符但其後跟隨的是0長度的payload，那麼必須看成消息格式錯誤處理。

實現注意：0xFF這個值有可能出如今一個選項的長度或選項的值中，因此簡單的掃描0xFF來尋找payload標識符是不可行的。做爲payload標識符的0xFF只可能出如今一個選項結束以後下一個選項有可能開始的地方。

CoAP的URL

在HTTP的世界中，RESTFul協議因爲其簡單性和適用性，在WEB應用中愈來愈受歡迎，這樣的道理一樣適用於CoAP。
一個CoAP資源能夠被一個URI所描述，例如一個設備能夠測量溫度，那麼這個溫度傳感器的URI被描述爲：CoAP://machine.address:5683/sensors/temperature。請注意，CoAP的默認UDP端口號爲5683。

CoAP觀察模式

當你須要去監控某個傳感器例如溫度或溼度等。在這種狀況下，CoAP客戶端並不須要不停的查詢CoAP服務器端的數據變化狀況。
CoAP客戶端能夠發送一個觀察請求到服務器端。從該時間點開始計算，服務器便會記住客戶端的鏈接信息，一旦溫度發生變化，服務器將會把新結果發送給客戶端。
若是客戶端不在但願得到溫度檢測結果，那麼客戶端將會發送一個RST復位請求，此時服務器便會清除與客戶端的鏈接信息。

CoAP塊傳輸

CoAP協議的特色是傳輸的內容小巧精簡，可是在某些狀況下不得不傳輸較大的數據。在這種狀況下可使用CoAP協議中的某個選項設定分塊傳輸的大小，那麼不管是服務器或客戶端可完成分片和組裝這兩個動做。

Option的格式

CoAP定義了許多option。
通常狀況下Option部分包含Option Delta、Option Length和Option Value三部分。
消息中的每一個option都有一個option編號，option值長度，和option值。
消息中的option號（TLV格式中的T）並非直接指定option編號的。
全部的option必須按實際option編號的遞增排列，某一個option和上一個option之間的option編號差值爲delta；
每個TLV格式的option號都是delta值（數據包中第一個option的delta即它的option編號）。
同一個編號的option再次出現時，delta的值爲0。

option編號由「CoAP option編號」表維護（見12.2節）。5.4講述了本文檔中定義的option的語義。（）

一個option之中的各個字段的含義以下：

Option Delta：
表示Option的增量，當前的Option的具體編號。
4-bit無符號整型。值0-12表明option delta。其它3個值做爲特殊狀況保留：
- 當值爲13：有一個8-bit無符號整型（extended）跟隨在第一個字節以後，本option的實際delta是這個8-bit值加13。
- 當值爲14：有一個16-bit無符號整型（網絡字節序）（extended）跟隨在第一個字節以後，本option的實際delta是這個16-bit值加269。
- 當值爲15：爲payload標識符而保留。若是這個字段被設置爲值15，但這個字節不是payload標識符，那麼必須看成消息格式錯誤來處理。
Option Length：
表示Option Value的具體長度。
4-bit無符號整數。值0-12表明這個option值的長度，單位是字節。其它3個值是特殊保留的：
- 當值爲13：有一個8-bit無符號整型跟隨在第一個字節以後，本option的實際長度是這個8-bit值加13。
- 當值爲14：一個16-bit無符號整型（網絡字節序）跟隨在第一個字節以後，本option的實際長度是這個16-bit值加269。
- 當值爲15：保留爲未來使用。若是這個字段被設置爲值15，必須看成消息格式錯誤來處理。
Option Value 共（option Length）個字節。
option值字段的長度和格式取決於具體的option，有可能定義變長的值。3.2節講述了本文檔所使用的option格式。其它文檔中定義的option可能使用其它option值的格式

　CoAP中全部的Option都採用編號的方式，這些Option及編號的定義以下圖所示。

在這些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之間採用「?」分隔。

　　在這些option中，Content-Format和Accept用於表示CoAP負載的媒體格式

　　【12】Content-Format:指定CoAP複雜媒體類型，媒體類型採用整數描述，例如application/json對應整數50，application/octet-stream對應整數40。

　　【17】Accept: 指定CoAP響應複雜中的媒體類型，媒體類型的定義和Content-Format相同。

　　CoAP協議中支持多個Option，例如

　　第一個Option Delta=11，表示該Option表示Uri-Path(11)

　　第二個Option Delta=1，表示該Option=1+11，表示Content-Format(12)

　　第三個Option Delta=3，表示該Option=3+1+11，表示Uri-Query(15)

　　CoAP採用這樣的方式表示多個Option，而每種Option均可以在HTTP協議中找到對應項。

CoAP代碼註冊（CoAP Code Registries）

這篇文檔定義了兩個sub-registries，給CoAP頭部代碼字段的值包含「Constrained RESTful Environments (CoRE) Parameters」註冊表。未來參考「CoRE參數」註冊表。

這兩個sub-registries都是8位值，能夠用三個十進制的符號表示爲「c.dd」,用一個句號將第一位和第二位數字分離開；第一位數字c爲07，表示代碼種類；第二個和第三個數字dd爲0031的十進制數，表示細節。

全部的代碼值都按照sub-registries，按照以下範圍安排：

方法碼(Method Codes) 這個sub-registry是「CoAP Method Codes」
每次進入這個sub-registry都必須包含在0.01-0.31範圍內的Method Code，方法的名字，方法文檔的參考。
初始化進入這個sub-registry以下：

+------+--------+-----------+                       
     | Code | Name   | Reference |                        
     +------+--------+-----------+                        
     | 0.01 | GET    | [RFC7252] |                        
     | 0.02 | POST   | [RFC7252] |                        
     | 0.03 | PUT    | [RFC7252] |                        
     | 0.04 | DELETE | [RFC7252] |                        
     +------+--------+-----------+  
        表 5: CoAP Method Codes

其餘Method Codes沒有安排。

互聯網號碼分配政策在將來爲這個sub-registry額外定義描述在「IETF Review or IESG Approval」 [RFC5226].

方法代碼的文檔須要指定這個請求的語義，包含以下屬性：

1.這個方法的響應碼成功返回。
2.這個方法是否冪等，安全或二者都知足。

響應碼 這個sub-registry的名字是「CoAP Response Codes」
每一個sub-registry必須包含在2.00-5.31範圍內的響應碼，響應碼的描述，響應碼的文檔參考。

初始化進入這個sub-registry以下：

+------+------------------------------+-----------+ 
   | Code | Description                  | Reference |
   +------+------------------------------+-----------+
   | 2.01 | Created                      | [RFC7252] | 
   | 2.02 | Deleted                      | [RFC7252] |
   | 2.03 | Valid                        | [RFC7252] |
   | 2.04 | Changed                      | [RFC7252] |
   | 2.05 | Content                      | [RFC7252] |
   | 4.00 | Bad Request                  | [RFC7252] |
   | 4.01 | Unauthorized                 | [RFC7252] | 
   | 4.02 | Bad Option                   | [RFC7252] |
   | 4.03 | Forbidden                    | [RFC7252] | 
   | 4.04 | Not Found                    | [RFC7252] | 
   | 4.05 | Method Not Allowed           | [RFC7252] | 
   | 4.06 | Not Acceptable               | [RFC7252] | 
   | 4.12 | Precondition Failed          | [RFC7252] | 
   | 4.13 | Request Entity Too Large     | [RFC7252] |  
   | 4.15 | Unsupported Content-Format   | [RFC7252] |  
   | 5.00 | Internal Server Error        | [RFC7252] |
   | 5.01 | Not Implemented              | [RFC7252] | 
   | 5.02 | Bad Gateway                  | [RFC7252] |  
   | 5.03 | Service Unavailable          | [RFC7252] | 
   | 5.04 | Gateway Timeout              | [RFC7252] | 
   | 5.05 | Proxying Not Supported       | [RFC7252] | 
   +------+------------------------------+-----------+ 
        表 6: CoAP Response Codes

響應碼3.00-3.31是預留給未來使用。全部其餘響應碼都沒有被安排。

互聯網號碼分配政策爲這個sub-registry之後額外的定義描述在「IETF Review or IESG Approval」[RFC5226].

響應碼的文檔須要指定這個響應的語義，包含以下屬性：

響應碼應用方式
是否須要攜帶payload，option。
payload的語義。舉個例子，2.05（內容）響應的payload是目標資源的展現；payload在錯誤的響應中是可讀和診斷的。
payload的格式。舉個例子，這個格式在2.05（內容）響應是經過內容格式選項表示；payload的格式在一個錯誤的
響應中老是Net-Unicode文本
響應是否能夠緩衝，取決於freshness model
響應是否經過合法性檢查，取決於validation model
響應是否致使一個cache來標誌響應已經存儲，代表這個請求的URI不是最新的。

Content-Format描述

CoAP支持多種媒體類型，具體可參考RFC7252 #12.3。從下圖的信息能夠發現，CoAP協議中關於媒體類型的定義比較簡單，將來應該會根據實際狀況擴展。

圖5.1 Content-Format編號內容

　　【text/plain】編號爲0，表示負載爲字符串形式，默認爲UTF8編碼。

　　【application/link-format】編號爲40，CoAP資源發現協議中追加定義，該媒體類型爲CoAP協議特有。

　　【application/xml】編號爲41，表示負載類型爲XML格式。

　　【application/octet-stream】編號爲42，表示負載類型爲二進制格式。

　　【application/exi】編號爲47，表示負載類型爲「精簡XML」格式。(翻譯不必定準確)

　　另外，還有一種格式也北IANA認定，也會在CoAP協議中普遍使用那即是CBOR格式，該格式可理解爲二進制JSON格式。

　　【applicaiton/cbor】編號爲60。

示例

　該示例來自於RFC7252。

　　【流程描述】

　　CoAP客戶端經過GET方法從Server端得到溫度傳感器數據，CoAP URI以下
　coap://www.server.com/temperautre

　　CoAP請求採用CON報文，Server接收到CON報文必須返回一個ACK報文。
CoAP請求採用0.01 GET方法，若操做成功CoAP Server返回2.05 Content，至關於HTTP 200 OK。請求和響應的MID必須徹底相同，此處爲0x7d34。請求響應中的Token域爲空。CoAP請求中包含Option，該Option的類型爲Uri-Path，那麼Option Delta的值爲0+11=11，Option Value的值爲字符串形式的「temperature」。
CoAP返回中包含溫度數據，使用字符串形式描述，具體值爲"22.3"。