題目
大家好，超子又和大家見面了，超子我能力有限，水平不高，有什麼錯誤的地方，歡迎板磚。超子接下來先介紹一下CoAP協議中的報文結構，只有瞭解了報文的基本結構之後，我們才能具體的構建對接阿里雲物聯網平臺是的認證還有上傳數據時需要的報文。
CoAP協議報文結構圖
CoAP協議報文結構的概覽圖，如上圖所示，注意一行是4個字節，每個字節的Bit7在左，Bit0在右。
我們先看第一個字節的Bit7~4。Ver是版本號，當前的版本要求Bit7是0 ，Bit6是1。再看T，其代表報文類型，有四種選項，分別是CON報文，NON報文，ACK報文和RST報文。
CON報文：如果我發給你一個CON報文，你必須回覆一個報文，不管正確與否，總之不能不吭聲。
NON報文：如果我發給你一個NON報文，你不必做出回覆 。
ACK報文：針對CON的回覆報文，你發我一個CON報文，正確的情況下，我得回你一個ACK報文。
RST報文：假如你發的CON報文錯誤，我不能回你ACK報文，我得回你RST報文。
不同的報文Bit5和Bit4的值如下所示：
CON報文： Bit5是0， Bit4是0
NON報文： Bit5是0， Bit4是1
ACK報文 ：Bit5是1， Bit4是0
RST 報文： Bit5是1， Bit4是1
再看Message ID，是2個字節的報文編號，這個作用和MQTT中的報文標識符類似。假設我連著上傳3次數據，1個出錯，2個正確，如果Message ID一樣，阿里雲回覆的時候，我們無法區分出誰正確誰失敗，因為我們發送的順序和阿里雲回覆的順序沒關係，所以需要用Message ID來區分。其佔用2個字節，我們可以從0x0001開始，每發一次報文，累加1即可。
再看TKL和Token，TKL用於指定Token佔用多少字節，目前支持的範圍是0~8個字節。Token類似於Message ID，發送和回覆的雙方要一致，Message ID一般是累加的，用一個之後加1。Token的一個用法是增加安全性，比如使用最多的8字節隨機Token，有助於提高安全性，防止偽造報文。但是阿里雲使用了對稱加密方式，提高對數據的安全保護，所以就不使用這個Token了。如此一來TKL是0，表示沒有Token，所以Bit3/2/1/0都是0。
Code是功能碼，佔用1個字節，共有4種，GET、POST、PUT和DELETE。和HTTP的差不多。
GET：獲取數據，取值0x01。
POST：上傳數據，取值0x02。
PUT：更新數據，取值0x03。
DELETE：刪除數據，取值0x04。
和HTTP協議一樣，阿里雲的CoAP只支持POST。
Payload是要上傳的數據，認證的時候要傳三元組的信息，傳數據的時候就是溫溼度值，當然都需要經過加密。注意Payload前的7個都是1的Bit位，換成16進制就是0xFF，這個是分割符，將數據Payload同前面的報文內容分開，類似於HTTP協議中header和body之間的一個空行。
Options包含許多參數，類似於HTTP的頭部header，比如設置HOST，PATH，URL，端口號等等，這個就要根據阿里雲的要求來設置了，超子今天就先總體的介紹下CoAP協議的報文結構，掌握了報文的結構之後，我們在一起構建具體的報文。
閱讀更多 超子說物聯網 的文章
