1、CoAP(The Constrained Application Protocol)协议详解,Jade 2016/12,目录,概述 Message Model Request/Response Model Options CoAP组播 CoAP代理 Securing CoAP,CoAP是什么,CoAP是IETF为满足物联网，M2M场景制定的协议，特点如下： 类似HTTP，基于REST模型：Servers将Resource通过URI形式呈现，客户端可以通过诸如GET,PUT,POST,DELETE方法访问，但是相对HTTP简化实现降低复杂度（代码更小，封包更小） 应用于资源受限的环境（内存，存储
2、，无良好的随机源），比如CPU为8-bit的单片机，内存32Kb，FLASH 256Kb 针对业务性能要求不高的应用：低速率(10s of kbit/s)，低功耗 满足CoRE环境的HTTP简化增强版本,协议模型,特征 基于UDP的类似HTTP的Client/Server交互模型 Client发送Request(携带不同method)请求对资源(通过URI表示)的操作，Server返回Response(携带资源的representation)和状态码 在M2M应用场景，Endpoint实际同时是Server和Client,逻辑上分为Message和Request/Response两层，Requ
3、est/Response通过Message承载，从封包上不体现这种层次结构 DTLS(Datagram Transport Layer Security)可选 由于基于UDP，支持组播,协议参与方,协议定义了如下角色： Endpoint：CoAP协议的参与方 Sender：发出Message的Endpoint，等于source Endpoint Recipient：Message的目的Endpoint，等于destination Endpoint Client：发出Request的Endpoint，Response的destination Endpoint Server：Request的des
4、tination Endpoint，Response的source Endpoint Origin Server：resource的所在的Server Intermediary：既作为Server由作为Origin Server的Client的Endpoint。可以理解为是Proxy的统称,协议参与方-续,Proxy：一种Intermediary，完成Request前转，Respone中继，执行缓存，namespace转换，协议转换等功能的Endpoint，基于前转请求架构中的位置，协议定义了forward-proxy和reverse-proxy两种代理 Forward-Proxy：被Clie
5、nt用于代表Client执行Request，并完成任何必要的转换。 Reverse-Proxy：代表一个或多个其他服务器并代表它们满足请求，执行任何必要的翻译的端点。 与转发代理不同，客户端可能不知道它正在与反向代理通信; 反向代理接收请求，就像它是目标资源的源服务器一样。 CoAP-to-CoAP Proxy：映射CoAP request到CoAP request Cross-Proxy：跨协议代理，比如COAP-to-HTTP和HTTP-to-COAP,目录,概述 Message Model Request/Response Model Options CoAP组播 CoAP代理 Secu
6、ring CoAP,Message模型,CoAP Message用于承载Request/Response模型，有两种模式： Reliability Mode Confirmable Message需要Acknowledgement Message确认 Confirmable Message和Acknowledgement Message通过Message ID匹配 Non-Reliability Mode Non-Confirmable Message不需要Acknowledgement Message确认,Message Format,Messge组成部分 固定4字节的头部 变长的Token
7、(0-8byte) 0或多个TLV格式的Option 可选的Payload Message承载信息 Request Response Empty Message（只有message header，且code为0.00）,Message Header,Ver：2bit version，当前版本为01，版本号非1的消息直接丢弃 T: Message type:Confirmable(0),Non-confirmable(1),Acknowledgement(2),Reset(3) TKL：Token length，当前有效取值0-8，其他认为是Message format error,Messag
8、e Format,Code: Code：8 bit无符号数，格式:c(3bit class type).dd(5bit detail code) Class分类： 0：表示message为request，dd表示具体的method：0.01 表示GET，0.02表示POST,0.03表示PUT，0.04表示DELETE，特例，0.00表示empty message 2: succsee 4: client error 5: server error Message ID：用于message的重复性检测，以及Confirmable msg，non-Confirmable msg和ACK、rese
9、t msg的匹配 Token：用于匹配Request和Response Option：可以0个或多个，每一个Option之后，可以是一个Option，或者是Payload Maker和Payload或者message结束 Payload：如果有payload，必然是payload marker(0xFF)和直到udp报文结尾的payload。Payload marker和payload必然同时出现,Message分类,协议定义的Message有如下几种 Confirmable Message：需要确认的消息，Receipt方必须对消息回复Acknowledgement或者Reset Non-c
10、onfirmable Message：不需要确认的消息，但是Receipt方可能回复Reset Acknowledgement Message：用于向Sender确认Confirmable Message已收到，可以携带Piggybacked Response Reset Message：用于回复收到的无法处理的Message(Confirmable和Non-confirmable Message)，也可通过一个Empty的Confirmable Message触发一个Rest，用于Endpoint的保活检测 Empty Message：一个code为0.00的既不是request也不是res
11、ponse的Message。Empty Message并不是协议定义和上述Messge并列的type，它只是一种特殊含义的Message,Message和Response映射关系,*：表示此种情况只是为了让接收方发出Reset msg,Message的可靠传输,Client构造Con Msg发送到Server，未收到ACK或Reset时，支持基于指数回退的重发 Server如果可以处理该Message，返回ACK，否则返回Reset,Endpoint匹配 CON和ACK/Reset Message中携带Message ID用于配对是一次可靠传输过程，支持重复检测 简单的停等基于指数回退的重传机
12、制保证靠性,Message的可靠传输,Message的可靠传输由一个Confirmable msg发起； Confirmable msg总是承载一个Request或Response，除非是一个为了触发Reset msg的empty msg Receipt收到一个Confirmable msg，处理结果是：回复一个Acknowledgement msg（携带匹配的message ID）或者在如下情况下Rejecting一个消息：recipient不能正确处理message；message是一个empty message，message中的code是1,6,7；Message存在格式错误 Reje
13、cting一个msg的结果是回复Reset msg或者忽略它,Message的可靠传输相关参数,ACK_TIMEOUT*ACK_RANDOM_FACTOR：初始的ACK保护时间(重传保护时间)，随后的MAX_RETRANSMIT次重传都乘以2 NSTART：最大并发的处于活动状态的Message数目 DEFAULT_LEISURE: Server休闲时间，用于收到多播Request时，何时返回Response的随机时间的计算（上限） PROBING_RATE：经过重传MAX_RETRASMIT次的Request最终未收到Response后，Requester发送对端的平均速率要小于该值,Mes
14、sage的可靠传输导出参数,MAX_TRANS_SPAN：最大重传时间=ACK_TIMEOUT * (2 * MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR=2*（16-1）*1.5=45s MAX_TRANSMIT_WAIT：最大等待响应时间=ACK_TIMEOUT * (2 * (MAX_RETRANSMIT + 1) - 1) *ACK_RANDOM_FACTOR=2*（32-1）*1.5=93=45+2*1.5*16=93s MAX_LATENCY：封包从发送到期望完成接收的最大保护时间=100s(协议参考MSL直接随意定义)，即封包在传输链路上的时间
15、 PROCESSING_DELAY:接收方从接收到该消息到发出响应的处理时间=ACK_TIMEOUT=2s MAX_RTT:最大往返时间=2*MAX_LATENCY+PROCESSING_DELAY=202s EXCHANGE_LIFETIME=MAX_TRANSMIT_SPAN + (2 * MAX_LATENCY) +PROCESSING_DELAY=45+200+2=247s NON_LIFETIME：non消息的Message ID最大安全重用保护时间=MAX_TRANS_SPAN+MAX_LATENCY=145,Message的非可靠传输,Client对于不需要可靠传输的Messag
16、e通过Non-Confirmable Msg传递 虽然不需要ACK确认NON Msg，Server仍然可能会返回Reset给Client(比如Server不能处理这个NON msg),NON msg中仍然携带Message ID用于重复检测,Message的非可靠传输,Message的非可靠传输由一个NON msg发起 NON msg总是承载一个Request或者Response，但是不能是一个Empty msg 不能用Acknowledgement msg回复NON msg 虽然不需要ACK确认NON Msg，Server仍然可能会返回Reset给Client(比如Server不能处理这个N
17、ON msg) Receipt收到一个NON msg，在如下情况下Rejecting一个消息：recipient不能正确处理message；message是一个empty message，message中的code是1,6,7；Message存在格式错误 Rejecting一个msg的结果是回复Reset msg或者忽略它 由于Sender不能确认Receipt是否收到NON msg，所以可以重传多次，Receipt通过Msg ID检测是否是重复消息,目录,概述 Message Model Request/Response Model Options CoAP组播 CoAP代理 Securin
18、g CoAP,Request/Response模型,CoAP Request和Response的语法通过Message承载 可靠传输的Request的Response方式(Piggybacked Response)： 同步可靠响应模式(piggybacked response)：通过Con msg的Ack携带Response异步可靠响应模式(Separate Response)：当server不能立即响应Request时，可以先通过空Ack msg响应Client，当Server准备好后，通过新的CON Msg将resonse发送给Client 非可靠传输Request和Response,pi
19、ggybacked response,Request和Response通过Token配对,异步可靠响应模式,跨多对Msg的Request和Response通过Token配对,非可靠响应模式,Request和Response通过Token配对 对于通过NON承载的Request，Server可以选择通过CON返回Response,Payloads and Representations,Request和Response中的Payload通常是是resource Representations或者是request action的结果，格式由”Content-Format”确定 对于client或者
20、server error的response，如果包含”Content-Format“，则Payload是request action结果的Representation，否则是一个诊断Diagnostic Payload，诊断payload通常是一个描述错误信息的字符串 Selected Representation：如果相应的请求使用方法GET并且排除了任何条件请求选项，我们使用术语“选择的表示”来引用对这些请求的成功响应中选择的目标资源的当前表示：client通过多次GET方法获取了resource的Representation，并且回复Request的每个response指定了ETag，则
21、client可以携带多个ETag的request，Server选择一个ETag返回2.03 valid response，这个就是Selected Representation,Request的Method,rfc7252 CoAP定义的方法 GET POST PUT DELETE 对于不能识别的Method，需要返回一个4.05（method Not Allowed）的Piggybacked response,GET,Get方法用于Client向Server端检索URI指定的resource的Representation 如果Request包含Accept Option，表示Client期望
22、的Response的Content-Format 如果Request包含ETag，如果Etag关联的Response validate成功则返回2.03 Valid，否则返回2.05 Content（包含resource的Representation）Get方法是安全并且正交的,POST,POST方法用于Client 请求Server处理 Request中的Representation，如何处理依赖于origin server和target resource，通常会导致创建一个新的resource或者更新target resource 如果resource被创建，response返回2.01
23、created，需要携带resource的uri信息(一个或多个Location-Path和Location-Query Option) 如果request处理成功，且未创建新的Resource，返回2.04 Changed 如果request处理成功，且导致resource别删除，返回2.02 DeletedPOST方法既不安全也不正交,PUT,Put方法用于Client 请求Server使用Request中的Representation更新或者创建URI指定的资源。Representation的格式由Request中的Content-Format确定(如果存在该Option) 如果Serv
24、er存在URI指定的resource，更新成功，返回2.04 Changed 如果resource不存在，并且Server成功创建，返回2.01 Created 如果resource无法更新也无法创建，返回相应的error response 对Put方法结果的进一步限制，可以通过If-Match和If-Not-Match施加Put方法不安全但是是正交的,DELETE,Put方法用于Client 请求Server删除URI指定的resource 如果删除成功或者resource根本不存在，返回2.02 DeletedDelete方法不安全但是是正交的,Response Code-2.xx suc
25、cess,This class of Response Code indicates that the clients request was successfully received, understood, and accepted 2.01 Created：response to POST and PUT，response中可能包含一个操作结果的Representation；not cacheable 2.02 Deleted：response to POST and DELETE, not cacheable 2.03 Valid：用于指示Request中ETag指定的Respons
26、e是有效的，Response必须包含ETag，不能包含payload 2.04 Changed：response to POST和PUT，not cacheable 2.05 Content：response to GET, response中包含target resource的Representation，is cacheable,Response Code-4.xx Client Error,此类Code用于表示可能的客户端错误，可以应用于所有method的response，并应该包含一个Diagnostic payload；此类Code的Response是cacheable的 4.00
27、Bad Request 4.13 Request Entity Too Large 4.01 Unauthorized 4.15 Unsupported Content-Format 4.02 Bad Option 4.03 Forbidden 4.04 Not Found 4.05 Method Not Allowed 4.06 Not Acceptable 4.12 Precondition Failed,Response Code-5.xx Server Error,此类Code用于表示可能的Server端错误，可以应用于所有method的response，并应该包含一个Diagnost
28、ic payload；此类Code的Response是cacheable的 5.00 Bad Internal Server Error 5.01 Not Implement 5.02 Bad Gateway 5.03 Service Unavailable 5.04 Gateway Timeout 5.05 Proxying Not Supported,目录,概述 Message Model Request/Response Model Options CoAP组播 CoAP代理 Securing CoAP,Option分类,协议定义了Option，Option的属性有如下几类： Criti
29、cal Option：接收方必须能够理解的Option，否则消息无法正常处理 Elective Option：接收方不识别该Option时，可以忽略，不影响消息的正常处理 注意：Option本身和字面意义一样，是否出现在Message中是可选的； Unsafe Option：Proxy不识别不能转发其所在Message的Option，并不是每个Critical Option都是Unsafe Option Safe-to-Forward Option：Proxy不识别仍可转发其所在Message的Option,Critical vs Elective Option,根据Endpoint对于不能识
30、别的Option如何处理分类，规则： 对于不能识别的Elective Option，无声的忽略该Option 在Confirmable Request中的不能识别的Critical Option，需要返回4.02(Bad Option) reponse，且携带该Option用于诊断 在Confirmable response中或者piggybacked Response中的不能识别的Critical Option，必须reject这个Response 在non-confirmable msg中不能识别的Option，必须reject这个消息（返回reset并忽略该non-Confirmable
31、 msg） Rejecting a Confirmable message is effected by sending a matching Reset message and otherwise ignoring it.Critical 和 Elective 规则应用于non-proxying的Endpoint,Proxy Unsafe-to-Forward vs Safe-to-Forward,根据Proxy如何处理Option分类 Proxy如何处理这两种Option的规则在Proxy中进一步描述 对于标记为Safe-to-Forward的option，可以通过NoCacheKey b
32、its来标识其是否愿意成为一个Cache-Key：如果some of NoCacheKey bits为0，表示愿意；如果NoCacheKey bits都是1，表示不愿意 Cache-Key用于Proxy对于Request中未实现的Option，作为替换采用Unsafe/Safe-to-Forward标识决定是否cache,Option Format,Option Delta：Option在message中的实例必须按照编号大小顺序存放，option的实际编号由本Option中的Delta值+上一个Option的值确定；对于Message中的第一个Option实例，假定上一个Option的编号为
33、0；同一个编号的多个Option的实例，其Delta值为0,Option Format,Option Delta：取值0-12表示Option delta，取值为13时，需要占用Option delta extension中一个byte，存放实际option delta减13的取值；取值为14时，需要占用extension中两个字节，存放实际Option delta减去269的部分；取值为15时，为payload marker保留。 Option length：取值0-12表示option占用的字节数；取值13时表示需要占用扩展中的一个字节，且表示option length减13的部分；取值1
34、4时，表示需要占用扩展中的两个字节，且表示option length减去269的部分；取值15时，保留； Option value format： 0长度的字符序列 不透明的字节序列 无符号整数 UTF-8编码的Unicode字符串,Option number,一个Option 编号的最低字节，有如下mask组成： C: 1表示是Critical Option,0表示是Elective Option，即奇数编号是Critical，偶数编号是Elective Option U：Unsafe，1表示是一个Unsafe Option，否则是一个Safe-to-Forward Option NoCac
35、heKey: 三个bit全为1时，表示是一个NoCacheKey，其他情况表示是一个Cache-Key,Option项,CoAP定义了如下可以应用于Request和Response中的Option： Content-Format ETag Location-Path Location-Query Max-Age Proxy-Uri Proxy-scheme Uri-Host Uri-Path Uri-Port Uri-Query,Accept If-Match If-No-Match Size1,Option项定义,NoCacheKey指示对于Safe-to-Forward选项才有意义,Uri
36、-Host/Uri-Port/Uri-Path/Uri-Query,Uri-Host/Uri-Port/Uri-Path/Uri-Query用于指定发往Server的Request中的目标resource，用于组合出目标resource的URI Uri-Host：指定目标资源所在的主机 Uri-Port：指定目标资源所在的端口 Uri-Path：指定目标资源绝对路径的一部分 Uri-Query：指定URI的参数的一部分 Request可以包含多个上述Option,Proxy-Uri/Proxy-Scheme,Proxy-Uri用于发往Forward-Proxy的Request中，表示一个绝对U
37、RI Proxy-Scheme表示代理scheme，比如coap,coaps,http,https,CoAP URI,CoAP协议使用和http协议对称的”coap“和”coaps” URI标识，定位一个coap resource 语法符合Augmented Backus-Naur Form (ABNF)(RFC5234)，关于“host”，“port”，“path-abempty”，“query”，“segment”，“IP-literal”，“IPV4address”，“reg-name”定义源自RFC3986 URI Generic Sytax,host：资源所在主机，可以是ip地址或者
38、域名，不能为空 port：coap服务监听端口，coap默认为5683，coaps默认为5684 path：指定resource在host内的路径，由”/”分隔 query：用于进一步参数化资源，由一系列的“&”分隔的参数组成，通常以“key=value”的形式出现,CoAP URI规范化和比较,“coap”和“coaps” URI编码方案遵循RFC3986 如果端口和默认值相同，可以不列出 空的path组件等效于根目录”/”,应该直接列出“/” host:port组件是大小写不敏感的，通常用小写呈现 非host外的其他组件内容是大小写敏感的 除”reserved“集合中的字符外，其和其百分号
39、编码含义等价：通常不需要采用百分号编码形式 如下形式的三个URI是等价的：,URI分解,分解一个绝对路径的url到CoAP Request的URI-*的步骤： 如果url不是绝对URI，分解失败 参照RFC3986解析url字符串，此刻URL是ASCII编码，经过步骤5,8,9，将被翻译为UTF-8编码 如果url不存在scheme，并且存在scheme，不是”coap”和”coaps“，分解失败 如果url包括”fragment“组件，分解失败 将url的host的取值转换为URI-Host，如果不是ip地址的形式，转换ASCII编码为UTF-8编码，并转换掉百分号编码的形式 如果url的p
40、ort不为空，翻译成10进制整数，否则使用默认port 如果url的port部分不等于request的目的port，将port转化为URI-Port 如果url的path组件为空或者只有一个”/”，转下一步；否则，每个path部分分解为URI-Path 如果url包含query组件，将query中的每个参数转化为URI-Query,组装URI,从CoAP Request的URI-* option中组装URI的步骤： 如果request由DTLS加密，则url由“coaps:/”打头，否则为“coap:/” 如果request包含URI-Host，转化为url的host组件；如果host不是ip
41、地址或者域名格式，组装失败；如果request不包含URI-Host，则使用该request目的IP地址转化为url的host组件 append host 到url 如果request包含URI-Port组件，url的port从URI-Port的value中获取；否则port从request中的目的port获取 如果port部位默认端口，append port到url 将request中的URI-Path拼装程url的path部分（通过”/”分隔），对于不在”unreserved“集合中、不在”sub-delims“集合中，不是”:”字符，不是”字符，需要转换为百分号编码格式 如果path部分
42、为空，将其指定为”/” 如果存在URI-Query，每个URI-Query通过”?”连接第一个URI-Query，通过“&”连接随后所有的URI-Query，对于不在”unreserved“集合中、不在”sub-delims“集合中，不是”:”字符，不是”字符，需要转换为百分号编码格式 将6-8中生成的path追加在url之后,Content-Format,用于指定payload的格式 Proxy-Scheme表示代理scheme，比如coap,coaps,http,https,Accept,用于指定期望的Payload的格式，即Content-Format If no Accept opti
43、on is given, the client does not express a preference (thus no default value is assumed). The client prefers the representation returned by the server to be in the Content-Format indicated. The server returns the preferred Content-Format if available. If the preferred Content-Format cannot be return
44、ed, then a 4.06 “Not Acceptable“ MUST be sent as a response, unless another error code takes precedence for this response.,Max-Age,指定Response的生存时间，即保持fresh的时间 默认60秒,ETag,实体标签是由Server产生的，用于区分随时间变化的相同资源的表示之间的资源本地标识符。 Response中的ETag 在Response中只能出现一次 If no Location-* options are present, the taggedrepre
45、sentation is the selected representation (Section 5.5.3) of the target resource. If one or more Location-* options are present and thus a location URI is indicated (Section 5.10.7), the tagged representation is the representation that would be retrieved by a GET request to the location URI. Request中
46、的ETag 可以出现0或1或多次 用于revalidate之前cache的Response,Location-Path/Location-Query,Location-Path和Location-Query共同组成一个绝对路径或者一个query string或者两者都有 该组合出现2.01 Created response中表示Resource创建的相对路径 如果Location-Path和Location-Query与现有的cache的response匹配，这些Response需要刷新为un-fresh,Conditional Request Options,作用 用于指示Server当Co
47、nditional Option满足时，才执行Request 条件满足时，则执行，否则返回4.12 Precondition Failed 该Request导致的除2.xx和4.12的其他Response code时，Conditional Option被忽略 If-Match If-Match用于携带ETag value 可以有0个或多个，有一个匹配，则条件满足 用于resource条件更新，比如PUT方法 If-None-Match If-None-Match未携带value 用于以目标资源不存在为条件提出请求。比如PUT方法,Sizel,作用 The Size1 option provi
48、des size information about the resource representation in a request. The option value is an integer number of bytes. Its main use is with block-wise transfers rfc7959 . In the present specification, it is used in 4.13 responses (Section 5.9.2.9) to indicate the maximum size of request entity that th
49、e server is able and willing to handle.,目录,概述 Message Model Request/Response Model Options Response的缓存机制 CoAP组播 CoAP代理 Securing CoAP,Caching,Endpoint可以cache response，也就是对当前的Request，复用之前Request的Response，以缩短响应时间，节约带宽消耗。 Caching机制 Freshness机制 Validation机制 使用Cache Response的条件 Request和Caching Response的me
50、thod相同 Request中的Option和Caching Response相同（Cache-key） Caching Response是fresh或者是validated的,Freshness model,为了提高效率，cache中的Response如果是Fresh的，可以用来直接满足后续的Requests，而不需要contact origin server 如果判断新鲜度(freshness) Response中的Max-Age用来指示该Response的生存(cache)时间，如果response没有这个Option，默认是60秒，如果Origin server不希望这个response被cache，显示携带Max-Age的值为0,
