在當前的互聯網通信協議中，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連接，即無連接的方式，另外爲保證傳輸質量，增加了確認包，便於應用層可以進行可靠傳輸服務。