CoAP协议详解#高级教育

《CoAP协议详解#高级教育》由会员分享，可在线阅读，更多相关《CoAP协议详解#高级教育（91页珍藏版）》请在金锄头文库上搜索。

1、CoAP(The Constrained Application Protocol)协议详解协议详解Jade 2016/121高级材料目录概述Message ModelRequest/Response ModelOptionsCoAP组播CoAP代理Securing CoAP2高级材料CoAP是什么CoAP是IETF为满足物联网，M2M场景制定的协议，特点如下：类似HTTP，基于REST模型：Servers将Resource通过URI形式呈现，客户端可以通过诸如GET,PUT,POST,DELETE方法访问，但是相对HTTP简化实现降低复杂度（代码更小，封包更小）应用于资源受限的环境（内存，存

2、储，无良好的随机源），比如CPU为8-bit的单片机，内存32Kb，FLASH 256Kb针对业务性能要求不高的应用：低速率(10s of kbit/s)，低功耗满足CoRE环境的HTTP简化增强版本3高级材料协议模型特征基于UDP的类似HTTP的Client/Server交互模型Client发送Request(携带不同method)请求对资源(通过URI表示)的操作，Server返回Response(携带资源的representation)和状态码在M2M应用场景，Endpoint实际同时是Server和Client 逻辑上分为Message和Request/Response两层，Reque

3、st/Response通过Message承载，从封包上不体现这种层次结构DTLS(Datagram Transport Layer Security)可选由于基于UDP，支持组播4高级材料协议参与方协议定义了如下角色：Endpoint：CoAP协议的参与方Sender：发出Message的Endpoint，等于source EndpointRecipient：Message的目的Endpoint，等于destination EndpointClient：发出Request的Endpoint，Response的destination EndpointServer：Request的destinat

4、ion Endpoint，Response的source EndpointOrigin Server：resource的所在的ServerIntermediary：既作为Server由作为Origin Server的Client的Endpoint。可以理解为是Proxy的统称5高级材料协议参与方-续Proxy：一种Intermediary，完成Request前转，Respone中继，执行缓存，namespace转换，协议转换等功能的Endpoint，基于前转请求架构中的位置，协议定义了forward-proxy和reverse-proxy两种代理Forward-Proxy：被Client用于代

5、表Client执行Request，并完成任何必要的转换。Reverse-Proxy：代表一个或多个其他服务器并代表它们满足请求，执行任何必要的翻译的端点。 与转发代理不同，客户端可能不知道它正在与反向代理通信; 反向代理接收请求，就像它是目标资源的源服务器一样。CoAP-to-CoAP Proxy：映射CoAP request到CoAP requestCross-Proxy：跨协议代理，比如COAP-to-HTTP和HTTP-to-COAP6高级材料目录概述Message ModelRequest/Response ModelOptionsCoAP组播CoAP代理Securing CoAP7高

6、级材料Message模型CoAP Message用于承载Request/Response模型，有两种模式：Reliability ModeConfirmable Message需要Acknowledgement Message确认Confirmable Message和Acknowledgement Message通过Message ID匹配Non-Reliability ModeNon-Confirmable Message不需要Acknowledgement Message确认8高级材料Message FormatMessge组成部分固定4字节的头部变长的Token(0-8byte)0或多

7、个TLV格式的Option可选的PayloadMessage承载信息RequestResponseEmpty Message（只有message header，且code为0.00）9高级材料Message HeaderVer：2bit version，当前版本为01，版本号非1的消息直接丢弃T: Message type:Confirmable(0),Non-confirmable(1),Acknowledgement(2),Reset(3)TKL：Token length，当前有效取值0-8，其他认为是Message format error10高级材料Message FormatCode

8、: 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 message2: succsee4: client error5: server errorMessage ID：用于message的重复性检测，以及Confirmable msg，non-Confirmable msg和ACK、reset msg的匹配Token：用于匹配R

9、equest和ResponseOption：可以0个或多个，每一个Option之后，可以是一个Option，或者是Payload Maker和Payload或者message结束Payload：如果有payload，必然是payload marker(0xFF)和直到udp报文结尾的payload。Payload marker和payload必然同时出现11高级材料Message分类协议定义的Message有如下几种Confirmable Message：需要确认的消息，Receipt方必须对消息回复Acknowledgement或者ResetNon-confirmable Message：不

