1. 物聯網應用上一般使用單片機（或者其他SOC），單片機的RAM內存一般只有20KB~~128KB左右，然而一個TCP協議棧可能就20KB，所以只能用UDP，因爲UDP相對小很多，然後在UDP上加了一層協議，就是Coap協議，CoAP是受限制的應用協議(Constrained Application Protocol)的代名詞，受限制就是RAM的空間小的單片機用。
2. 想搞懂，最快的辦法是看協議，如下圖，着重關注實際會用到的字段，忽略暫時不關心的。
【Ver】 版本編號，指示CoAP協議的版本號。這個不重要，可以先不管
【T】報文類型，CoAP協議定了4種不同形式的報文，CON報文，NON報文，ACK報文和RST報文。
【TKL】CoAP標識符長度。
【Code】功能碼/響應碼。Code在CoAP請求報文和響應報文中具有不同的表現形式，Code佔一個字節，它被分成了兩部分，前3位一部分，後5位一部分，爲了方便描述它被寫成了c.dd結構。其中0.XX表示CoAP請求的某種方法，而2.XX、4.XX或5.XX則表示CoAP響應的某種具體表現。
【Message ID】報文編號
【Token】標識符具體內容，通過TKL指定Token長度。
【Option】報文選項，通過報文選項可設定CoAP主機，CoAP URI，CoAP請求參數和負載媒體類型等等。
【1111 1111B】CoAP報文和具體負載之間的分隔符。
3. 聚焦第一個點，報文類型
CON報文，就是發出去的報文，需要接收方返回有沒有收到，就像你叫一個人的名字，你要求那個人得“嗯”一聲作爲迴應。
NON報文，像你叫一個人的名字，你要求那個人可以不迴應你。
ACK報文，別人叫了你的名字，你得“嗯”迴應人家（因爲別人要求你迴應），這個“嗯”就是ACK。
RST報文，別人叫了你的名字，但是叫錯了名字，然後你不想回應別人，那你就給RST。
注意第一個細節，Coap是分爲服務器和客戶端的，在上面4種報文，客戶端和服務器都可以發送和應答的。
4. 聚焦第二個點，功能碼/響應碼，前面說過分爲客戶端和服務器，客戶端發給服務器的數據叫做Coap請求，請求有4個功能碼分別對應CoAP請求方法中的GET、POST、PUT和DELETE，先說0.01是個什麼意思？前面說過前3位一部分，後5位一部分，那麼Code=0x01，換成二進制0000 0001，前三位是000，後5位是00001，合起來就是0.01，資源是什麼？可以理解是一個燈泡的開關等，一個溫度傳感器的數據。
【0.01】GET方法——用於獲得某資源
【0.02】POST方法——用於創建某資源
【0.03】PUT方法——用於更新某資源
【0.04】DELETE方法——用於刪除某資源
5. 服務器發給客戶端的數據叫做Coap響應。注意，服務器不能給客戶端發Coap請求！！同時在實際產品中，一般溫度傳感器設備是一個服務器，可能剛開始看的人懵逼，不要緊，可以先跳過這一點。在CoAP響應中，Code被定義爲CoAP響應碼。
【2.01】Created
【2.02】Deleted
【2.03】Valid
【2.04】Changed
【2.05】Content。類似於HTTP 200 OK
【4.00】Bad Request 請求錯誤，服務器無法處理。類似於HTTP 400。
【4.01】Unauthorized 沒有範圍權限。類似於HTTP 401。
【4.02】Bad Option 請求中包含錯誤選項。
【4.03】Forbidden 服務器拒絕請求。類似於HTTP 403。
【4.04】Not Found 服務器找不到資源。類似於HTTP 404。
【4.05】Method Not Allowed 非法請求方法。類似於HTTP 405。
【4.06】Not Acceptable 請求選項和服務器生成內容選項不一致。類似於HTTP 406。
【4.12】Precondition Failed 請求參數不足。類似於HTTP 412。
【4.15】Unsuppor Conten-Type 請求中的媒體類型不被支持。類似於HTTP 415。
【5.00】Internal Server Error 服務器內部錯誤。類似於HTTP 500。
【5.01】Not Implemented 服務器無法支持請求內容。類似於HTTP 501。
【5.02】Bad Gateway 服務器作爲網關時，收到了一個錯誤的響應。類似於HTTP 502。
【5.03】Service Unavailable 服務器過載或者維護停機。類似於HTTP 503。
【5.04】Gateway Timeout 服務器作爲網關時，執行請求時發生超時錯誤。類似於HTTP 504。
【5.05】Proxying Not Supported 服務器不支持代理功能。
6. option選項，主要是用來配置一些參數，比如是否用到代理服務器，目的主機的端口等。
7. 一個比較重要的點，觀察者模式，實際應用常用到，這個觀察者模式在協議裏面並沒有體現出來，物聯網場景中，CoAP客戶端有時並不需要不停的查詢CoAP服務器端的數據變化情況(比如需要去監控某個溫度或溼度傳感器)。此時CoAP客戶端可以發送一個觀察請求到服務器端，從該時間點開始計算，服務器便會記住客戶端的連接信息，一旦溫度發生變化，服務器將會把新結果發送給客戶端。如果客戶端不在希望獲得溫度檢測結果，那麼客戶端將會發送一個RST復位請求，此時服務器便會清除與客戶端的連接信息。
8. 爲什麼溫溼度傳感器是一個服務器，看了觀察者模式，應該就清楚了。
9. 觀察者模式，可能有多個觀察者，那麼服務器需要記錄多個觀察者的信息，然後變化的時候，需要去一個個的發送。
10. Coap的觀察者模式和LWM2M的觀察者模式基本是一樣的，在服務器上，需要開啓一個任務，一直查詢是否有客戶端的Coap請求，然後對應4個回調函數，當然這個是Coap的代碼協議棧的實現框架。
11. 總結，本次主要是圍繞實際會使用的Coap相關的技術點進行解析，並沒有巨漏無疑的全篇講解，跳過了一些知識點。