CoAP是一种可实现M2M需求的受限Web协议,建立在UDP之上,利用了UDP服务来完成其消息的交换。CoAP协议共有4种不同的消息类型。
①CON:需要被确认的请求,如果CON请求被发送,那么对方必须做出响应。
②NON:不需要被确认的请求,如果NON请求被发送,那么对方不必做出回应。
③ACK:应答消息,接受CON消息的响应。
④RST:复位消息,当接收者接受的消息包含一个错误,接受者解析消息或者不再关心发送者发送的内容,那么复位消息将会被发送。
对请求/响应交互过程来说,上述4种类型消息的基本交换过程都是透明的。
CoAP在逻辑上分成两层消息(Messages)层和请求/响应(Requests/Responses)层。
若要实现可靠性,可用CON消息来提供此项功能。CON消息在默认的超时间隔后会重传,两次重传间采用指数后退方法,直至接收者发送了ACK。此ACK消息包含与相应的CON消息相同的消息ID。
CoAP协议头部中域的含义(图5.1)如下所述:
①版本域(Version,Ver):长度为2 bit,用于指出CoAP版本号。
②类型域(Type,T):长度为2 bit,用于指出CoAP消息的类型。
③选项数(Option Count,OC):长度为4 bit,用于指出头部后的选项数目(0~14)。
④代码(Code):长度为8 bit,用于指出消息携带的载荷类型。(www.xing528.com)
⑤消息ID(Message ID):长度为16 bit,用于检测重复消息。
图5.1 CoAP协议头部中域的含义
消息大小在受限节点上的实现也是一个很重要的问题,需要被专门考虑,例如,6LoWPAN L2分组被限制到127 bit,包括各种开销。若实现太受约束以至于不能考虑分配上述提及的上界数目,则可使用如下实现策略:
①对接收一个报文进入一个太小的缓存的实现方案通常能够决定报文的尾部是否应该被丢弃并检索初始部分。
②若非全部有效载荷,至少CoAP头部和选项可以放入缓存中。
③若有效载荷被裁减,服务器能够充分解释此请求并返回4.13(请求实体太大)的响应代码。
CoAP消息在CoAP端节点之间异步交换,它们被用来传输CoAP请求/响应。由于CoAP与非可靠传输协议(如UDP)绑定在一起,因此CoAP消息可能会无序到达、出现重复或丢失。基于此,CoAP需要实现一个轻量级的可靠机制,而不是试图重建类似TCP的全部传输特征集。其特点如下:
①针对CON消息,采用简单的停-等重传可靠机制,使用指数后退方法。
②既针对CON消息又针对NON消息的消息包重复检测。
③多播支持。
CoAP在与HTTP类似的请求/响应模式下操作,起客户作用的CoAP端节点发送一个或多个CoAP请求到服务器,此服务器通过发送CoAP响应为这些请求服务。不同于HTTP,请求/响应不在以前建立的连接上发送,但在CoAP消息上异步交换。
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。