CoAP的块传输详解.ppt

* * 关于Caching 协议对于cache持开放态度，尤其是在proxy cache 缓存机制可以将每个Block单独缓存（部分缓存），也可以收集完整个body再做处理； 协议认为部分缓存对于cross proxy更为高效 部分缓存时每个Block有单独的Max-Age，一个fresh一个block的response，可以fresh所有的block 在控制使用中使用Block1选项的Response（设置了M位）使目标URI的缓存的Response无效 无状态服务器可能仅在传输的第一个Block1块上响应2.01，这支持了后面的块的任何2.04响应 组合响应（例如，对请求中的分割块或增加响应中的块大小或交叉代理）的高速缓存或代理可能需要组合2.31和2.01 / 2.04响应; * 如有疑问欢迎讨论 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 基于CoAP的块传输详解 Jade 2016/12 目录 概述 新的Options和Response Examples Others 概述 RFC7959定义了CoAP协议的块输出规范，对于resource representation无法通过一个CoAP数据包承载时，发起块传输过程 为何在CoAP引入块传输 CoAP基于UDP，最大传输数据报的长度为64KByte，无法支持FW升级（除非开发基于CoAP的特定应用） 避免数据报文分片(基于IP) 避免适配层分片（基于RFC4919 6LoWPAN） 术语说明 Payload：指的是单个CoAP Message中的内容 Body：通过块传输的Resource Presentation整体内容 目录 概述 新的Options and Response Examples Others 新增的Option CoAP块传输标准新增了4个Option(size1最早在RFC7252中定义，RFC7959扩展了其含义) 块传输机制采用Block1和Size1完成Request中Resource Presentation的块传输；采用Block2和Size2完成Response中的Resource Presentation的块传输 Size Option是Elective且Safe-to-Forward的，并且是No-Cache-Key Block Option格式 Option Value为变长0-3个字节的无符号数 NUM：具有给定大小的块序列内的块（NUM）的相对数（从0开始编号），即块序号 M：是否有更多块 SZX:块大小，取值0-6，实际每个块的payload为2**(4+SZX)，即块大小为16-1024Byte Block Option语义 Block1和Block2都可以出现在Request和Response中，但是含义不同： Block1出现在Request中和Block2出现在Response中，代表正在执行块传输，它们描述了正在传输的Payload在整个Body的哪个部分，此称为描述性用法(descriptive usage) Block1和Block2用在上述相反的情况，提供了对如何形成或处理有效载荷的附加控制，此称为控制性用法(control usage) 描述性用法 Block1出现在Request中和Block2出现在Response中，Option value取值含义： NUM：表示当前Message的Payload在整个body中的编号 M：表示是否还有更多块才能完成整个body的传输 SZX：当M为1时，表示当前Message的Payload的大小(2**(SZX+4))；当M为0时，实际Payload为1到2**（SZX+4）Byte； 参考Example-1 of Block2和Example-1 of Block1 Block2的控制性用法 Block2出现在Request中，属于控制性用法： NUM：期望Response传输的块号 M：无意义，设置为0 SZX：当NUM为0时，表示希望采用的块大小；当NUM非0时，直接采用上一个接收到的Response中的块daxiao 说明 Block2作为描述性用法(出现在携带块的Response中)，Client端有机会通过Request中携带Block2(NUM:0,M:0,SZX:期望值)通知Server，Client端希望采用的块大小；参考Example-2 of Block2。如果Request建议一个比较大的SZX值，下一个Request必须将SZX调整为Response中的SZX，最终结果是Server使用其选择的较小的SZX或者是Se