从http协议看coap协议解决物联网问题
在当前的互联网通信协议中，HTTP协议以其开发成本低，开放程度高，占据绝对统治地位。但 随着物联网时代的到来，大规模海量设备接入网络，http协议因其自身的局限性，虽然很好的解决了互联网通信问题，但无法很好的解决物联网问题。http协议解决物联网问题的主要局限有，资源消耗大，单方向收发，TCP长连接带来的并发数及功耗问题。
Coap协议应运而生，为了克服 HTTP在物联网中的局限性，CoAP 做了一些优化，主要包括协议包轻量化，双向收发，采用udp无连接等。
- 协议轻量化
如上图所示，除了将协议头压缩为4字节外，采用option定义协议参数，是coap相较于http在协议轻量化方面做的最大的改动，http协议采用XML语言定义协议参数，虽然可读性很高，但是消耗了大量的资源，在资源受限的物联网设备中无疑是个很大的压力。
1.1 option数据结构
CoAP定义了许多option。消息中的每个option都有一个option编号，option值长度，和option值。 消息中的option号（TLV格式中的T） 并不是直接指定option编号的。所有的option必须按实际option编号的递增排列，某一个option和上一个option之间的option编号差值为delta；每一个TLV格式的option号都是delta值（数据包中第一个option的delta即它的option编号） 。同一个编号的option再次出现时，delta的值为0。
如上图所示，Option包含Option Delta、Option Length和Option Value三部分。
【Option Delta】表示Option的增量，当前的Option的具体编号等于之前所有Option Delta的总和。
【Option Length】表示Option Value的具体长度。
【Option Value】表示Option具体内容
1.2 常用option解析
常用option说明如下，Uri-Host、Uri-Port、Uri-Path和Uri-Query等和资源“位置”和参数有关。
【3】Uri-Host:CoAP主机名称
【6】Observe:coap协议未定义，目前已默认作为observe请求标志位。0：订阅；1：取消订阅。
【7】Uri-Port:CoAP端口号，默认为5683
【11】Uri-Path：资源路由或路径，对比http协议中的\led。资源路径采用UTF8字符串形式，长度不计第一个"\"。如果再支持LwM2M协议的话，该option描述可进一步简化为objId，InstId以及resId的数值形式表示。
【15】Uri-Query:访问资源参数，对比http协议中的?para1=1¶2=2，参数与参数之间使用“&”分隔，Uri-Query和Uri-Path之间采用“?”分隔。
【12】Content-Format:指定CoAP复杂媒体类型，媒体类型采用整数描述。
【17】Accept: 指定CoAP响应复杂中的媒体类型，媒体类型的定义和Content-Format相同。
2、双向收发
Coap虽然定义了client和server角色，如下图所示，每次数据传输都是由client段发起资源请求，server端进行响应。但在实际操作中，client和server的角色并不是固定的，即设备和服务器都有可能充当client或者server的角色，两者都存在对方可能要访问的资源，这是和http协议最大的不同，也是coap协议解决物联网场景问题的关键所在。
对于物联网场景，服务器会主动获取设备资源或者下发资源到设备，这时设备充当coap的server角色；设备也会主动上报资源或者注册到服务器，这时设备充当coap的client角色。
3、寻址
物联网设备一般位于局域网中，IP地址为局域网IP地址；服务器一般位于公网中，ip地址为公网IP地址，因此服务器无法直接访问设备，必须在设备主动访问服务器之后，服务器获取到设备IP地址后。因此在物联网应用场景中，第一条数据一定是设备主动发送给服务器的，比如中移onenet平台，设备首先要发注册消息，注册到平台；比如联通ayla平台，设备首先要发送oberve消息订阅某一资源，ayla平台才会下发数据到设备。
因此物联网平台的协议定义中，都会首先有一条设备主动发送数据的协议要求，协议上是描述设备的需求，根本问题是解决设备寻址。
并发数
海量设备接入服务器是一个比较大的压力，为减少服务器的并发连接量，coap基于udp连接，即无连接的方式，另外为保证传输质量，增加了确认包，便于应用层可以进行可靠传输服务。