Constrained Application Protocol

Constrained Application Protocol （ CoAP ）は、 RFC 7252で定義されている、制約のあるデバイス向けに特化したインターネットアプリケーションプロトコルである。「ノード」と呼ばれる制約のあるデバイスのインターネット通信のために作られた。CoAPは、制約のある同じネットワーク（低電力、損失の多いネットワークなど）上のデバイス間、デバイスとインターネット上の一般的なノード、両方がインターネットに参加している異なる制約のあるネットワーク上のデバイス間で使用できるように設計された。 CoAPは、携帯電話網上のSMSなど、他のメカニズムでも使用されている。

CoAPは、無線センサーネットワークノードなど、リソースに制約のあるインターネットデバイスでの使用を目的としたサービスレイヤプロトコルである。 CoAPは、Webへの統合を簡素化するためにHTTPに簡単に変換できるように設計されている一方で、マルチキャストサポート、非常に小さいオーバーヘッド、シンプルさなどの特化した要件も満たしている。マルチキャスト、低オーバーヘッド、シンプルさが、従来のインターネットデバイスよりもはるかに少ないメモリと電力で動作する傾向にある組み込み機器であるモノのインターネット（IOT）やマシン・ツー・マシン（M2M）デバイスにとって非常に重要である。したがって、動作効率は非常に重要である。CoAPはUDPまたはUDPアナログをサポートするほとんどの機器で動作可能である。

インターネットエンジニアリングタスクフォース（ IETF ）制約付きRESTful環境ワーキンググループ（ CoRE ）が、このプロトコルの主要な標準化作業を行った。プロトコルをIoTおよびM2Mアプリケーションに適したものにするために、さまざまな新しい機能が追加されている。プロトコルのコアは RFC 7252 で規定されている。重要な拡張機能は、標準化プロセスのさまざまな段階にある。

特徴

ノードには多くの場合、少量のROMとRAMを備えた8ビットのマイクロコントローラーが用いられており、低電力ワイヤレスパーソナルエリアネットワーク（ 6LoWPANs ）を介したIPv6などの制約のあるネットワークでは、パケットエラー率が高く、通常は数十kbit/sのスループットしかない。このプロトコルは、スマートエネルギーやビルディングオートメーションなどのマシンツーマシン（M2M）アプリケーション向けに設計されている。 [1]

CoREグループは、次のことを念頭に置いてCoAPを設計した。

オーバーヘッドと解析の複雑さ。
URIおよびcontent-typeのサポート。
既知のCoAPサービスによって提供されるリソースのディスカバリーのサポート。
リソースへのシンプルなサブスクリプション、およびその結果のプッシュ通知。
max-ageに基づく単純なキャッシュ。

CoAPとHTTPのマッピングも定義されているため、HTTP経由でCoAPリソースに統一された方法でアクセスできるプロキシを構築できる。 ^[1]

CoAPの導入により、制約のあるデバイスや環境に適したオープン標準プロトコルの完全なネットワークスタックが利用可能になる。 ^[2]

アーキテクチャの観点から、CoAPサーバーは多くの場合センサーであるエンドノードにインストールされる。一方、CoAPクライアントはコントローラーにインストールされ、複数のエンドノードを管理する。

CoAPコード、オプション、およびコンテンツタイプの背景にあるレジストレーションは、 [2]示すIANAによって処理される。

メッセージフォーマット

トークン、オプション、およびペイロードを省略する場合、最小のCoAPメッセージの長さは4バイトである。 CoAPは、シンプルなバイナリベースヘッダー形式を使用して、リクエストとレスポンスの2つのメッセージタイプを使用する。ベースヘッダーの後に、最適化されたType-Length-Value形式のオプションが続く。CoAPはデフォルトでUDPにバインドされ、オプションでDTLSにバインドされ、高レベルの通信セキュリティを提供する。

パケットのヘッダーの後のバイトはすべてメッセージ本文と見なされる。メッセージ本文の長さは、データグラムの長さによって暗示される。 UDPにバインドされる場合は、メッセージ全体が単一のデータグラムに収まらなければならない。 RFC 4944で定義されている6LoWPANで使用する場合、メッセージは単一のIEEE 802.15.4フレームに収め、断片化を最小限に抑える。

CoAPヘッダー
オフセット	オクテット	0								1								2								3
オクテット	ビット	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
4	32	VER		タイプ		トークンの長さ				CoAP要求/応答コード								メッセージID
8	64	トークン（0-8バイト）
12	96	トークン（0-8バイト）
16	128	オプション（存在する場合）
20	160	1	1	1	1	1	1	1	1	ペイロード（存在する場合）

バージョン（VER）（2ビット）: CoAPバージョン番号を示す。
タイプ（2ビット）: このメッセージのタイプが確認可能（0）、非確認可能（1）、確認応答（2）、またはリセット（3）のいずれであるかを示す
トークン長（4ビット）: 可変長トークンフィールドの長さを示す。長さは0〜8バイト。
CoAP要求/応答コード（8ビット）

上位3ビットは、HTTPステータスコードのクラスに類似した「クラス」として知られる数値である。下位5ビットは、要求または応答に関する詳細を伝えるコードである。通常、コード全体はclass.codeの形式で通信する。最新のCoAP要求/応答コードは[3]にある。以下にいくつかの例を示す。

Method: 0.XX
Success : 2.XX
Client Error : 4.XX
Server Error : 5.XX
Signaling Codes : 7.XX

メッセージID（16ビット）: メッセージの重複を検出し、Acknowledgement / ResetタイプのメッセージをConfirmable / Non-confirmableタイプのメッセージにマッチするために使う。

次のマクロを使用して、Cヘッダーから情報を簡単に抽出できる。

#define COAP_HEADER_VERSION(data) ( (0xC0 & data[0])>>6  )
#define COAP_HEADER_TYPE(data)   ( (0x30 & data[0])>>4  )
#define COAP_HEADER_TKL(data)   ( (0x0F & data[0])>>0  )
#define COAP_HEADER_CLASS(data)  ( ((data[1]>>5)&0x07)  )
#define COAP_HEADER_CODE(data)   ( ((data[1]>>0)&0x1F)  )
#define COAP_HEADER_MID(data)   ( (data[2]<<8)|(data[3]) )

CoAPグループ通信

多くのCoAPアプリケーションドメインでは、各リソースを個別に指定するのではなく、複数のCoAPリソースをグループとして指定する機能（たとえばひとつの部屋の中にあるCoAP対応照明を、照明スイッチのトグルによって発生する1回のCoAPリクエストによって制御する）が不可欠である。このニーズに対処するために、IETFは実験的なRFCの形式でCoAPのオプションの拡張を開発した：CoAPのグループ通信 - RFC 7390 ^[3]この拡張は、すべてのグループメンバーにCoAP要求を配信するためにIPマルチキャストを使用する。マルチキャストを使用すると、リクエストをメンバーに配信するために必要なパケット数を減らすなどの利点がある。ただし、マルチキャストには、信頼性の低さやキャッシュに適さないという制約もある。マルチキャストの代わりにユニキャストを使用するの仲介者を持つことによる。クライアントは、グループリクエストを仲介者に送信する。仲介者は、個々のユニキャストリクエストをグループメンバーに送信し、それらから返信を収集し、集約された返信をクライアントに返信する。 ^[4]