10、需要确认的消息，但是Receipt方可能回复ResetAcknowledgement Message：用于向Sender确认Confirmable Message已收到，可以携带Piggybacked ResponseReset Message：用于回复收到的无法处理的Message(Confirmable和Non-confirmable Message)，也可通过一个Empty的Confirmable Message触发一个Rest，用于Endpoint的保活检测Empty Message：一个code为0.00的既不是request也不是response的Message。Empty Mes

11、sage并不是协议定义和上述Messge并列的type，它只是一种特殊含义的Message12高级材料Message和Response映射关系*：表示此种情况只是为了让接收方发出Reset msg13高级材料Message的可靠传输Client构造Con Msg发送到Server，未收到ACK或Reset时，支持基于指数回退的重发Server如果可以处理该Message，返回ACK，否则返回ResetEndpoint匹配CON和ACK/Reset Message中携带Message ID用于配对是一次可靠传输过程，支持重复检测简单的停等基于指数回退的重传机制保证靠性14高级材料Message的

12、可靠传输Message的可靠传输由一个Confirmable msg发起；Confirmable msg总是承载一个Request或Response，除非是一个为了触发Reset msg的empty msgReceipt收到一个Confirmable msg，处理结果是：回复一个Acknowledgement msg（携带匹配的message ID）或者在如下情况下Rejecting一个消息：recipient不能正确处理message；message是一个empty message，message中的code是1,6,7；Message存在格式错误Rejecting一个msg的结果是回复Re

13、set msg或者忽略它15高级材料Message的可靠传输相关参数ACK_TIMEOUT*ACK_RANDOM_FACTOR：初始的ACK保护时间(重传保护时间)，随后的MAX_RETRANSMIT次重传都乘以2NSTART：最大并发的处于活动状态的Message数目DEFAULT_LEISURE: Server休闲时间，用于收到多播Request时，何时返回Response的随机时间的计算（上限）PROBING_RATE：经过重传MAX_RETRASMIT次的Request最终未收到Response后，Requester发送对端的平均速率要小于该值16高级材料Message的可靠传输导出参

14、数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_DELA

15、Y:接收方从接收到该消息到发出响应的处理时间=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消息的Message ID最大安全重用保护时间=MAX_TRANS_SPAN+MAX_LATENCY=14517高级材料Message的非可靠传输Client对于不需要可靠传输的Message通过Non-Confirma

16、ble Msg传递虽然不需要ACK确认NON Msg，Server仍然可能会返回Reset给Client(比如Server不能处理这个NON msg)NON msg中仍然携带Message ID用于重复检测18高级材料Message的非可靠传输Message的非可靠传输由一个NON msg发起NON msg总是承载一个Request或者Response，但是不能是一个Empty msg不能用Acknowledgement msg回复NON msg虽然不需要ACK确认NON Msg，Server仍然可能会返回Reset给Client(比如Server不能处理这个NON msg)Receipt收到

17、一个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检测是否是重复消息19高级材料目录概述Message ModelRequest/Response ModelOptionsCoAP组播CoAP代理Securing CoAP20高级材料Request/R

18、esponse模型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和Response21高级材料piggybacked respo

19、nseRequest和Response通过Token配对22高级材料异步可靠响应模式跨多对Msg的Request和Response通过Token配对23高级材料非可靠响应模式Request和Response通过Token配对对于通过NON承载的Request，Server可以选择通过CON返回Response24高级材料Payloads and RepresentationsRequest和Response中的Payload通常是是resource Representations或者是request action的结果，格式由”Content-Format”确定对于client或者server

20、 error的response，如果包含”Content-Format“，则Payload是request action结果的Representation，否则是一个诊断Diagnostic Payload，诊断payload通常是一个描述错误信息的字符串Selected Representation：如果相应的请求使用方法GET并且排除了任何条件请求选项，我们使用术语“选择的表示”来引用对这些请求的成功响应中选择的目标资源的当前表示：client通过多次GET方法获取了resource的Representation，并且回复Request的每个response指定了ETag，则client可

21、以携带多个ETag的request，Server选择一个ETag返回2.03 valid response，这个就是Selected Representation25高级材料Request的Methodrfc7252 CoAP定义的方法GETPOSTPUTDELETE 对于不能识别的Method，需要返回一个4.05（method Not Allowed）的Piggybacked response26高级材料GETGet方法用于Client向Server端检索URI指定的resource的Representation如果Request包含Accept Option，表示Client期望的Res

