CoAP协议详解

CoAP(TheConstrainedApplicationProtocol)协议详解,Jade2016/12,目录,概述MessageModelRequest/ResponseModelOptionsCoAP组播CoAP代理SecuringCoAP,CoAP是什么,CoAP是IETF为满足物联网，M2M场景制定的协议，特点如下：类似HTTP，基于REST模型：Servers将Resource通过URI形式呈现，客户端可以通过诸如GET,PUT,POST,DELETE方法访问，但是相对HTTP简化实现降低复杂度（代码更小，封包更小）应用于资源受限的环境（内存，存储，无良好的随机源），比如CPU为8-bit的单片机，内存32Kb，FLASH256Kb针对业务性能要求不高的应用：低速率(10sofkbit/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(DatagramTransportLayerSecurity)可选由于基于UDP，支持组播,协议参与方,协议定义了如下角色：Endpoint：CoAP协议的参与方Sender：发出Message的Endpoint，等于sourceEndpointRecipient：Message的目的Endpoint，等于destinationEndpointClient：发出Request的Endpoint，Response的destinationEndpointServer：Request的destinationEndpoint，Response的sourceEndpointOriginServer：resource的所在的ServerIntermediary：既作为Server由作为OriginServer的Client的Endpoint。可以理解为是Proxy的统称,协议参与方-续,Proxy：一种Intermediary，完成Request前转，Respone中继，执行缓存，namespace转换，协议转换等功能的Endpoint，基于前转请求架构中的位置，协议定义了forward-proxy和reverse-proxy两种代理Forward-Proxy：被Client用于代表Client执行Request，并完成任何必要的转换。Reverse-Proxy：代表一个或多个其他服务器并代表它们满足请求，执行任何必要的翻译的端点。与转发代理不同，客户端可能不知道它正在与反向代理通信;反向代理接收请求，就像它是目标资源的源服务器一样。CoAP-to-CoAPProxy：映射CoAPrequest到CoAPrequestCross-Proxy：跨协议代理，比如COAP-to-HTTP和HTTP-to-COAP,目录,概述MessageModelRequest/ResponseModelOptionsCoAP组播CoAP代理SecuringCoAP,Message模型,CoAPMessage用于承载Request/Response模型，有两种模式：ReliabilityModeConfirmableMessage需要AcknowledgementMessage确认ConfirmableMessage和AcknowledgementMessage通过MessageID匹配Non-ReliabilityModeNon-ConfirmableMessage不需要AcknowledgementMessage确认,MessageFormat,Messge组成部分固定4字节的头部变长的Token(0-8byte)0或多个TLV格式的Option可选的PayloadMessage承载信息RequestResponseEmptyMessage（只有messageheader，且code为0.00）,MessageHeader,Ver：2bitversion，当前版本为01，版本号非1的消息直接丢弃T:Messagetype:Confirmable(0),Non-confirmable(1),Acknowledgement(2),Reset(3)TKL：Tokenlength，当前有效取值0-8，其他认为是Messageformaterror,MessageFormat,Code:Code：8bit无符号数，格式:c(3bitclasstype).dd(5bitdetailcode)Class分类：0：表示message为request，dd表示具体的method：0.01表示GET，0.02表示POST,0.03表示PUT，0.04表示DELETE，特例，0.00表示emptymessage2:succsee4:clienterror5:servererrorMessageID：用于message的重复性检测，以及Confirmablemsg，non-Confirmablemsg和ACK、resetmsg的匹配Token：用于匹配Request和ResponseOption：可以0个或多个，每一个Option之后，可以是一个Option，或者是PayloadMaker和Payload或者message结束Payload：如果有payload，必然是payloadmarker(0 xFF)和直到udp报文结尾的payload。Payloadmarker和payload必然同时出现,Message分类,协议定义的Message有如下几种ConfirmableMessage：需要确认的消息，Receipt方必须对消息回复Acknowledgement或者ResetNon-confirmableMessage：不需要确认的消息，但是Receipt方可能回复ResetAcknowledgementMessage：用于向Sender确认ConfirmableMessage已收到，可以携带PiggybackedResponseResetMessage：用于回复收到的无法处理的Message(Confirmable和Non-confirmableMessage)，也可通过一个Empty的ConfirmableMessage触发一个Rest，用于Endpoint的保活检测EmptyMessage：一个code为0.00的既不是request也不是response的Message。EmptyMessage并不是协议定义和上述Messge并列的type，它只是一种特殊含义的Message,Message和Response映射关系,*：表示此种情况只是为了让接收方发出Resetmsg,Message的可靠传输,Client构造ConMsg发送到Server，未收到ACK或Reset时，支持基于指数回退的重发Server如果可以处理该Message，返回ACK，否则返回Reset,Endpoint匹配CON和ACK/ResetMessage中携带MessageID用于配对是一次可靠传输过程，支持重复检测简单的停等基于指数回退的重传机制保证靠性,Message的可靠传输,Message的可靠传输由一个Confirmablemsg发起；Confirmablemsg总是承载一个Request或Response，除非是一个为了触发Resetmsg的emptymsgReceipt收到一个Confirmablemsg，处理结果是：回复一个Acknowledgementmsg（携带匹配的messageID）或者在如下情况下Rejecting一个消息：recipient不能正确处理message；message是一个emptymessage，message中的code是1,6,7；Message存在格式错误Rejecting一个msg的结果是回复Resetmsg或者忽略它,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消息的MessageID最大安全重用保护时间=MAX_TRANS_SPAN+MAX_LATENCY=145,Message的非可靠传输,Client对于不需要可靠传输的Message通过Non-ConfirmableMsg传递虽然不需要ACK确认NONMsg，Server仍然可能会返回Reset给Client(比如Server不能处理这个NONmsg),NONmsg中仍然携带MessageID用于重复检测,Message的非可靠传输,Message的非可靠传输由一个NONmsg发起NONmsg总是承载一个Request或者Response，但是不能是一个Emptymsg不能用Acknowledgementmsg回复NONmsg虽然不需要ACK确认NONMsg，Server仍然可能会返回Reset给Client(比如Server不能处理这个NONmsg)Receipt收到一个NONmsg，在如下情况下Rejecting一个消息：recipient不能正确处理message；message是一个emptymessage，message中的code是1,6,7；Message存在格式错误Rejecting一个msg的结果是回复Resetmsg或者忽略它由于Sender不能确认Receipt是否收到NONmsg，所以可以重传多次，Receipt通过MsgID检测是否是重复消息,目录,概述MessageModelRequest/ResponseModelOptionsCoAP组播CoAP代理SecuringCoAP,Request/Response模型,CoAPRequest和Response的语法通过Message承载可靠传输的Request的Response方式(PiggybackedResponse)：同步可靠响应模式(piggybackedresponse)：通过Conmsg的Ack携带Response异步可靠响应模式(SeparateResponse)：当server不能立即响应Request时，可以先通过空Ackmsg响应Client，当Server准备好后，通过新的CONMsg将resonse发送给Client非可靠传输Request和Response,piggybackedresponse,Request和Response通过Token配对,异步可靠响应模式,跨多对Msg的Request和Response通过Token配对,非可靠响应模式,Request和Response通过Token配对对于通过NON承载的Request，Server可以选择通过CON返回Response,PayloadsandRepresentations,Request和Response中的Payload通常是是resourceRepresentations或者是requestaction的结果，格式由”Content-Format”确定对于client或者servererror的response，如果包含”Content-Format“，则Payload是requestaction结果的Representation，否则是一个诊断DiagnosticPayload，诊断payload通常是一个描述错误信息的字符串SelectedRepresentation：如果相应的请求使用方法GET并且排除了任何条件请求选项，我们使用术语“选择的表示”来引用对这些请求的成功响应中选择的目标资源的当前表示：client通过多次GET方法获取了resource的Representation，并且回复Request的每个response指定了ETag，则client可以携带多个ETag的request，Server选择一个ETag返回2.03validresponse，这个就是SelectedRepresentation,Request的Method,rfc7252CoAP定义的方法GETPOSTPUTDELETE对于不能识别的Method，需要返回一个4.05（methodNotAllowed）的Piggybackedresponse,GET,Get方法用于Client向Server端检索URI指定的resource的Representation如果Request包含AcceptOption，表示Client期望的Response的Content-Format如果Request包含ETag，如果Etag关联的Responsevalidate成功则返回2.03Valid，否则返回2.05Content（包含resource的Representation）Get方法是安全并且正交的,POST,POST方法用于Client请求Server处理Request中的Representation，如何处理依赖于originserver和targetresource，通常会导致创建一个新的resource或者更新targetresource如果resource被创建，response返回2.01created，需要携带resource的uri信息(一个或多个Location-Path和Location-QueryOption)如果request处理成功，且未创建新的Resource，返回2.04Changed如果request处理成功，且导致resource别删除，返回2.02DeletedPOST方法既不安全也不正交,PUT,Put方法用于Client请求Server使用Request中的Representation更新或者创建URI指定的资源。Representation的格式由Request中的Content-Format确定(如果存在该Option)如果Server存在URI指定的resource，更新成功，返回2.04Changed如果resource不存在，并且Server成功创建，返回2.01Created如果resource无法更新也无法创建，返回相应的errorresponse对Put方法结果的进一步限制，可以通过If-Match和If-Not-Match施加Put方法不安全但是是正交的,DELETE,Put方法用于Client请求Server删除URI指定的resource如果删除成功或者resource根本不存在，返回2.02DeletedDelete方法不安全但是是正交的,ResponseCode-2.xxsuccess,ThisclassofResponseCodeindicatesthattheclientsrequestwassuccessfullyreceived,understood,andaccepted2.01Created：responsetoPOSTandPUT，response中可能包含一个操作结果的Representation；notcacheable2.02Deleted：responsetoPOSTandDELETE,notcacheable2.03Valid：用于指示Request中ETag指定的Response是有效的，Response必须包含ETag，不能包含payload2.04Changed：responsetoPOST和PUT，notcacheable2.05Content：responsetoGET,response中包含targetresource的Representation，iscacheable,ResponseCode-4.xxClientError,此类Code用于表示可能的客户端错误，可以应用于所有method的response，并应该包含一个Diagnosticpayload；此类Code的Response是cacheable的4.00BadRequest4.13RequestEntityTooLarge4.01Unauthorized4.15UnsupportedContent-Format4.02BadOption4.03Forbidden4.04NotFound4.05MethodNotAllowed4.06NotAcceptable4.12PreconditionFailed,ResponseCode-5.xxServerError,此类Code用于表示可能的Server端错误，可以应用于所有method的response，并应该包含一个Diagnosticpayload；此类Code的Response是cacheable的5.00BadInternalServerError5.01NotImplement5.02BadGateway5.03ServiceUnavailable5.04GatewayTimeout5.05ProxyingNotSupported,目录,概述MessageModelRequest/ResponseModelOptionsCoAP组播CoAP代理SecuringCoAP,Option分类,协议定义了Option，Option的属性有如下几类：CriticalOption：接收方必须能够理解的Option，否则消息无法正常处理ElectiveOption：接收方不识别该Option时，可以忽略，不影响消息的正常处理注意：Option本身和字面意义一样，是否出现在Message中是可选的；UnsafeOption：Proxy不识别不能转发其所在Message的Option，并不是每个CriticalOption都是UnsafeOptionSafe-to-ForwardOption：Proxy不识别仍可转发其所在Message的Option,CriticalvsElectiveOption,根据Endpoint对于不能识别的Option如何处理分类，规则：对于不能识别的ElectiveOption，无声的忽略该Option在ConfirmableRequest中的不能识别的CriticalOption，需要返回4.02(BadOption)reponse，且携带该Option用于诊断在Confirmableresponse中或者piggybackedResponse中的不能识别的CriticalOption，必须reject这个Response在non-confirmablemsg中不能识别的Option，必须reject这个消息（返回reset并忽略该non-Confirmablemsg）RejectingaConfirmablemessageiseffectedbysendingamatchingResetmessageandotherwiseignoringit.Critical和Elective规则应用于non-proxying的Endpoint,ProxyUnsafe-to-ForwardvsSafe-to-Forward,根据Proxy如何处理Option分类Proxy如何处理这两种Option的规则在Proxy中进一步描述对于标记为Safe-to-Forward的option，可以通过NoCacheKeybits来标识其是否愿意成为一个Cache-Key：如果someofNoCacheKeybits为0，表示愿意；如果NoCacheKeybits都是1，表示不愿意Cache-Key用于Proxy对于Request中未实现的Option，作为替换采用Unsafe/Safe-to-Forward标识决定是否cache,OptionFormat,OptionDelta：Option在message中的实例必须按照编号大小顺序存放，option的实际编号由本Option中的Delta值+上一个Option的值确定；对于Message中的第一个Option实例，假定上一个Option的编号为0；同一个编号的多个Option的实例，其Delta值为0,OptionFormat,OptionDelta：取值0-12表示Optiondelta，取值为13时，需要占用Optiondeltaextension中一个byte，存放实际optiondelta减13的取值；取值为14时，需要占用extension中两个字节，存放实际Optiondelta减去269的部分；取值为15时，为payloadmarker保留。Optionlength：取值0-12表示option占用的字节数；取值13时表示需要占用扩展中的一个字节，且表示optionlength减13的部分；取值14时，表示需要占用扩展中的两个字节，且表示optionlength减去269的部分；取值15时，保留；Optionvalueformat：0长度的字符序列不透明的字节序列无符号整数UTF-8编码的Unicode字符串,Optionnumber,一个Option编号的最低字节，有如下mask组成：C:1表示是CriticalOption,0表示是ElectiveOption，即奇数编号是Critical，偶数编号是ElectiveOptionU：Unsafe，1表示是一个UnsafeOption，否则是一个Safe-to-ForwardOptionNoCacheKey:三个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,CoAPURI,CoAP协议使用和http协议对称的”coap“和”coaps”URI标识，定位一个coapresource语法符合AugmentedBackus-NaurForm(ABNF)(RFC5234)，关于“host”，“port”，“path-abempty”，“query”，“segment”，“IP-literal”，“IPV4address”，“reg-name”定义源自RFC3986URIGenericSytax,host：资源所在主机，可以是ip地址或者域名，不能为空port：coap服务监听端口，coap默认为5683，coaps默认为5684path：指定resource在host内的路径，由”/”分隔query：用于进一步参数化资源，由一系列的“协议要求必须要携带Max-AgeOption协议要求如果HTTP实体包含一个entity-tag，响应中需要包含EtagOptionClient可以通过如下处理影响Proxy返回的Response在发往Proxy的request中增加Accept指定优先考虑的content-format在发往Proxy的Request中增加一个或多个ETag，当有一个ETag和Proxy缓存的Response匹配时，使得Proxy返回2.03Valid，否则Proxy返回2.05Content,CoAP-HTTPProxyPUTmethod,PUT方法请求代理更新或者创建requestURI标识的HTTPresource的enclosedRepresentation如果newResource创建成功，返回2.01Created的response如果已有的Resource更新成功，返回2.04Changed的response,CoAP-HTTPProxyDELETEmethod,DELETE方法请求代理删除requestURI标识的HTTPresource如果Resource删除成功，返回2.02Deleted的response如果Resource不存在，返回2.02Deleted的response,CoAP-HTTPProxyPOSTmethod,POST方法请求代理让HTTPoriginserver处理requestURI标识的HTTPresource的Representation，如何处理由HTTPserver根据requestURI确定如果执行结果不会导致一个可以用URI标识的Resource，返回2.04Changed的response如果在originServer创建了Resource，返回2.01Created的response,HTTP-CoAPProxy,HTTP-CoAPProxyHTTPClient发送携带URI为“coap”、“coaps”的Request请求到ProxyProxy对CoAPresource执行Request中method指定的操作，并返回响应给Client协议定义了Proxy对HTTPrequest应该返回的Response，至于代理如何实现以满足这个要求属于实现细节，协议未具体定义如果Proxy不愿或不能服务一个携带指定CoAPURI的Request，返回client一个5.01NotImplemented如果Proxy将Request转发到originhttpserver，超时未得到响应，Proxy应该给client返回5.04GatewayTimeout；或者得到了originserver的响应，但是无法解析，给client返回一个5.02BadGateway响应,HTTP-CoAPProxyOPTIONSandTRACEmethod,HTTP-CoAPProxy不支持OPTIONS和TRACE方法，返回501NotImplemented,HTTP-CoAPProxyHeadmethod,Head方法等价于GET方法，区别是Server返回的Response不能包含message-body尽管CoAP对于HEAD方法没有对应的方法，HTTP-CoAPProxy可以返回对于CoAPresource的响应，并且响应中只有header，没有message-bodyHTTP-CoAP代理可能想尝试使用块方式传输选项BLOCK以最小化实际传输的数据量，但是它需要为源服务器不支持块方式传输的情况做好准备,HTTP-CoAPProxyPOSTmethod,POST方法请求代理让CoAPoriginserver处理requestURI标识的CoAPresource的Representation，如何处理由CoAPserver根据requestURI确定如果执行结果不会导致一个可以用URI标识的Resource，返回200OK或者204NoContent的response如果在originServer创建了Resource，返回201Created的response如果CoAPresponse中包含Location-*Option，返回给HTTPClient的Response中药包含Locationheaer,HTTP-CoAPProxyPUTmethod,PUT方法请求代理更新或者创建requestURI标识的CoAPresource的enclosedRepresentation如果newResource创建成功，返回201Created的response如果已有的Resource更新成功，返回204NoContent或者200OK的response,HTTP-CoAPProxyDELETEmethod,DELETE方法请求代理删除requestURI标识的CoAPresource如果response中包含描述状态的实体，返回200OK的response如果Delete动作已执行但是response中不包含实体，返回2.02Deleted的response,HTTP-CoAPProxyCONNECTmethod,当前不支持该方法，因为TLS到DTLS的隧道目前无标准；收到该HTTP方法的Request，返回501NotImplemented的Response,目录,概述MessageModelRequest/ResponseModelOptionsResponse的缓存机制CoAP组播CoAP代理SecuringCoAP,SecuringCoAP模式,支持加密，需要给Device预置加密相关配置以及访问控制列表CoAP支持通过DTLS加密，定义了如下安全模式NoSec：DisableDTLSPreSharedKey：EnableDTLS，定义一组预共享秘钥，每个秘钥用于的通信节点；极限情况下，该节点和任意通信节点都有一个presharekey，此为1:1模式；相反的话，大于两个用户使用一个presharekey，该key只能用于认证该用户成为改组的成员，而不能用于peer到peer认证必须支持TLS_PSK_WITH_AES_128_CCM_8(RFC6655)RawPublicKey：EnableDTLS，定义一对预共享公钥。设备可以从公钥中导出身份标识，以及可以与之通信的节点列表必须支持TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8Certificate：EnableDTLS，通过X.509数字证书获取公钥协议要求必须支持NoSec和RawPublicKey模式,SecuringCoAP,CoAP支持通过DTLS加密，相对非加密场景的变化CoAPoverUDP和CoAPoverTLS知名端口不同，requestURIsheme不同MessageLayer：CoAP通信前，需要建立TLSsession，Message作为DTLS的payload处理，增加了DTLSheader(13byte)的开销；Message除通过MessageID匹配外，还需要满足在同一个DTLSsession和epoch内；Request/ResponseLayer：Request和Response除通过Token匹配外，还必须满足在同一个DTLSsession和epoch内在RawPublicKey和Certificate安全模式下，DTLSconnection采用相互认证，所以CoAP应该尽量重用该连接，而不是每次Message交互都关闭，重建DTLS连接不支持组播加密(没有组播key)需要支持RFC60