CoAP协议详解_图文.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 发现机制（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定义了输出协议及其细节（例如，