22、ponse的Content-Format如果Request包含ETag，如果Etag关联的Response validate成功则返回2.03 Valid，否则返回2.05 Content（包含resource的Representation）Get方法是安全并且正交的27高级材料POSTPOST方法用于Client 请求Server处理 Request中的Representation，如何处理依赖于origin server和target resource，通常会导致创建一个新的resource或者更新target resource如果resource被创建，response返回2.01 cr

23、eated，需要携带resource的uri信息(一个或多个Location-Path和Location-Query Option)如果request处理成功，且未创建新的Resource，返回2.04 Changed如果request处理成功，且导致resource别删除，返回2.02 DeletedPOST方法既不安全也不正交28高级材料PUTPut方法用于Client 请求Server使用Request中的Representation更新或者创建URI指定的资源。Representation的格式由Request中的Content-Format确定(如果存在该Option)如果Serve

24、r存在URI指定的resource，更新成功，返回2.04 Changed如果resource不存在，并且Server成功创建，返回2.01 Created如果resource无法更新也无法创建，返回相应的error response对Put方法结果的进一步限制，可以通过If-Match和If-Not-Match施加Put方法不安全但是是正交的29高级材料DELETEPut方法用于Client 请求Server删除URI指定的resource如果删除成功或者resource根本不存在，返回2.02 DeletedDelete方法不安全但是是正交的30高级材料Response Code-2.xx

25、 successThis class of Response Code indicates that the clients request was successfully received, understood, and accepted2.01 Created：response to POST and PUT，response中可能包含一个操作结果的Representation；not cacheable2.02 Deleted：response to POST and DELETE, not cacheable2.03 Valid：用于指示Request中ETag指定的Respons

26、e是有效的，Response必须包含ETag，不能包含payload2.04 Changed：response to POST和PUT，not cacheable 2.05 Content：response to GET, response中包含target resource的Representation，is cacheable31高级材料Response Code-4.xx Client Error此类Code用于表示可能的客户端错误，可以应用于所有method的response，并应该包含一个Diagnostic payload；此类Code的Response是cacheable的4.0

27、0 Bad Request4.13 Request Entity Too Large4.01 Unauthorized 4.15 Unsupported Content-Format4.02 Bad Option4.03 Forbidden4.04 Not Found4.05 Method Not Allowed4.06 Not Acceptable4.12 Precondition Failed 32高级材料Response Code-5.xx Server Error此类Code用于表示可能的Server端错误，可以应用于所有method的response，并应该包含一个Diagnosti

28、c payload；此类Code的Response是cacheable的5.00 Bad Internal Server Error5.01 Not Implement5.02 Bad Gateway5.03 Service Unavailable5.04 Gateway Timeout5.05 Proxying Not Supported33高级材料目录概述Message ModelRequest/Response ModelOptionsCoAP组播CoAP代理Securing CoAP34高级材料Option分类协议定义了Option，Option的属性有如下几类：Critical Op

29、tion：接收方必须能够理解的Option，否则消息无法正常处理Elective Option：接收方不识别该Option时，可以忽略，不影响消息的正常处理注意：Option本身和字面意义一样，是否出现在Message中是可选的；Unsafe Option：Proxy不识别不能转发其所在Message的Option，并不是每个Critical Option都是Unsafe OptionSafe-to-Forward Option：Proxy不识别仍可转发其所在Message的Option35高级材料Critical vs Elective Option根据Endpoint对于不能识别的Opti

30、on如何处理分类，规则：对于不能识别的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）Rejec

31、ting a Confirmable message is effected by sending a matching Reset message and otherwise ignoring it.Critical 和 Elective 规则应用于non-proxying的Endpoint36高级材料Proxy Unsafe-to-Forward vs Safe-to-Forward根据Proxy如何处理Option分类Proxy如何处理这两种Option的规则在Proxy中进一步描述对于标记为Safe-to-Forward的option，可以通过NoCacheKey bits来标识其是否

32、愿意成为一个Cache-Key：如果some of NoCacheKey bits为0，表示愿意；如果NoCacheKey bits都是1，表示不愿意Cache-Key用于Proxy对于Request中未实现的Option，作为替换采用Unsafe/Safe-to-Forward标识决定是否cache37高级材料Option FormatOption Delta：Option在message中的实例必须按照编号大小顺序存放，option的实际编号由本Option中的Delta值+上一个Option的值确定；对于Message中的第一个Option实例，假定上一个Option的编号为0；同一个编

