634515047CoAP协议详解图文.ppt

CoAP(The Constrained Application Protocol)协议详解,Jade 2016/12,目录,概述Message ModelRequest/Response ModelOptionsCoAP组播CoAP代理Securing CoAP,CoAP是什么,CoAP是IETF为满足物联网，M2M场景制定的协议，特点如下：类似HTTP，基于REST模型：Servers将Resource通过URI形式呈现，客户端可以通过诸如GET,PUT,POST,DELETE方法访问，但是相对HTTP简化实现降低复杂度（代码更小，封包更小）应用于资源受限的环境（内存，存储，无良好的随机源），比如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两层，Request/Response通过Message承载，从封包上不体现这种层次结构DTLS(Datagram Transport Layer Security)可选由于基于UDP，支持组播,协议参与方,协议定义了如下角色：Endpoint：CoAP协议的参与方Sender：发出Message的Endpoint，等于source EndpointRecipient：Message的目的Endpoint，等于destination EndpointClient：发出Request的Endpoint，Response的destination EndpointServer：Request的destination Endpoint，Response的source EndpointOrigin Server：resource的所在的ServerIntermediary：既作为Server由作为Origin Server的Client的Endpoint。可以理解为是Proxy的统称,协议参与方-续,Proxy：一种Intermediary，完成Request前转，Respone中继，执行缓存，namespace转换，协议转换等功能的Endpoint，基于前转请求架构中的位置，协议定义了forward-proxy和reverse-proxy两种代理Forward-Proxy：被Client用于代表Client执行Request，并完成任何必要的转换。Reverse-Proxy：代表一个或多个其他服务器并代表它们满足请求，执行任何必要的翻译的端点。与转发代理不同，客户端可能不知道它正在与反向代理通信;反向代理接收请求，就像它是目标资源的源服务器一样。CoAP-to-CoAP Proxy：映射CoAP request到CoAP requestCross-Proxy：跨协议代理，比如COAP-to-HTTP和HTTP-to-COAP,目录,概述Message ModelRequest/Response ModelOptionsCoAP组播CoAP代理Securing CoAP,Message模型,CoAP Message用于承载Request/Response模型，有两种模式：Reliability ModeConfirmable Message需要Acknowledgement Message确认Confirmable Message和Acknowledgement Message通过Message ID匹配Non-Reliability ModeNon-Confirmable Message不需要Acknowledgement Message确认,Message Format,Messge组成部分固定4字节的头部变长的Token(0-8byte)0或多个TLV格式的Option可选的PayloadMessage承载信息RequestResponseEmpty 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,Message 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 message2:succsee4:client error5:server errorMessage ID：用于message的重复性检测，以及Confirmable msg，non-Confirmable msg和ACK、reset msg的匹配Token：用于匹配Request和ResponseOption：可以0个或多个，每一个Option之后，可以是一个Option，或者是Payload Maker和Payload或者message结束Payload：如果有payload，必然是payload marker(0 xFF)和直到udp报文结尾的payload。Payload marker和payload必然同时出现,Message分类,协议定义的Message有如下几种Confirmable Message：需要确认的消息，Receipt方必须对消息回复Acknowledgement或者ResetNon-confirmable Message：不需要确认的消息，但是Receipt方可能回复ResetAcknowledgement Message：用于向Sender确认Confirmable Message已收到，可以携带Piggybacked ResponseReset Message：用于回复收到的无法处理的Message(Confirmable和Non-confirmable Message)，也可通过一个Empty的Confirmable Message触发一个Rest，用于Endpoint的保活检测Empty Message：一个code为0.00的既不是request也不是response的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用于配对是一次可靠传输过程，支持重复检测简单的停等基于指数回退的重传机制保证靠性,Message的可靠传输,Message的可靠传输由一个Confirmable msg发起；Confirmable msg总是承载一个Request或Response，除非是一个为了触发Reset msg的empty msgReceipt收到一个Confirmable msg，处理结果是：回复一个Acknowledgement msg（携带匹配的message ID）或者在如下情况下Rejecting一个消息：recipient不能正确处理message；message是一个empty message，message中的code是1,6,7；Message存在格式错误Rejecting一个msg的结果是回复Reset msg或者忽略它,Message的可靠传输相关参数,ACK_TIMEOUT*ACK_RANDOM_FACTOR：初始的ACK保护时间(重传保护时间)，随后的MAX_RETRANSMIT次重传都乘以2NSTART：最大并发的处于活动状态的Message数目DEFAULT_LEISURE:Server休闲时间，用于收到多播Request时，何时返回Response的随机时间的计算（上限）PROBING_RATE：经过重传MAX_RETRASMIT次的Request最终未收到Response后，Requester发送对端的平均速率要小于该值,Message的可靠传输导出参数,MAX_TRANS_SPAN：最大重传时间=ACK_TIMEOUT*(2*MAX_RETRANSMIT)-1)*ACK_RANDOM_FACTOR=2*（16-1）*1.5=45sMAX_TRANSMIT_WAIT：最大等待响应时间=ACK_TIMEOUT*(2*(MAX_RETRANSMIT+1)-1)*ACK_RANDOM_FACTOR=2*（32-1）*1.5=93=45+2*1.5*16=93sMAX_LATENCY：封包从发送到期望完成接收的最大保护时间=100s(协议参考MSL直接随意定义)，即封包在传输链路上的时间PROCESSING_DELAY:接收方从接收到该消息到发出响应的处理时间=ACK_TIMEOUT=2sMAX_RTT:最大往返时间=2*MAX_LATENCY+PROCESSING_DELAY=202sEXCHANGE_LIFETIME=MAX_TRANSMIT_SPAN+(2*MAX_LATENCY)+PROCESSING_DELAY=45+200+2=247sNON_LIFETIME：non消息的Message ID最大安全重用保护时间=MAX_TRANS_SPAN+MAX_LATENCY=145,Message的非可靠传输,Client对于不需要可靠传输的Message通过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不能处理这个NON 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 ModelRequest/Response ModelOptionsCoAP组播CoAP代理Securing 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,piggybacked 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或者server error的response，如果包含”Content-Format“，则Payload是request action结果的Representation，否则是一个诊断Diagnostic Payload，诊断payload通常是一个描述错误信息的字符串Selected Representation：如果相应的请求使用方法GET并且排除了任何条件请求选项，我们使用术语“选择的表示”来引用对这些请求的成功响应中选择的目标资源的当前表示：client通过多次GET方法获取了resource的Representation，并且回复Request的每个response指定了ETag，则client可以携带多个ETag的request，Server选择一个ETag返回2.03 valid response，这个就是Selected Representation,Request的Method,rfc7252 CoAP定义的方法GETPOSTPUTDELETE 对于不能识别的Method，需要返回一个4.05（method Not Allowed）的Piggybacked response,GET,Get方法用于Client向Server端检索URI指定的resource的Representation如果Request包含Accept Option，表示Client期望的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 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)如果Server存在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 success,This class of Response Code indicates that the clients request was successfully received,understood,and accepted2.01 Created：response to POST and PUT，response中可能包含一个操作结果的Representation；not cacheable2.02 Deleted：response to POST and DELETE,not cacheable2.03 Valid：用于指示Request中ETag指定的Response是有效的，Response必须包含ETag，不能包含payload2.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 Bad Request4.13 Request Entity Too Large4.01 Unauthorized 4.15 Unsupported Content-Format4.02 Bad Option4.03 Forbidden4.04 Not Found4.05 Method Not Allowed4.06 Not Acceptable4.12 Precondition Failed,Response Code-5.xx Server Error,此类Code用于表示可能的Server端错误，可以应用于所有method的response，并应该包含一个Diagnostic payload；此类Code的Response是cacheable的5.00 Bad Internal Server Error5.01 Not Implement5.02 Bad Gateway5.03 Service Unavailable5.04 Gateway Timeout5.05 Proxying Not Supported,目录,概述Message ModelRequest/Response ModelOptionsCoAP组播CoAP代理Securing CoAP,Option分类,协议定义了Option，Option的属性有如下几类：Critical Option：接收方必须能够理解的Option，否则消息无法正常处理Elective Option：接收方不识别该Option时，可以忽略，不影响消息的正常处理注意：Option本身和字面意义一样，是否出现在Message中是可选的；Unsafe Option：Proxy不识别不能转发其所在Message的Option，并不是每个Critical Option都是Unsafe OptionSafe-to-Forward Option：Proxy不识别仍可转发其所在Message的Option,Critical vs Elective Option,根据Endpoint对于不能识别的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 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 bits来标识其是否愿意成为一个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的编号为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的部分；取值14时，表示需要占用扩展中的两个字节，且表示option length减去269的部分；取值15时，保留；Option value format：0长度的字符序列不透明的字节序列无符号整数UTF-8编码的Unicode字符串,Option number,一个Option 编号的最低字节，有如下mask组成：C:1表示是Critical Option,0表示是Elective Option，即奇数编号是Critical，偶数编号是Elective OptionU：Unsafe，1表示是一个Unsafe Option，否则是一个Safe-to-Forward OptionNoCacheKey:三个bit全为1时，表示是一个NoCacheKey，其他情况表示是一个Cache-Key,Option项,CoAP定义了如下可以应用于Request和Response中的Option：Content-FormatETagLocation-PathLocation-QueryMax-AgeProxy-UriProxy-schemeUri-HostUri-PathUri-PortUri-Query,AcceptIf-MatchIf-No-MatchSize1,Option项定义,NoCacheKey指示对于Safe-to-Forward选项才有意义,Uri-Host/Uri-Port/Uri-Path/Uri-Query,Uri-Host/Uri-Port/Uri-Path/Uri-Query用于指定发往Server的Request中的目标resource，用于组合出目标resource的URIUri-Host：指定目标资源所在的主机Uri-Port：指定目标资源所在的端口Uri-Path：指定目标资源绝对路径的一部分Uri-Query：指定URI的参数的一部分Request可以包含多个上述Option,Proxy-Uri/Proxy-Scheme,Proxy-Uri用于发往Forward-Proxy的Request中，表示一个绝对URIProxy-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地址或者域名，不能为空port：coap服务监听端口，coap默认为5683，coaps默认为5684path：指定resource在host内的路径，由”/”分隔query：用于进一步参数化资源，由一系列的“&”分隔的参数组成，通常以“key=value”的形式出现,CoAP URI规范化和比较,“coap”和“coaps”URI编码方案遵循RFC3986如果端口和默认值相同，可以不列出空的path组件等效于根目录”/”,应该直接列出“/”host:port组件是大小写不敏感的，通常用小写呈现非host外的其他组件内容是大小写敏感的除”reserved“集合中的字符外，其和其百分号编码含义等价：通常不需要采用百分号编码形式如下形式的三个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的port不为空，翻译成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地址或者域名格式，组装失败；如果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部分为空，将其指定为”/”如果存在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-FormatIf no Accept option 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 returned,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 taggedrepresentation 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中的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当Conditional Option满足时，才执行Request条件满足时，则执行，否则返回4.12 Precondition Failed该Request导致的除2.xx和4.12的其他Response code时，Conditional Option被忽略If-MatchIf-Match用于携带ETag value可以有0个或多个，有一个匹配，则条件满足用于resource条件更新，比如PUT方法If-None-MatchIf-None-Match未携带value用于以目标资源不存在为条件提出请求。比如PUT方法,Sizel,作用The Size1 option provides 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 the server is able and willing to handle.,目录,概述Message ModelRequest/Response ModelOptionsResponse的缓存机制CoAP组播CoAP代理Securing CoAP,Caching,Endpoint可以cache response，也就是对当前的Request，复用之前Request的Response，以缩短响应时间，节约带宽消耗。Caching机制Freshness机制Validation机制使用Cache Response的条件Request和Caching Response的method相同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,Validation model,Endpoint为request保存了多个Response，但是由于not fresh而不能使用，当收到携带ETag的Request时，origin Server可以选择一个保存的response，并且更新其新鲜度。此称为”validating“or”revalidating“保存的Response；过程Endpoint发送携带ETag Option的Request，可以携带多个，每个代表一个保存的Response一个编号为2.03的Response携带ETag指定重用已保存的Reponse中的哪一个其他编号的Respons