不像人接入互联网的简单方便,由于物联网设备大多都是资源限制型的,有限的CPU、RAM、Flash、网络弊弊神宽带等。对于这类设备来说,想要直接使用现有网络的TCP和HTTP来实现设备实现信息交换是不现实的。于是为了让这部分设备能够顺利接入网络,CoAP协议就被设计出来了。
以上是来自维基百科对CoAP的定义。简言之,CoAP是受约束设备的专用Internet应用程序协议。
CoAP是一个完整的二进制应用层协议,消息格式紧凑,默认运行在UDP上。
这一类型的状态码,代表请求已成功被服务器接收、理解、并接受。
这类的状态码代表了客户端看起来可能发生了错误,妨碍了服务器的处理。
这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生,也有可能是服务器的软硬件资源无法完成对请求的处理。
CoAP参考了很多HTTP的设计思路,同时也根据受限资源限制设备的具体情况改良了诸租亏多的设计细节,增加了卜早很多实用的功能。
CoAP协议的设计参考了HTTP,CoAP和MQTT都是行之有效的物联网协议,一下为它们之间的异同。
EMQ的开源版提供了一个 Generic CoAP 的实现,读者如果有兴趣的话可以试用一下。在EMQ的商业版中,包含了对CoAP的完整支持。
CoAP的URL
在HTTP的世界中,RESTFul协议由于其简单性和适用性,在WEB应用中越来越受欢迎,这样的道理同样适用于CoAP。
一个CoAP资源可以被一个URI所描述,例如一个设备可以测量温度,那么这个温度传感器的URI被描述为:CoAP://machine.address:5683/sensors/temperature。
请注意,CoAP的默认UDP端口号为5683。
CoAP观察模式
在物联网的世界中,你需要去监控某困樱族个传感器例如温度或湿度等。
在这种情况下,CoAP客户端并不需要不停的查询CoAP服务器端的数据变化情况。
CoAP客户端可以发送一个观察请求到服务器端。
从该时间点开始计算,服务器便会记住客户端的连接信息,一旦汪弊温度发生变化,服务器将会把新结果发送给客户端。
如果客户端不在希望获得温度检测结果,那么客户端将会发送一个RST复位请求,此时颂弯服务器便会清除与客户端的连接信息。
CoAP块传输
CoAP协议的特点是传输的内容小巧精简,但是在某些情况下不得不传输较大的数据。
在这种情况下可以使用CoAP协议中的某个选项设定分块传输的大小,那么无论是服务器或客户端可完成分片和组装这两个动作。
coap是比较常用的物联网传输协议,基于udp协议之上的应用层协议。下面基于rfc7252对coap报文进行分析。
rfc7252对coap的报文头定义如上,8位表示一个字节,可以看到coap协议字节还是比较节省的。
第一个字节的8位,2位表示协议版本号(每个协议都有协议版本号,为了兼容性考虑),在这里rfc7252规定这里必须填01,其他的留给以后或燃的版本。
2位表示消息类型,其实是一个枚举值2^2有四个消息类型.对于这四种消息类型,rfc7252给的回复标准是:
4位的token,结衫瞎虚合可选的token确定是否在报文里面携带token信息,也就是说coap协议最多可携带2^4-1的15个字节的token信息
紧接着是1字节的code信息,这里的code也是一个枚举值类型,表明请求类型,类似于http的请求方法,不过与http不同的http采用明文表明请求方法,无论你请求方法是啥,只占用1个字节。有的同学就说了,255个方法是不是有点多了,确实,所以对于这一个字节,协议又把它细分了,前三位和后五位,所以就形成了x.xx的数据结构
2个字节的messgaeid,标示请求和响应的对应关系啊。65535个,用完了再循环呗。
变字节长度的token,结合第一个字节4位的token长度可确定token的字节数。神腊
变长度的option可选配置,有的同学说了,coap不是说是rest的方式请求的吗?那我的方法知道在哪了,uri我放在哪呢?没错就是放在options里面去配置,编码如下。
既然options是变长的,前面爷没有说明option的长度,那它和payload怎么区分边界,在这里,协议规定了ff之后就是payload内容,就是你要传递的业务数据了。
下面以一个请求响应报文说明上面的分析:
至此分解到此结束,coap协议要写的地方还很多,下次再补充吧,欢迎各位大佬斧正!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)