33、号的多个Option的实例，其Delta值为038高级材料Option FormatOption 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时，

34、表示需要占用扩展中的两个字节，且表示option length减去269的部分；取值15时，保留；Option value format：0长度的字符序列不透明的字节序列无符号整数UTF-8编码的Unicode字符串39高级材料Option number一个Option 编号的最低字节，有如下mask组成：C: 1表示是Critical Option,0表示是Elective Option，即奇数编号是Critical，偶数编号是Elective OptionU：Unsafe，1表示是一个Unsafe Option，否则是一个Safe-to-Forward OptionNoCacheKey:

35、三个bit全为1时，表示是一个NoCacheKey，其他情况表示是一个Cache-Key40高级材料Option项CoAP定义了如下可以应用于Request和Response中的Option：Content-FormatETagLocation-PathLocation-QueryMax-AgeProxy-UriProxy-schemeUri-HostUri-PathUri-PortUri-QueryAcceptIf-MatchIf-No-MatchSize141高级材料Option项定义NoCacheKey指示对于Safe-to-Forward选项才有意义42高级材料Uri-Host/Uri

36、-Port/Uri-Path/Uri-QueryUri-Host/Uri-Port/Uri-Path/Uri-Query用于指定发往Server的Request中的目标resource，用于组合出目标resource的URIUri-Host：指定目标资源所在的主机Uri-Port：指定目标资源所在的端口Uri-Path：指定目标资源绝对路径的一部分Uri-Query：指定URI的参数的一部分Request可以包含多个上述Option43高级材料Proxy-Uri/Proxy-SchemeProxy-Uri用于发往Forward-Proxy的Request中，表示一个绝对URIProxy-Sch

37、eme表示代理scheme，比如coap,coaps,http,https44高级材料CoAP URICoAP协议使用和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 Sytaxhost：资源所在主机，可以是ip地址或者域名，不能为空por

38、t：coap服务监听端口，coap默认为5683，coaps默认为5684path：指定resource在host内的路径，由”/”分隔query：用于进一步参数化资源，由一系列的“&”分隔的参数组成，通常以“key=value”的形式出现45高级材料CoAP URI规范化和比较“coap”和“coaps” URI编码方案遵循RFC3986如果端口和默认值相同，可以不列出空的path组件等效于根目录”/”,应该直接列出“/”host:port组件是大小写不敏感的，通常用小写呈现非host外的其他组件内容是大小写敏感的除”reserved“集合中的字符外，其和其百分号编码含义等价：通常不需要采用

39、百分号编码形式如下形式的三个URI是等价的：46高级材料URI分解分解一个绝对路径的url到CoAP Request的URI-*的步骤：1.如果url不是绝对URI，分解失败2.参照RFC3986解析url字符串，此刻URL是ASCII编码，经过步骤5,8,9，将被翻译为UTF-8编码3.如果url不存在scheme，并且存在scheme，不是”coap”和”coaps“，分解失败4.如果url包括”fragment“组件，分解失败5.将url的host的取值转换为URI-Host，如果不是ip地址的形式，转换ASCII编码为UTF-8编码，并转换掉百分号编码的形式6.如果url的port不为

40、空，翻译成10进制整数，否则使用默认port7.如果url的port部分不等于request的目的port，将port转化为URI-Port8.如果url的path组件为空或者只有一个”/”，转下一步；否则，每个path部分分解为URI-Path9.如果url包含query组件，将query中的每个参数转化为URI-Query47高级材料组装URI从CoAP Request的URI-* option中组装URI的步骤：1.如果request由DTLS加密，则url由“coaps:/”打头，否则为“coap:/”2.如果request包含URI-Host，转化为url的host组件；如果host

41、不是ip地址或者域名格式，组装失败；如果request不包含URI-Host，则使用该request目的IP地址转化为url的host组件3.append host 到url4.如果request包含URI-Port组件，url的port从URI-Port的value中获取；否则port从request中的目的port获取5.如果port部位默认端口，append port到url6.将request中的URI-Path拼装程url的path部分（通过”/”分隔），对于不在”unreserved“集合中、不在”sub-delims“集合中，不是”:”字符，不是”字符，需要转换为百分号编码格式7

