【8A文】CoAP协议详解

CoAP(TheConstrainedApplicationProtocol)协议详解Jade2016/12目录概述MessageModelRequest/ResponseModelOptionsCoAP组播CoAP代理SecuringCoAPCoAP是什么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，等于sourceEndpointRecipient：Message的目的Endpoint，等于destinationEndpointClient：发出Request的Endpoint，Response的destinationEndpointServer：Request的destinationEndpoint，Response的sourceEndpointOriginServer：resource的所在的ServerIntermediary：既作为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到CoAPrequestCross-Proxy：跨协议代理，比如COAP-to-HTTP和HTTP-to-COAP目录概述MessageModelRequest/ResponseModelOptionsCoAP组播CoAP代理SecuringCoAPMessage模型CoAPMessage用于承载Request/Response模型，有两种模式：ReliabilityModeConfirmableMessage需要AcknowledgementMessage确认ConfirmableMessage和AcknowledgementMessage通过MessageID匹配Non-ReliabilityModeNon-ConfirmableMessage不需要AcknowledgementMessage确认MessageFormatMessge组成部分固定4字节的头部变长的Token(0-8byte)0或多个TLV格式的Option可选的PayloadMessage承载信息RequestResponseEmptyMessage（只有messageheader，且code为0.00）MessageHeaderVer：2bitversion，当前版本为01，版本号非1的消息直接丢弃T:Messagetype:Confirmable(0),Non-confirmable(1),Acknowledgement(2),Reset(3)TKL：Tokenlength，当前有效取值0-8，其他认为是MessageformaterrorMessageFormat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表示emptymessage2:succsee4:clienterror5:servererrorMessageID：用于message的重复性检测，以及Confirmablemsg，non-Confirmablemsg和ACK、resetmsg的匹配Token：用于匹配Request和ResponseOption：可以0个或多个，每一个Option之后，可以是一个Option，或者是PayloadMaker和Payload或者message结束Payload：如果有payload，必然是payloadmarker(0xFF)和直到udp报文结尾的payload。Payloadmarker和payload必然同时出现Message分类协议定义的Message有如下几种ConfirmableMessage：需要确认的消息，Receipt方必须对消息回复Acknowledgement或者ResetNon-confirmableMessage：不需要确认的消息，但是Receipt方可能回复ResetAcknowledgementMessage：用于向Sender确认ConfirmableMessage已收到，可以携带PiggybackedResponseResetMessage：用于回复收到的无法处理的Message(Confirmable和Non-confirmableMessage)，也可通过一个Empty的ConfirmableMessage触发一个Rest，用于Endpoint的保活检测EmptyMessage：一个code为0.00的既不是request也不是response的Message。EmptyMessage并不是协议定义和上述Messge并列的type，它只是一种特殊含义的MessageMessage和Response映射关系*：表示此种情况只是为了让接收方发出ResetmsgMessage的可靠传输Client构造ConMsg发送到Server，未收到ACK或Reset时，支持基于指数回退的重发Server如果可以处理该Message，返回ACK，否则返回ResetEndpoint匹配CON和ACK/ResetMessage中携带MessageID用于配对是一次可靠传输过程，支持重复检测简单的停等基于指数回退的重传机制保证靠性Message的可靠传输Message的可靠传输由一个Confirmablemsg发起；Confirmablemsg总是承载一个Request或Response，除非是一个为了触发Resetmsg的emptymsgReceipt收到一个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次重传都乘以2NSTART：最大并发的处于活动状态的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=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直接随意定义)，即封包在传输链路上的时间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消息的MessageID最大安全重用保护时间=MAX_TRANS_SPAN+MAX_LATENCY=145Message的非可靠传输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代理SecuringCoAPRequest/Response模型CoAPRequest和Response的语法通过Message承载可靠传输的Request