物联网系统设计（第2版）.pptVIP

3）CoAP请求/响应模型带有piggy-backed响应的基本GET请求带有单独响应的GET请求NON请求/响应4）中间物、缓冲、资源发现为了高效地实现请求，CoAP协议支持响应缓冲简单缓冲便于使用携带在CoAP响应消息中的时新的有效信息，缓冲可位于端节点或中间物上CoAP是根据REST体系结构设计的，并具有类似HTTP协议的功能，因此在HTTP与CoAP或CoAP与HTTP之间进行映射是非常直截了当的，这样的映射可以方便地用于以下两个方面使用CoAP实现HTTPREST接口在HTTP和CoAP之间进行转换代理能实现这个转换，即它能转换方法代码或响应代码、内容类型和选项到相应于HTTP的特征上资源发现对M2M交互而言是很重要的，使用CoRE链路格式可支持此功能2．CoAP消息语法1）消息格式2）消息大小的实现考虑3）选项格式1）消息格式头部中域的含义如下所述。版本域（Version，Ver）：长度为2比特，用于指出CoAP版本号类型域（Type，T）：长度为2比特，用于指出CoAP消息的类型选项数（OptionCount，OC）：长度为4比特，用于指出头部后的选项数目（0～14）代码（Code）：长度为8比特，用于指出消息携带的载荷类型消息ID（MessageID）：长度为16比特，用于检测重复消息2）消息大小的实现考虑在许多受限网络中，更重要的一种分片发生在适配层例如，6LoWPANL2分组被限制到127B，包括各种开销消息大小在受限节点上的实现也是一个很重要的问题很多实现需要为输入消息分配缓存若实现太受约束以至于不能考虑分配上述提及的上界数目，则可使用如下实现策略：对接收一个报文进入一个太小的缓存的实现方案通常能够决定报文的尾部是否应该被丢弃并检索初始部分若非全部有效载荷，至少CoAP头部和选项可以放入缓存中若有效载荷被裁减，服务器能够充分解释此请求并返回4.13（请求实体太大）的响应代码3）选项格式选项中各个域的含义选项Delta域：长度为4比特，用于指示此选项的选项号码与前一个选项号码之间的差值长度域：指出选项值的长度，以字节计算选项结束标记：当头部选项计数域的值为15时，选项号码不受限制，由选项结束标记0选项Delta取值15，长度取值0）终止。当遇到这个标记，其后紧跟的是有效载荷（若有）3．CoAP消息语义CoAP消息在CoAP端节点之间异步交换，它们被用来传输CoAP请求/响应。由于CoAP与非可靠传输协议（如UDP）绑定在一起，因此CoAP消息可能会无序到达、出现重复或丢失。基于此，CoAP需要实现一个轻量级的可靠机制，而不是试图重建类似TCP的全部传输特征集。其特点如下：针对CON消息，采用简单的停-等重传可靠机制，使用指数后退方法既针对CON消息又针对NON消息的消息包重复检测多播支持1）可靠消息2）不可靠消息3）消息匹配规则4）消息类型5）多播6）拥塞控制1）可靠消息消息的可靠传输通过在CoAP头部标记消息为CON开始。接收者必须通过ACK消息确认这样的消息（或者若缺乏适当处理此消息的上下文信息，则必须用RST消息拒绝之），发送者在等待指数增加的间隔后重传CON消息，直到接收到ACK消息（或RST消息）或使用完尝试次数为止。CoAP端节点必须记录它发送的每个CON消息而等待相应的ACK或RST消息，因此，需要设置超时间隔和重传计算器来控制重传。2）不可靠消息接收者不必确认NON消息，因此可节省通信开销，但发送成功的可靠性会差一些。若接收者缺乏适当处理此消息的上下文，可以使用RST消息拒绝它，否则必须默认地忽略它。在CoAP层面上，没有方法检测NON消息是否被接收了。发送者可以选择多次发送NON消息。为此，需要指明消息ID，以便于区分重传消息。3）消息匹配规则ACK或RST对CON以及RST对NON的准确匹配规则响应消息的ID必须匹配原来的消息ID对于单播消息，响应的发送源必须匹配原消息的目的地址不考虑安全问题时，消息的目的地和响应源的IP地址和端口号必须匹配当考虑其他安全模型时，除了IP地址和UDP端口号匹配外，请求和响应必须有相同的安全上下文4）消息类型不同的消息类型由CoAP头部的T域指出消息可以携带请求、响应，或者空。这由CoAP头部的代码域（即Code域）指出，并与请求/响应模型有关CON：需要被确认的消息称为CONNON：不需要被确认的消息称为NONACK：ACK消息确认特定的CON消息的到达，由其消息ID识别RST：重置消息指出特定的消息（CON或NON）