42、.如果path部分为空，将其指定为”/”8.如果存在URI-Query，每个URI-Query通过”?”连接第一个URI-Query，通过“&”连接随后所有的URI-Query，对于不在”unreserved“集合中、不在”sub-delims“集合中，不是”:”字符，不是”字符，需要转换为百分号编码格式9.将6-8中生成的path追加在url之后48高级材料Content-Format用于指定payload的格式Proxy-Scheme表示代理scheme，比如coap,coaps,http,https49高级材料Accept用于指定期望的Payload的格式，即Content-Format

43、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

44、 cannot be returned, then a 4.06 Not Acceptable MUST be sent as a response, unless another error code takes precedence for this response.50高级材料Max-Age指定Response的生存时间，即保持fresh的时间默认60秒51高级材料ETag实体标签是由Server产生的，用于区分随时间变化的相同资源的表示之间的资源本地标识符。Response中的ETag在Response中只能出现一次If no Location-* options are prese

45、nt, 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 loc

46、ation URI.Request中的ETag可以出现0或1或多次用于revalidate之前cache的Response52高级材料Location-Path/Location-QueryLocation-Path和Location-Query共同组成一个绝对路径或者一个query string或者两者都有该组合出现2.01 Created response中表示Resource创建的相对路径如果Location-Path和Location-Query与现有的cache的response匹配，这些Response需要刷新为un-fresh53高级材料Conditional Request O

47、ptions作用用于指示Server当Conditional Option满足时，才执行Request条件满足时，则执行，否则返回4.12 Precondition Failed该Request导致的除2.xx和4.12的其他Response code时，Conditional Option被忽略If-MatchIf-Match用于携带ETag value可以有0个或多个，有一个匹配，则条件满足用于resource条件更新，比如PUT方法If-None-MatchIf-None-Match未携带value用于以目标资源不存在为条件提出请求。比如PUT方法54高级材料Sizel作用The Siz

48、e1 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 5.9.2.9) to indicate the maximum size of request

49、 entity that the server is able and willing to handle.55高级材料目录概述Message ModelRequest/Response ModelOptionsResponse的缓存机制CoAP组播CoAP代理Securing CoAP56高级材料Caching Endpoint可以cache response，也就是对当前的Request，复用之前Request的Response，以缩短响应时间，节约带宽消耗。Caching机制Freshness机制Validation机制使用Cache Response的条件Request和Caching

50、 Response的method相同Request中的Option和Caching Response相同（Cache-key）Caching Response是fresh或者是validated的57高级材料Freshness model为了提高效率，cache中的Response如果是Fresh的，可以用来直接满足后续的Requests，而不需要contact origin server如果判断新鲜度(freshness)Response中的Max-Age用来指示该Response的生存(cache)时间，如果response没有这个Option，默认是60秒，如果Origin server

51、不希望这个response被cache，显示携带Max-Age的值为058高级材料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指定重用已保存的R

52、eponse中的哪一个其他编号的Response指示没有可以用来重用的Response59高级材料目录概述Message ModelRequest/Response ModelOptionsResponse的缓存机制CoAP组播CoAP代理Securing CoAP60高级材料组播组播是相对单播CoAP的一系列增强Message Layer组播Message必须是non-Confirmable，Server必须能够识别该消息是组播消息；对于收到的组播消息，Server不能回复Reset；Client发出组播消息的Message ID不能和当前Active的单播消息重复组播不能通过DTLS承载（

53、在RFC7252写作时）Request/Response LayerServer可以不理会组播的Request（取决于应用）Server决定返回组播Message的单播响应时，需要等一个随机时间CachingClient每次发出一个新的组播请求，可以用repose更新cache的Response随后针对组播server发出的单播GET请求的URI的主机部分，需要用reponse中的源IP地址替代到组播地址的GET请求，不能携带Etag OptionProxying61高级材料组播地址62高级材料发现机制（Discovery）Service Discovery：发现Server的方式：通过Ser

54、ver的URI发现Server通过组播方式(IPv4)发现Server通过All CoAP Nodes组播地址(IPv6)发现ServerServer默认在端口5683或5684提供CoAP服务Resource Discovery:将受限Web服务器托管的资源，其属性和其他资源关系的发现称为CoRE资源发现。在M2M应用场景，由于没有人工接口，CoAP Endpoint建议支持RFC6690定义的可发现资源的CoRE Link Format，用于资源发现CoAP为应用RFC6690定义一个新的Web Linking（RFC5988）ct Attribute用于指示返回的Resource的Con

