CoAP プロトコルとは？ 意味とアーキテクチャ

簡単な概要 

CoAP は従来のクライアントサーバー型 IoT プロトコルです。必要に応じてクライアントがウェブ転送の要求を送信でき、サーバも届いた要求に応答できます。つまり、IoT エコシステム内の各デバイスは CoAP を通じてのみ相互にやりとりを行います。

CoAP と HTTP は同様の動作手順ですが、CoAP は UDP を用いた非同期取引で機能を果たします。POST、GET、PUT、DELETE の呼び出しを利用するため、RPK および PSK 認定プロトコルとして動作する際の API セキュリティ はより高い水準となります。

CoAP は次の 4 種類の情報交換に対応しています:

1. 確認応答はイベントの完了または失敗を示します。
2. 確認可能なメッセージは、送信成功の確認が得られるまでタイムアウト後に再送されます。
3. リセットメッセージは空で、確認可能な性質を持ちます。
4. 非確認可能な情報は単に送信され、送信成功の保証や確認応答はありません。

CoAP の主な特徴は:

• 同じネットワーク内のデバイスで動作する。
• 一般のインターネット接続ノードやネットワーク接続デバイス間で双方向のデータ転送を可能にする。
• モバイルネットワークでの SMS 共有にも適している。
• 接続デバイスやセンサーを利用し、リソースに制約のあるインターネット連携アプリに適している。
• HTTP の変換が可能で、マルチキャストに対応し、コスト負担を最小限に抑える。
• ネットワーク内の機器同士の通信をサポートする。

CoAP アーキテクチャ

CoAP プロトコルアーキテクチャの基盤は WWW と制約環境の 2 つです。ここでは、サーバが CoAP と HTTP を用いた通信を監視し、プロキシデバイスが両者の間のギャップを埋め、通信を円滑にします。

CoAP は、HTTP クライアント（ここでは CoAP クライアントとも呼ばれる）が、リソース制約下でデータや情報のやりとりを行うことを可能にします。

このアーキテクチャを理解するためには、以下の重要な用語を知っておくことが大切です:

• エンドポイントは、ホストが把握しているノードである。
• クライアントは要求を送信し、受信した要求に応答する。
• サーバは要求を受け取り転送し、また処理した要求への応答メッセージも受け取って転送する。
• 送信者は元のメッセージを作成して送信する。
• 受信者はクライアントが送信、またはサーバが転送した情報を受け取る。

CoAP の機能

CoAP の主な役割は、制約のあるデバイスが関わる通信において HTTP のように機能することです。HTTP のギャップを埋め、アクチュエータやセンサーなどのデバイスがインターネット上でやりとりできるようにします。

このプロセスに関与するデバイスは、システムの一部としてデータを考慮しながら管理・制御されます。CoAP プロトコルは、低消費電力と少ない帯域幅で済むため、帯域が限られ混雑が激しい環境でも動作可能です。

極度の混雑や接続制限のあるネットワークは、TCP ベースのプロトコルが本来の役割を果たすには適していません。そんな中、CoAP は救済策としてウェブ転送を支援します。

衛星を用いた長距離のウェブ転送も、CoAP により完璧に実現できます。数十億のノードを持つネットワークにおいても、情報交換のために CoAP プロトコルが活用されています。

どのような機能や役割であっても、CoAP はデフォルトのセキュリティパラメータとして DTLS を使用し、128 ビット RSA 鍵に相当する最高レベルのセキュリティを提供します。

展開も簡単で手間がかからず、シンプルなアプリをゼロから実装することが可能です。

CoAP が適さないアプリ環境に対しては、さまざまなプラットフォーム向けに一般的な実装が提供されます。多くの CoAP の実装は非公開ですが、一部は MIT ライセンスなどのオープンソースライブラリで公開されています。

CoAP の特徴

CoAP プロトコルを他と差別化する特徴は以下の通りです。HTTP と多くの共通点があるため、開発者が使用する際の困難は最小限です。

CoAP は統合に適したプロトコルで、クロスプロトコルプロキシを用いるアプリと容易に連携できます。JSON、XML、CBOR など多様なデータ形式との統合もスムーズで、その過程でウェブクライアントにセンサーリソースへのアクセスが知られることはありません。

開発者は複数のペイロードを利用でき、最適なペイロードを自由に選択することが可能です。

成功する IoT デバイスやアプリは、数十億のノードを同時に活用する必要があります。CoAP は大量のノードに対応しつつ、オーバーヘッドを抑えるよう設計されており、多数のマイクロコントローラ上で最小限のリソースで動作します。RAM が 10KiB、コード領域が 100KiBあれば十分です。

CoAP が要求するリソースは少ないため、無駄を抑えられます。ウェブ転送に大掛かりなトランスポートスタックを必要とせず、メッセージ処理で使用するヘッダーやエンコーディングはコンパクトでリンク層での断片化も引き起こしません。一度に複数のサーバの機能をサポートします。

CoAP は、ノードの特性を把握するための包括的なリソースディレクトリを提供します。

CoAP は RFC 7252 に準拠しており、将来を見据えた設計と混雑制御への対応力を持っています。

CoAP レイヤー

プロトコルは以下の 2 つのレイヤーで動作します:

1. CoAP メッセージモデル

エンドポイント間で、確認可能（CON）または非確認可能（NON）形式の UDP 取引を実現します。各 CoAP メッセージには重複を防ぐための固有の ID が付与されます。

このレイヤーは、バイナリヘッダー、コンピュータオプション、ペイロードの 3 つの主要部分で構成されます。

前述のように、確認可能なテキストは信頼性が高く、迅速に作成でき、送信成功の確認（ACK）を受けるまで再送されます。

2. CoAP リクエスト/レスポンスモデル

このレイヤーは CON および NON メッセージの要求に対応し、要求の受理はサーバの状態に依存します。以下のケースがあります:

1. サーバがアイドル状態であれば、要求は直ちに処理され、CON の場合はクライアントが ACK を受け取ります。ACK が Token として渡され ID と異なる場合、要求とレスポンスを適切に対応付ける必要があります。
2. 処理に遅れが生じる場合は、ACK が空のメッセージとして送信され、その後順次要求が処理され、クライアントには新たな CON が送られます。

リクエスト/レスポンスモデルの主な特徴は以下の通りです:

• CoAP のリクエストやレスポンスコードは HTTP と同様ですが、バイナリ形式（0～8 バイトの Token）です。
• 呼び出しに用いるリクエストメソッド（GET、PUT、POST、DELETE）が定義されています。
• CON のレスポンスは ACK メッセージに含めるか、CON/NON として転送されます。

CoAP と MQTT

両者には大きな類似点があるため、同一視しても不自然ではありません。どちらも、少ないネットワークパケットで省エネ、低記憶域消費、長いバッテリ寿命を実現するために IoT デバイスで利用されます。

CoAP と MQTT は、以下の点で異なります:

‍

REST プロトコルと CoAP

RESTful プロトコルとは、REpresentational State Transfer の略で、HTTP 上で動作します。この場合、すべてのエンティティがリソースとして扱われ、共通のインターフェースからアクセス可能です。REST はウェブ技術によって大きく支えられていますが、HTTP のみに依存するものではありません。

IoT アプリ向けとして、CoAP は軽量な RESTful 方言と呼ばれることが多く、CPU リソースやネットワーク帯域の使用が少なくて済みます。HTTP での IoT デバイス開発は数十億のノードを含むため困難ですが、CoAP はその性質、アーキテクチャ、動作によりこれを十分に実現できます。