《CoAP协议详解》PPT课件.ppt

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简化实现降低复杂度（代码更小，封包更小） 应用于资源受限的环境（内存，存储，无良好的随机源），比如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 Endpoint Recipient：Message的目的Endpoint，等于destination Endpoint Client：发出Request的Endpoint，Response的destination Endpoint Server：Request的destination 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：被Client用于代表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代理 Securing 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(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,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 message 2: succsee 4: client error 5: server error Message ID：用于message的重复性检测，以及Confirmable msg，non-Confirmable msg和ACK、reset 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-confirmable 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也不是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 msg Receipt收到一个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次重传都乘以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消息的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 Model Request/Response Model Options CoAP组播 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定义的方法 GET POST PUT DELETE 对于不能识别的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 Deleted POST方法既不安全也不正交,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 Deleted Delete方法不安全但是是正交的,Response Code-2.xx success,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指定的Response是有效的，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 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，并应该包含一个Diagnostic 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的属性有如下几类： Critical 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对于不能识别的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 Option U：Unsafe，1表示是一个Unsafe Option，否则是一个Safe-to-Forward Option NoCacheKey: 三个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-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中，表示一个绝对URI 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地址或者域名，不能为空 port：coap服务监听端口，coap默认为5683，coaps默认为5684 path：指定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-Format If 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-Match If-Match用于携带ETag value 可以有0个或多个，有一个匹配，则条件满足 用于resource条件更新，比如PUT方法 If-None-Match If-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 ) to indicate the maximum size of request entity that the 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的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中的哪一个 其他编号的Response指示没有可以用来重用的Response,目录,概述 Message Model Request/Response Model Options Response的缓存机制 CoAP组播 CoAP代理 Securing CoAP,组播,组播是相对单播CoAP的一系列增强 Message Layer 组播Message必须是non-Confirmable，Server必须能够识别该消息是组播消息；对于收到的组播消息，Server不能回复Reset；Client发出组播消息的Message ID不能和当前Active的单播消息重复 组播不能通过DTLS承载（在RFC7252写作时） Request/Response Layer Server可以不理会组播的Request（取决于应用） Server决定返回组播Message的单播响应时，需要等一个随机时间 Caching Client每次发出一个新的组播请求，可以用repose更新cache的Response 随后针对组播server发出的单播GET请求的URI的主机部分，需要用reponse中的源IP地址替代 到组播地址的GET请求，不能携带Etag Option Proxying,组播地址,发现机制（Discovery）,Service Discovery：发现Server的方式： 通过Server的URI发现Server 通过组播方式(IPv4)发现Server 通过All CoAP Nodes组播地址(IPv6)发现Server Server默认在端口5683或5684提供CoAP服务 Resource Discovery:将受限Web服务器托管的资源，其属性和其他资源关系的发现称为CoRE资源发现。 在M2M应用场景，由于没有人工接口，CoAP Endpoint建议支持RFC6690定义的可发现资源的CoRE Link Format，用于资源发现 CoAP为应用RFC6690定义一个新的Web Linking（RFC5988）ct Attribute用于指示返回的Resource的Content-Format,目录,概述 Message Model Request/Response Model Options Response的缓存机制 CoAP组播 CoAP代理 Securing CoAP,Proxying,Proxy是一种在CoAP Clients驱动下代表它们执行Request的Endpoint Proxy按照功能分类 Forward-proxy：被Client显示指定，并转发Client request到Server或下一个proxy，必要时可以直接从本地cache中查询response直接返回Client Reverse-proxy：代表Server执行Client的Request，Reverse-Proxy背后一般隐藏着多个origin Server，Reverse-Proxy根据request-URI和其配置策略，决定将Request发往哪一个origin Server执行Request，必要时也可以从本地cache中查询response直接返回client Proxy按照协议转换分类 CoAP-to-CoAP proxy cross proxy,Proxy的一般行为,代理通常需要一种方式来基于其从客户端接收到的请求来确定其放置到目的地的请求的潜在请求参数 支持Freshness model和Validation model 缓存Response 对于Request可以识别的Option，知道该option是否应该作为cache-key：比如URI-Path必然是cache-key，而Token不可以作为cache-key 对于Request中不识别的Option，知道根据Option中的Unsafe和NoCacheKey决定是否可以作为cache-key：标识为Safe-to-Forward的Option且NoCacheKey未全置1 Request超时返回5.04（gateway timeout）或者server返回的Response无法处理，返回5.02(Bad gateway)，否则将origin server返回的响应给clinet 如果Reponse从Cache中选择，返回Client中的Max-Age需要减去在cache中的存活时间 处理Request中Option时，对于不能识别的Unsafe Option，返回4.02（bad option），对于Response中不能识别的Unsafe Option，返回5.02（bad gateway），对于不能识别的Safe-to-Forward option，不影响转发,Forward-Proxy,Forward-Proxy需要显示配置给CoAP Clients 发送到代理的Request和直接发往Origin server的Request中的resource URI格式不同：到Proxy的Request中的URI以字符串形式出现在Option Proxy-URI或者通过Proxy-Scheme和Uri-*组合，而到Origin Server的Request的URI分解为Uri-Host，Uri-Port，Uri-Path，Uri-Query中； Endpoint不愿担任proxy时，返回5.05（Proxy not Supported） 除非代理被配置为将代理请求转发到另一代理，否则它必须如下翻译请求：Request中URI定义了输出协议及其细节（例如，CoAP在“coap”方案上通过UDP使用， 对于CoAP到CoAP代理，原始服务器的IP地址和端口由请求URI的确定，并且Proxy-Uri或Proxy-Scheme被解码并分割成Uri-Host ，Uri-Port，Uri-Path和Uri-Query选项。,Reverse-Proxy,Reverse-Proxy不涉及Proxy-Uri和Proxy-scheme，但是需要根据Request的信息和配置信息，决定Request的下一跳；比如，例如，在通过资源发现知道它们的存在之后，反向代理可以提供各种资源，如同它们是它自己的资源一样。 反向代理可以自由地为标识这些资源的URI构建一个命名空间。反向代理还可以构建命名空间