55、tent-Format63高级材料目录概述Message ModelRequest/Response ModelOptionsResponse的缓存机制CoAP组播CoAP代理Securing CoAP64高级材料ProxyingProxy是一种在CoAP Clients驱动下代表它们执行Request的Endpoint Proxy按照功能分类Forward-proxy：被Client显示指定，并转发Client request到Server或下一个proxy，必要时可以直接从本地cache中查询response直接返回ClientReverse-proxy：代表Server执行Client的

56、Request，Reverse-Proxy背后一般隐藏着多个origin Server，Reverse-Proxy根据request-URI和其配置策略，决定将Request发往哪一个origin Server执行Request，必要时也可以从本地cache中查询response直接返回clientProxy按照协议转换分类CoAP-to-CoAP proxycross proxy65高级材料Proxy的一般行为 代理通常需要一种方式来基于其从客户端接收到的请求来确定其放置到目的地的请求的潜在请求参数支持Freshness model和Validation model 缓存Response对于

57、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（gateway timeout）或者server返回的Response无法处理，返回5.02(Bad gateway)，否则将origin server返回的响应给clinet如

58、果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，不影响转发66高级材料Forward-ProxyForward-Proxy需要显示配置给CoAP Clients 发送到代理的Request和直接发往Origin server的Request中的resource URI格

59、式不同：到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地址和端口由请求U

60、RI的确定，并且Proxy-Uri或Proxy-Scheme被解码并分割成Uri-Host ，Uri-Port，Uri-Path和Uri-Query选项。67高级材料Reverse-Proxy Reverse-Proxy不涉及Proxy-Uri和Proxy-scheme，但是需要根据Request的信息和配置信息，决定Request的下一跳；比如，例如，在通过资源发现知道它们的存在之后，反向代理可以提供各种资源，如同它们是它自己的资源一样。 反向代理可以自由地为标识这些资源的URI构建一个命名空间。反向代理还可以构建命名空间，其给予客户端例如通过将主机标识符和端口号嵌入到所提供的资源的URI路

61、径中来更多地控制请求的去向。在处理Response时，反向代理必须小心，来自不同源的ETag选项值不会混合到提供给其所有客户端的一个资源上。如果从Reverse-Proxy提供的资源到由其各种Origin Server提供的资源的映射不是唯一的，则Reverse-Proxy可能需要生成新的ETag，确保该选项的语义被适当地保留。68高级材料Cross-Proxy between CoAP and HTTP按代理方向分类COAP-HTTP ProxyingCoAP Client通过该代理访问HTTP Server上resource的资源，Client通过发送携带Proxy-URI或者Proxy-

62、Scheme指定到http或https URI的Request发起该访问过程HTTP-COAP Proxying HTTP Client通过该代理访问CoAP Server上的资源，通过在HTTP Request的request-line中指定URI格式为coap或者coaps发起该访问过程CoAP的Request/Response模型和HTTP映射，CoAP底层的message model不影响代理本身的功能；Reverse-Proxy对于Client来说，和origin Server是一样的，协议认为不需特别描述。但是从被代理的Server看，Reverse-Proxy会导致proxy更广

63、泛的适用性，需要专门的协议定义69高级材料CoAP-HTTP ProxyCOAP-HTTP ProxyCoAP Client发送携带Proxy-URI或者Proxy-Scheme的Request请求到ProxyProxy对HTTP resource执行Request中method指定的操作，并返回响应协议定义了Proxy对CoAP request应该返回的Response，至于代理如何实现以满足这个要求属于实现细节，协议未具体定义如果Proxy不愿服务一个携带指定URI的Request，返回client一个5.05 Proxying Not Supported如果Proxy将Request转发

64、到origin http server，超时未得到响应，Proxy应该给client返回5.04 Gateway Timeout；或者得到了origin server的响应，但是无法解析，给client返回一个5.02 Bad Gateway响应70高级材料CoAP-HTTP Proxy GET methodGET方法请求代理返回request URI标识的HTTP resource的Representation如果Proxy处理成功，返回2.05 Content的response，Payload是target HTTP resource的Representation，并设置合适的Conten

