物聯網協議之CoAP協議開發學習筆記之術語解釋

哪有什麼天生如此，只是咱們每天堅持。 -Zhiyuan

此文章主要總結CoAP協議的術語解釋：

只在網上找到了[RFC2616] 的解釋，可是這些都是通用的
本文檔要求讀者熟悉[RFC2616]中討論的全部術語，包括resource , representation，cache和fresh。（對HTTP協議更新的RFC有7230到7235，但因爲本文檔的完成早於這些對HTTP協議更新的rfc，故本文檔引用的是先前的HTTP協議版本：[RFC2616]）。此外，本文檔定義瞭如下術語：

• 端(Endpoint)
  參與CoAP協議的一個實體。通俗的說，一個端指的是一個節點(node)，儘管Host這個詞更符合互聯網標準，與傳 輸層的多路複用技術聯繫起來，能夠包括一個UDP端口號。
• 發送者(Sender)
  消息的發起端。從交互角度來講，也稱爲「源端」（source endpoint）。
• 接收者(Recipient)
  消息的目的端。從交互角度來講，也稱爲「目的端」（destination endpoint）。
• 客戶端(Client)
  消息請求的源端，消息響應的目的端。

• 服務端(Server)
  消息請求的目的端，消息響應的源端。

• 原始服務端(Origin Server)
  存儲或建立一個給定的資源的服務端。

• 中間人(Intermediary)
  對於一個原始服務端（也多是其它的中間人）來講，一個便是服務端又是客戶端的CoAP端。常見的場景是一個代理。

• 代理(Proxy)
  代理是主要做用爲轉發請求和響應消息的中間人，有可能起到緩存，命名空間轉換，或者協議轉換的做用。與通常的中間人不一樣的是，代理一般不實現任何語義。在轉發請求的場景下，根據定位的不一樣，主要分爲兩種：正向代理和反向代理。在某些狀況下，一個端有可能根據每個請求的特性轉換本身的角色，能夠做爲原始服務端、正向代理或反向代理。
• 正向代理(Forward-Proxy)
  即客戶端的代理，一般是經過本地配置，用來表明客戶端發出請求，必要時作一些轉換。有些轉換是很細微的，如代理「coap」開頭的URI，然而有些請求則須要在其它應用層協議和coap協議間做轉換。

• 反向代理(Reverse-Proxy)
  代替一個或多個服務端接收請求的端，必要時作一些轉換。與正向代理不一樣的是，反向代理對客戶端多是徹底透明的。反向代理接收請求，把它本身當成目標資源的原始服務端。
• CoAP到CoAP代理(CoAP-to-CoAP Proxy)
  把一個CoAP請求映射到另外一個CoAP請求的代理。也就是說它的服務端部分和客戶端部分都使用CoAP協議。與「跨協議代理」造成對比。

• 跨協議代理(Cross-Proxy)
  跨協議代理指的是在不一樣協議之間作轉換的代理，例如一個從CoAP到HTTP的代理，或者HTTP到CoAP的代理。相對於CoAP到CoAP代理，跨協議代理有不少種。

• 需應答消息(Confirmable Message)
  要求ACK的消息稱爲需應答消息。當沒有發生數據包丟失的時候，每一個需應答消息一定會有一個類型爲ACK或Reset的響應。後面簡寫爲CON。

• 不需應答消息(Non-confirmable Message)
  不要求ACK的的消息稱爲不需應答消息。一般用於某些應用中週期性的重複發送數據的情形，例如不斷的讀取一個傳感器的數據。後面簡寫成NON。

• ACK消息(Acknowledgement Message)
  ACK消息用於確認某個可靠消息已經到達。ACK消息自身並不表明這個請求處理的結果是成功仍是失敗。ACK消息有可能會同時爲附帶響應(Piggybacked Response)。

• 重置消息(Reset Message)
  Reset消息表明的是一個消息（須要應答或者不須要應答的消息）被收到了，可是因爲缺乏某些上下文信息而沒法被正常的處理。這種狀況一般是因爲接收節點重啓了，於是缺失了一些必要的信息，致使當前接收到的消息沒法被處理。利用reset消息，也是一種低開銷的檢查端是否存活的方式（也稱做CoAP ping，發送一個空的需應答消息）。後面簡寫成RST。

• 附帶響應(Piggybacked Response)
  附帶響應指的是，對於一個請求消息，它的ACK消息中包含了響應數據。

• 單獨響應(Separate Response)
  當請求是一個需應答消息時，若是它的ACK是一個空消息（由於服務端對該請求產生對應結果須要一些時間），那麼就須要一個單獨的消息交換過程來完成對請求的響應（5.2.2節）。

• 空消息(Empty Message)
  空消息的code是0.00，有多是請求，也多是響應。空消息只有4個字節的header，沒有body部分。

• 重要選項(Critical Option)
  指的是這樣的選項：只有接收端正確的理解這個選項，那麼這個請求才能被正確的處理（5.4.1節）。注意，這些選項的值一般都有一個範圍，不支持的選項值會致使錯誤的響應消息或者拒絕這個消息。

• 非重要選項(Elective Option)
  非重要選項指的是若是接收端不理解這個選項，那麼能夠把它忽略。協議容許忽略這個選項而對消息進行處理（參見5.4.1節）。

• 非安全選項(Unsafe Option)
  非安全的選項指的是，代理必須理解這個選項才能正確的轉發這個消息。並不是全部的重要選項都是非安全選項。

• 轉發安全選項(Safe-to-Forward Option)
  代理不理解這個選項，但也能夠安全的轉發這個消息。在不理解這個選項的狀況下，也能夠轉發這個消息（參見5.4.2節）。

• 資源發現(Resource Discovery)
  資源發現指的是CoAP客戶端得到服務端支持的全部資源列表的過程（參見第7章）。

• 內容格式(Content-Format)
  內容格式指的是互聯網媒體類型和內容編碼，用一個數值型標識符來標識。這個數值型標識符在「COAP 內容格式」中定義。當重點注意力不是在這個數值型的標識上，而是在資源表現自己時，就稱做「表現格式」（REPRESENTATION FORMAT）。

參考文獻：
https://github.com/WildDogTea...

學以至用，靈活運用。祝你們好運！