CoAP協(xié)議格式詳解

CoAP是受限制的應用協(xié)議(ConstrainedApplicationProtocol)的代名詞。在當前由PC機組成的世界，信息交換是通過TCP和應用層協(xié)議HTTP實現(xiàn)的。但是對于小型設備而言，實現(xiàn)TCP和HTTP協(xié)議顯然是一個過分的要求。為了讓小設備可以接入互聯(lián)網(wǎng)，CoAP協(xié)議被設計出來。CoAP是一種應用層協(xié)議，它運行于UDP協(xié)議之上而不是像HTTP那樣運行于TCP之上。CoAP協(xié)議非常小巧，最小的數(shù)據(jù)包僅為4字節(jié)。1CoAP協(xié)議綜述和其他TCPIP協(xié)議簇中的協(xié)議一樣，CoAP協(xié)議總是以“頭”的形式出現(xiàn)在負載之前，而負載和CoAP頭之間使用單字節(jié)0xFF分離。學習CoAP協(xié)議最好的方法便是結(jié)合RFC文檔，詳細分析CoAP協(xié)議報文格式的每一部分，便是CoAP協(xié)議報文結(jié)構(gòu)示意圖。圖1.1CoAP協(xié)議報文結(jié)構(gòu)示意圖2CoAP協(xié)議報文各部分【Ver】版本編號，指示CoAP協(xié)議的版本號。類似于HTTP1.0HTTP1.1。版本編號占2位，取值為01B?！綯】報文類型，CoAP協(xié)議定了4種不同形式的報文，CON報文，NON報文，ACK報文和RST報文?！綯KL】CoAP標識符長度。CoAP協(xié)議中具有兩種功能相似的標識符，一種為MessageID(報文編號)，一種為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)。【MessageID】報文編號【Token】標識符具體內(nèi)容，通過TKL指定Token長度?！綩ption】報文選項，通過報文選項可設定CoAP主機，CoAPURI，CoAP請求參數(shù)和負載媒體類型等等。【11111111B】CoAP報文和具體負載之間的分隔符。3Code部分詳解Code部分被分成了兩部分，為了便于閱讀，Code被描述為c.dd形式。具體內(nèi)容可參考RFC7252#12.1.1MethodCodes3.1請求在CoAP請求中，Code被定義為CoAP請求方法，這些方法有GET、POST、PUT和DELETE，這些方法和HTTP協(xié)議非常相似?！?.01】GET方法——用于獲得某資源【0.02】POST方法——用于創(chuàng)建某資源【0.03】PUT方法——用于更新某資源【0.04】DELETE方法——用于刪除某資源3.2響應在CoAP響應中，Code被定義為CoAP響應碼，類似于HTTP200OK等等。【2.01】Created【2.02】Deleted【2.03】Valid【2.04】Changed【2.05】Content。類似于HTTP200OK【4.00】BadRequest請求錯誤，服務器無法處理。類似于HTTP400?！?.01】Unauthorized沒有范圍權限。類似于HTTP401。【4.02】BadOption請求中包含錯誤選項。【4.03】Forbidden服務器拒絕請求。類似于HTTP403?！?.04】NotFound服務器找不到資源。類似于HTTP404。【4.05】MethodNotAllowed非法請求方法。類似于HTTP405?！?.06】NotAcceptable請求選項和服務器生成內(nèi)容選項不一致。類似于HTTP406。【4.12】PreconditionFailed請求參數(shù)不足。類似于HTTP412?！?.15】UnsupporConten-Type請求中的媒體類型不被支持。類似于HTTP415?！?.00】InternalServerError服務器內(nèi)部錯誤。類似于HTTP500。【5.01】NotImplemented服務器無法支持請求內(nèi)容。類似于HTTP501?！?.02】BadGateway服務器作為網(wǎng)關時，收到了一個錯誤的響應。類似于HTTP502?！?.03】ServiceUnavailable服務器過載或者維護停機。類似于HTTP503。【5.04】GatewayTimeout服務器作為網(wǎng)關時，執(zhí)行請求時發(fā)生超時錯誤。類似于HTTP504。【5.05】ProxyingNotSupported服務器不支持代理功能。4Option部分詳解CoAP支持多個Option，CoAP的Option的表示方法比較特殊，采用增量的方式描述，細節(jié)可參考RFC7252#3.1圖4.1CoAP部分Option定義一般情況下Option部分包含OptionDelta、OptionLength和OptionValue三部分?！綩ptionDelta】表示Option的增量，當前的Option的具體編號等于之前所有OptionDelta的總和。【OptionLength】表示OptionValue的具體長度。【OptionValue】表示Option具體內(nèi)容CoAP中所有的Option都采用編號的方式，這些Option及編號的定義如下圖所示。圖4.2Option編號內(nèi)容在這些option中，Uri-Host、Uri-Port、Uri-Path和Uri-Query等和資源“位置”和參數(shù)有關?！?】Uri-Host:CoAP主機名稱，例如【7】Uri-Port:CoAP端口號，默認為5683【11】Uri-Path:資源路由或路徑，例如\temperature。資源路徑采用UTF8字符串形式，長度不計第一個"\"。【15】Uri-Query:訪問資源參數(shù)，例如?value1=1&value2=2，參數(shù)與參數(shù)之間使用“&”分隔，Uri-Query和Uri-Path之間采用“?”分隔。在這些option中，Content-Format和Accept用于表示CoAP負載的媒體格式【12】Content-Format:指定CoAP復雜媒體類型，媒體類型采用整數(shù)描述，例如application/json對應整數(shù)50，application/octet-stream對應整數(shù)40。【17】Accept:指定CoAP響應復雜中的媒體類型，媒體類型的定義和Content-Format相同。CoAP協(xié)議中支持多個Option，例如第一個OptionDelta=11，表示該Option表示Uri-Path(11)第二個OptionDelta=1，表示該Option=1+11，表示Content-Format(12)第三個OptionDelta=3，表示該Option=3+1+11，表示Uri-Query(15)CoAP采用這樣的方式表示多個Option，而每種Option都可以在HTTP協(xié)議中找到對應項。5Content-Format描述CoAP支持多種媒體類型，具體可參考RFC7252#12.3。從下圖的信息可以發(fā)現(xiàn)，CoAP協(xié)議中關于媒體類型的定義比較簡單，未來應該會根據(jù)實際情況擴展。圖5.1Content-Format編號內(nèi)容【text/plain】編號為0，表示負載為字符串形式，默認為UTF8編碼。【application/link-format】編號為40，CoAP資源發(fā)現(xiàn)協(xié)議中追加定義，該媒體類型為CoAP協(xié)議特有?！綼pplication/xml】編號為41，表示負載類型為XML格式?！綼pplication/octet-stream】編號為42，表示負載類型為二進制格式?！綼pplication/exi】編號為47，表示負載類型為“精簡XML”格式。(翻譯不一定準確)另外，還有一種格式也北IANA認定，也會在CoAP協(xié)議中廣泛使用那便是CBOR格式，該格式可理解為二進制JSON格式。【applicaiton/cbor】編號為60。6示例該示例來自于RFC7252?！玖鞒堂枋觥緾oAP客戶端通過GET方法從Server端獲得溫度傳感器數(shù)據(jù)，CoAPURI如下coap:///temperautreCoAP請求采用CON報文，Server接收到CON報文必須返回一個ACK報文。CoAP請求采用0.01GET方法，若操作成功CoAPServer返回2.05Content，相當于HTTP200OK。請求和響應的MID必須完全相同，此處為0x7d