65、t-Format;协议要求必须要携带Max-Age Option协议要求如果HTTP 实体包含一个entity-tag，响应中需要包含Etag OptionClient可以通过如下处理影响Proxy返回的Response在发往Proxy的request中增加Accept指定优先考虑的content-format在发往Proxy的Request中增加一个或多个ETag，当有一个ETag和Proxy缓存的Response匹配时，使得Proxy返回2.03 Valid，否则Proxy返回2.05 Content71高级材料CoAP-HTTP Proxy PUT methodPUT方法请求代理更新或者

66、创建request URI标识的HTTP resource的enclosed Representation如果new Resource创建成功，返回2.01 Created的response如果已有的Resource更新成功，返回2.04 Changed的response72高级材料CoAP-HTTP Proxy DELETE methodDELETE方法请求代理删除request URI标识的HTTP resource如果Resource删除成功，返回2.02 Deleted的response如果Resource不存在，返回2.02 Deleted的response73高级材料CoAP-HT

67、TP Proxy POST methodPOST方法请求代理让HTTP origin server处理request URI标识的HTTP resource的Representation，如何处理由HTTP server根据request URI确定如果执行结果不会导致一个可以用URI标识的Resource，返回2.04 Changed的response如果在origin Server创建了Resource，返回2.01 Created的response74高级材料HTTP-CoAP ProxyHTTP-CoAP ProxyHTTP Client发送携带URI为“coap”、“coaps”的R

68、equest请求到ProxyProxy对CoAP resource执行Request中method指定的操作，并返回响应给Client协议定义了Proxy对HTTP request应该返回的Response，至于代理如何实现以满足这个要求属于实现细节，协议未具体定义如果Proxy不愿或不能服务一个携带指定CoAP URI的Request，返回client一个5.01 Not Implemented如果Proxy将Request转发到origin http server，超时未得到响应，Proxy应该给client返回5.04 Gateway Timeout；或者得到了origin server

69、的响应，但是无法解析，给client返回一个5.02 Bad Gateway响应75高级材料HTTP-CoAP Proxy OPTIONS and TRACE methodHTTP-CoAP Proxy不支持OPTIONS和TRACE方法，返回501 Not Implemented76高级材料HTTP-CoAP Proxy Head methodHead方法等价于GET方法，区别是Server返回的Response不能包含message-body尽管CoAP对于HEAD方法没有对应的方法，HTTP-CoAP Proxy可以返回对于CoAP resource的响应，并且响应中只有header，没

70、有message-bodyHTTP-CoAP代理可能想尝试使用块方式传输选项BLOCK以最小化实际传输的数据量，但是它需要为源服务器不支持块方式传输的情况做好准备77高级材料HTTP-CoAP Proxy POST methodPOST方法请求代理让CoAP origin server处理request URI标识的CoAP resource的Representation，如何处理由CoAP server根据request URI确定如果执行结果不会导致一个可以用URI标识的Resource，返回200 OK或者204 No Content的response如果在origin Server创建

71、了Resource，返回201 Created的response如果CoAP response中包含Location-* Option，返回给HTTP Client的Response中药包含Location heaer78高级材料HTTP-CoAP Proxy PUT methodPUT方法请求代理更新或者创建request URI标识的CoAP resource的enclosed Representation如果new Resource创建成功，返回201 Created的response如果已有的Resource更新成功，返回204 No Content或者200 OK的response7

72、9高级材料HTTP-CoAP Proxy DELETE methodDELETE方法请求代理删除request URI标识的CoAP resource如果response中包含描述状态的实体，返回200 OK的response如果Delete动作已执行但是response中不包含实体，返回2.02 Deleted的response80高级材料HTTP-CoAP Proxy CONNECT method当前不支持该方法，因为TLS 到 DTLS的隧道目前无标准；收到该HTTP 方法的Request，返回501 Not Implemented的Response81高级材料目录概述Message M

73、odelRequest/Response ModelOptionsResponse的缓存机制CoAP组播CoAP代理Securing CoAP82高级材料Securing CoAP模式支持加密，需要给Device预置加密相关配置以及访问控制列表CoAP支持通过DTLS加密，定义了如下安全模式NoSec：Disable DTLSPreSharedKey：Enable DTLS，定义一组预共享秘钥，每个秘钥用于的通信节点；极限情况下，该节点和任意通信节点都有一个presharekey，此为1:1模式；相反的话，大于两个用户使用一个presharekey，该key只能用于认证该用户成为改组的成员，而

