CoAP

読み：こあっぷ　／　英語表記：Constrained Application Protocol

IoT機器のような、電力やメモリが限られた機器向けのアプリケーション層プロトコル。HTTPに似たやり取りを、軽いUDPの上で行う。

イマシルちゃんの解説

部屋の温度センサーや、畑の土の湿り気を測るセンサーみたいなIoT機器って、電池で何年も動かしたいんだ。
だから、たくさんの電気やメモリを使う重たい通信はできないんだよね。

そこで生まれたのがCoAP！
Webでおなじみの「GETでデータをもらう」「PUTで設定を変える」みたいなやり方はそのままに、
とっても小さく、軽くした通信ルールなんだ。

より深い解説

定義

CoAP（Constrained Application Protocol）は、IETFがRFC 7252（2014年）で標準化した、制約のある機器（constrained device）と制約のあるネットワーク向けのアプリケーション層プロトコルである。電池で動く小さなセンサーや、パケット損失が多く帯域の狭い無線ネットワーク（6LoWPANなど）での利用を想定している。

HTTPに似た仕組み

CoAPは、HTTPと同じRESTの考え方で設計されている。

サーバ上の資源（リソース）をURIで指定する（coap:// で始まる）
メソッドは GET、POST、PUT、DELETE の4つ
応答コードもHTTPに似ている（2.05 Content、4.04 Not Found など）

そのため、CoAPとHTTPを相互に変換するプロキシを置けば、IoT機器のデータを普通のWebの仕組みから扱える。

軽くするための工夫

工夫	内容
UDPの上で動く	TCPのような接続の確立や管理が不要。標準のポート番号は5683
小さなバイナリヘッダ	固定部分はわずか4バイト。HTTPのようなテキストのヘッダではない
必要なときだけ再送	下の「メッセージの種類」で、確認が必要なメッセージだけ再送する

メッセージの種類と信頼性

UDPには再送の仕組みがないため、CoAP自身が簡単な信頼性の仕組みを持つ。

種類	意味
CON（Confirmable）	確認が必要。相手からACKが返らなければ、間隔を広げながら再送する
NON（Non-confirmable）	確認不要。定期的なセンサー値のように、1回くらい欠けても困らないデータ向け
ACK（Acknowledgement）	CONを受け取ったことを知らせる
RST（Reset）	受け取ったが処理できないことを知らせる

この「大事なものだけ確認する」仕組みにより、パケット損失が起きやすいネットワークでも、少ない電力で必要な信頼性を確保できる。

その他の特徴

Observe：一度登録すると、値が変わるたびにサーバから通知が届く。定期的に問い合わせなくてよいので、電力を節約できる
マルチキャスト：UDPの上で動くので、複数の機器に一度に問い合わせられる
ブロック転送：大きなデータを小さなブロックに分けて送れる
セキュリティ：UDP向けのTLSであるDTLSで暗号化する（ポート番号5684）

MQTTとの違い

IoT向けのプロトコルとして、CoAPとよく比べられるのがMQTTである。

	CoAP	MQTT
通信の形	要求と応答（HTTPに似る）	発行と購読（Publish/Subscribe）
下位のプロトコル	UDP	TCP
仲介役	なくてよい	ブローカーが必須

メッセージIDとトークン

CoAPには、メッセージを対応付けるための値が2つある。役割の違いが午後でよく問われる。

値	対応付けるもの	使い道
メッセージID	CONとそれに対するACKなど、メッセージ同士	確認応答の対応付けと、重複の検出（同じメッセージIDのメッセージを再び受け取ったら、処理済みとして無視する）
トークン	要求と応答の内容	どの要求に対する応答のデータかを判断する。応答が別のメッセージで後から届いても対応付けられる

応答の返し方

方式	内容
ピギーバック	CONに対するACKに、応答のデータ（2.05 Contentなど）を載せて返す
別応答（セパレート）	すぐにデータを用意できないときは、まず空のACKだけを返し、後でデータを新しいCONで送る。どの要求の応答かはトークンで判断する

HTTP/1.1との比較

CoAPはUDPの上で動くため、データを送るたびにTCPのコネクションの確立（3ウェイハンドシェイク）と切断の処理が必要なHTTP/1.1に比べて、やり取りするIPパケットの数が少なく、通信の時間と機器の電力を節約できる。