CoAP协议详解.ppt

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 用于进一步参数化资源 由一系列的 分隔的参数组成 通常以 key value 的形式出现 CoAPURI规范化和比较 coap 和 coaps URI编码方案遵循RFC3986如果端口和默认值相同 可以不列出空的path组件等效于根目录 应该直接列出 host port组件是大小写不敏感的 通常用小写呈现非host外的其他组件内容是大小写敏感的除 reserved 集合中的字符外 其和其百分号编码含义等价 通常不需要采用百分号编码形式如下形式的三个URI是等价的 URI分解 分解一个绝对路径的url到CoAPRequest的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 从CoAPRequest的URI option中组装URI的步骤 如果request由DTLS加密 则url由 coaps 打头 否则为 coap 如果request包含URI Host 转化为url的host组件 如果host不是ip地址或者域名格式 组装失败 如果request不包含URI Host 则使用该request目的IP地址转化为url的host组件appendhost到url如果request包含URI Port组件 url的port从URI Port的value中获取 否则port从request中的目的port获取如果port部位默认端口 appendport到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 FormatIfnoAcceptoptionisgiven theclientdoesnotexpressapreference thusnodefaultvalueisassumed TheclientpreferstherepresentationreturnedbytheservertobeintheContent Formatindicated TheserverreturnsthepreferredContent Formatifavailable IfthepreferredContent Formatcannotbereturned thena4 06 NotAcceptable MUSTbesentasaresponse unlessanothererrorcodetakesprecedenceforthisresponse Max Age 指定Response的生存时间 即保持fresh的时间默认60秒 ETag 实体标签是由Server产生的 用于区分随时间变化的相同资源的表示之间的资源本地标识符 Response中的ETag在Response中只能出现一次IfnoLocation optionsarepresent thetaggedrepresentationistheselectedrepresentation Section5 5 3 ofthetargetresource IfoneormoreLocation optionsarepresentandthusalocationURIisindicated Section5 10 7 thetaggedrepresentationistherepresentationthatwouldberetrievedbyaGETrequesttothelocationURI Request中的ETag可以出现0或1或多次用于revalidate之前cache的Response Location Path Location Query Location Path和Location Query共同组成一个绝对路径或者一个querystring或者两者都有该组合出现2 01Createdresponse中表示Resource创建的相对路径如果Location Path和Location Query与现有的cache的response匹配 这些Response需要刷新为un fresh ConditionalRequestOptions 作用用于指示Server当ConditionalOption满足时 才执行Request条件满足时 则执行 否则返回4 12PreconditionFailed该Request导致的除2 xx和4 12的其他Responsecode时 ConditionalOption被忽略If MatchIf Match用于携带ETagvalue可以有0个或多个 有一个匹配 则条件满足用于resource条件更新 比如PUT方法If None MatchIf None Match未携带value用于以目标资源不存在为条件提出请求 比如PUT方法 Sizel 作用TheSize1optionprovidessizeinformationabouttheresourcerepresentationinarequest Theoptionvalueisanintegernumberofbytes Itsmainuseiswithblock wisetransfers rfc7959 Inthepresentspecification itisusedin4 13responses Section5 9 2 9 toindicatethemaximumsizeofrequestentitythattheserverisableandwillingtohandle 目录 概述MessageModelRequest ResponseModelOptionsResponse的缓存机制CoAP组播CoAP代理SecuringCoAP Caching Endpoint可以cacheresponse 也就是对当前的Request 复用之前Request的Response 以缩短响应时间 节约带宽消耗 Caching机制Freshness机制Validation机制使用CacheResponse的条件Request和CachingResponse的method相同Request中的Option和CachingResponse相同 Cache key CachingResponse是fresh或者是validated的 Freshnessmodel 为了提高效率 cache中的Response如果是Fresh的 可以用来直接满足后续的Requests 而不需要contactoriginserver如果判断新鲜度 freshness Response中的Max Age用来指示该Response的生存 cache 时间 如果response没有这个Option 默认是60秒 如果Originserver不希望这个response被cache 显示携带Max Age的值为0 Validationmodel Endpoint为request保存了多个Response 但是由于notfresh而不能使用 当收到携带ETag的Request时 originServer可以选择一个保存的response 并且更新其新鲜度 此称为 validating or revalidating 保存的Response 过程Endpoint发送携带ETagOption的Request 可以携带多个 每个代表一个保存的Response一个编号为2 03的Response携带ETag指定重用已保存的Reponse中的哪一个其他编号的Response指示没有可以用来重用的Response 目录 概述MessageModelRequest ResponseModelOptionsResponse的缓存机制CoAP组播CoAP代理SecuringCoAP 组播 组播是相对单播CoAP的一系列增强MessageLayer组播Message必须是non Confirmable Server必须能够识别该消息是组播消息 对于收到的组播消息 Server不能回复Reset Client发出组播消息的MessageID不能和当前Active的单播消息重复组播不能通过DTLS承载 在RFC7252写作时 Request ResponseLayerServer可以不理会组播的Request 取决于应用 Server决定返回组播Message的单播响应时 需要等一个随机时间CachingClient每次发出一个新的组播请求 可以用repose更新cache的Response随后针对组播server发出的单播GET请求的URI的主机部分 需要用reponse中的源IP地址替代到组播地址的GET请求 不能携带EtagOptionProxying 组播地址 发现机制 Discovery ServiceDiscovery 发现Server的方式 通过Server的URI发现Server通过组播方式 IPv4 发现Server通过AllCoAPNodes组播地址 IPv6 发现ServerServer默认在端口5683或5684提供CoAP服务ResourceDiscovery 将受限Web服务器托管的资源 其属性和其他资源关系的发现称为CoRE资源发现 在M2M应用场景 由于没有人工接口 CoAPEndpoint建议支持RFC6690定义的可发现资源的CoRELinkFormat 用于资源发现CoAP为应用RFC6690定义一个新的WebLinking RFC5988 ctAttribute 用于指示返回的Resource的Content Format 目录 概述MessageModelRequest ResponseModelOptionsResponse的缓存机制CoAP组播CoAP代理SecuringCoAP Proxying Proxy是一种在CoAPClients驱动下代表它们执行Request的EndpointProxy按照功能分类Forward proxy 被Client显示指定 并转发Clientrequest到Server或下一个proxy 必要时可以直接从本地cache中查询response直接返回ClientReverse proxy 代表Server执行Client的Request Reverse Proxy背后一般隐藏着多个originServer Reverse Proxy根据request URI和其配置策略 决定将Request发往哪一个originServer执行Request 必要时也可以从本地cache中查询response直接返回clientProxy按照协议转换分类CoAP to CoAPproxycrossproxy Proxy的一般行为 代理通常需要一种方式来基于其从客户端接收到的请求来确定其放置到目的地的请求的潜在请求参数支持Freshnessmodel和Validationmodel缓存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未全置1Request超时返回5 04 gatewaytimeout 或者server返回的Response无法处理 返回5 02 Badgateway 否则将originserver返回的响应给clinet如果Reponse从Cache中选择 返回Client中的Max Age需要减去在cache中的存活时间处理Request中Option时 对于不能识别的UnsafeOption 返回4 02 badoption 对于Response中不能识别的UnsafeOption 返回5 02 badgateway 对于不能识别的Safe to Forwardoption 不影响转发 Forward Proxy Forward Proxy需要显示配置给CoAPClients发送到代理的Request和直接发往Originserver的Request中的resourceURI格式不同 到Proxy的Request中的URI以字符串形式出现在OptionProxy URI或者通过Proxy Scheme和Uri 组合 而到OriginServer的Request的URI分解为Uri Host Uri Port Uri Path Uri Query中 Endpoint不愿担任proxy时 返回5 05 ProxynotSupported 除非代理被配置为将代理请求转发到另一代理 否则它必须如下翻译请求 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构建一个命名空间 反向代理还可以构建命名空间 其给予客户端例如通过将主机标识符和端口号嵌入到所提供的资源的URI路径中来更多地控制请求的去向 在处理Response时 反向代理必须小心 来自不同源的ETag选项值不会混合到提供给其所有客户端的一个资源上 如果从Reverse Proxy提供的资源到由其各种OriginServer提供的资源的映射不是唯一的 则Reverse Proxy可能需要生成新的ETag 确保该选项的语义被适当地保留 Cross ProxybetweenCoAPandHTTP 按代理方向分类COAP HTTPProxyingCoAPClient通过该代理访问HTTPServer上resource的资源 Client通过发送携带Proxy URI或者Proxy Scheme指定到http或httpsURI的Request发起该访问过程HTTP COAPProxyingHTTPClient通过该代理访问CoAPServer上的资源 通过在HTTPRequest的request line中指定URI格式为coap或者coaps发起该访问过程CoAP的Request Response模型和HTTP映射 CoAP底层的messagemodel不影响代理本身的功能 Reverse Proxy对于Client来说 和originServer是一样的 协议认为不需特别描述 但是从被代理的Server看 Reverse Proxy会导致proxy更广泛的适用性 需要专门的协议定义 CoAP HTTPProxy COAP HTTPProxyCoAPClient发送携带Proxy URI或者Proxy Scheme的Request请求到ProxyProxy对HTTPresource执行Request中method指定的操作 并返回响应协议定义了Proxy对CoAPrequest应该返回的Response 至于代理如何实现以满足这个要求属于实现细节 协议未具体定义如果Proxy不愿服务一个携带指定URI的Request 返回client一个5 05ProxyingNotSupported如果Proxy将Request转发到originhttpserver 超时未得到响应 Proxy应该给client返回5 04GatewayTimeout 或者得到了originserver的响应 但是无法解析 给client返回一个5 02BadGateway响应 CoAP HTTPPro