74、不能用于peer到peer认证必须支持TLS_PSK_WITH_AES_128_CCM_8(RFC6655)RawPublicKey：Enable DTLS，定义一对预共享公钥。设备可以从公钥中导出身份标识，以及可以与之通信的节点列表必须支持TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8Certificate：Enable DTLS，通过X.509数字证书获取公钥协议要求必须支持NoSec和RawPublicKey模式83高级材料Securing CoAPCoAP支持通过DTLS加密，相对非加密场景的变化CoAP over UDP 和 CoAP over TLS知名端口不

75、同，request URI sheme不同Message Layer：CoAP通信前，需要建立TLS session，Message作为DTLS的payload处理，增加了DTLS header(13 byte)的开销；Message除通过Message ID匹配外，还需要满足在同一个DTLS session和epoch内；Request/Response Layer：Request和Response除通过Token匹配外，还必须满足在同一个DTLS session和epoch内在RawPublicKey和Certificate安全模式下，DTLS connection采用相互认证，所以CoA

76、P应该尽量重用该连接，而不是每次Message交互都关闭，重建DTLS连接不支持组播加密(没有组播key)需要支持RFC6066定义的SNI扩展，以便能和一个主机上运行多个Virtual Server的主机建立TLS连接84高级材料Pre-Shared Keys当和新的节点建立连接时，系统根据配置选择一个Pre-Shared Key，参照RFC4279定义的流程建立TLS连接实现上要求必须支持RFC6655定义的TLS_PSK_WITH_AES_128_CCM_8加密套件基于试运行模式，应用程序也许需要为身份提示定义一份应用清单(RFC4279 5.2)，使能PSK身份提示需要应用RFC427

77、9 section 7中的安全建议：是否需要PFS(Perfect Forward Secrecy)并选择合适的加密套件，避免遭受暴力破解和字典攻击明文传输客户端身份标识，可能导致数据泄露，危害隐私85高级材料Raw Public Key Certificates在这种模式下，系统预置一对非对称密钥对（不基于数字证书），实现上可以考虑通过制造商产生，并且安装在设备上；秘钥的类型和长度依赖于需要支持的加密套件，协议要求必须实现rfc7251/rfc5246/rfc4492定义的TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8协议要求必须支持RFC4492定义的curve se

78、cp256r1，hash算法是SHA-256协议要求必须Elliptic Curves和Point Formats Extensions(rfc4492)协议要求必须支持uncompressed point format（rfc6090）TLS使用raw public key的机制由rfc7250定义86高级材料Raw Public Key Certificates特别的，协议要求DLS握手过程中必须出现如下扩展Extension: elliptic_curvesType: elliptic_curves (0x000a)Length: 4Elliptic Curves Length: 2El

79、liptic curves (1 curve)Elliptic curve: secp256r1 (0x0017)Extension: ec_point_formatsType: ec_point_formats (0x000b)Length: 2EC point formats Length: 1Elliptic curves point formats (1)EC point format: uncompressed (0)Extension: signature_algorithmsType: signature_algorithms (0x000d)Length: 4Data (4 b

80、ytes): 00 02 04 03HashAlgorithm: sha256 (4)SignatureAlgorithm: ecdsa (3)87高级材料参考文档RFC7252 The Constrained Application Protocol (CoAP)88高级材料HTTP幂等性和安全性Http协议规定了不同方法的安全特性和幂等特性，作为服务提供者的服务器必需为客户端提供这些特性。安全性，仅指该方法的多次调用不会产生副作用，不涉及传统意义上的“安全”，这里的副作用是指资源状态。即，安全的方法不会修改资源状态，尽管多次调用的返回值可能不一样(被其他非安全方法修改过)。幂等性，是指该方法多次调用返回的效果(形式)一致，客户端可以重复调用并且期望同样的结果方法名安全性幂等性GET是是HEAD是是OPTIONS是是DELETE否是PUT否是POST否否89高级材料RESTREST即表述性状态转移(Representational State Transfer)，是Roy Fielding博士(HTTP规范的主要设计者之一)在2000年他的博士论文中提出来的一种基于网络的软件架构风格满足REST架构风格的标准或软件架构，称为是RESTful的90高级材料91高级材料