2. Constrained Application Protocol (受限アプリケーションプロトコル)
CoAPの相互作用モデルは、HTTPのクライアント/サーバーモデルに似ています。しかし、マシン・ツー・マシンの相互作用では、通常、CoAP実装がクライアントとサーバーの両方の役割を果たします。CoAPリクエストはHTTPのそれと同等であり、クライアントによって送信され、サーバー上のリソース (URIによって識別される) に対するアクション (Method Codeを使用) を要求します。その後、サーバーはResponse Codeを含むレスポンスを送信します; このレスポンスにはリソース表現が含まれる場合があります。
HTTPとは異なり、CoAPはこれらのやり取りをUDPなどのデータグラム指向のトランスポート上で非同期に処理します。これは、オプションの信頼性 (指数バックオフを使用) をサポートするメッセージ層を使用して論理的に行われます。CoAPは4種類のメッセージタイプを定義しています: Confirmable (確認可能)、Non-confirmable (確認不要)、Acknowledgement (確認応答)、Reset (リセット)。これらのメッセージの一部に含まれるMethod CodeとResponse Codeにより、リクエストまたはレスポンスを運ぶことができます。4つのタイプのメッセージの基本的な交換は、リクエスト/レスポンスの相互作用とはやや直交しています; リクエストはConfirmableメッセージとNon-confirmableメッセージで運ばれ、レスポンスもこれらのメッセージで運ばれるか、Acknowledgementメッセージにピギーバックされることができます。
CoAPは論理的に2層アプローチを使用していると考えることができます。UDPと相互作用の非同期性を扱うために使用されるCoAPメッセージング層と、MethodおよびResponse Codeを使用したリクエスト/レスポンス相互作用です (図1参照)。しかし、CoAPは単一のプロトコルであり、メッセージングとリクエスト/レスポンスはCoAPヘッダーの機能に過ぎません。
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
図 1: CoAPの抽象的な階層化
2.1. Messaging Model (メッセージングモデル)
CoAPメッセージングモデルは、エンドポイント間でUDP上でメッセージを交換することに基づいています。
CoAPは、短い固定長のバイナリヘッダー (4バイト) を使用し、その後にコンパクトなバイナリオプションとペイロードが続く場合があります。このメッセージフォーマットは、リクエストとレスポンスで共有されます。CoAPメッセージフォーマットはSection 3で規定されています。各メッセージには、重複検出とオプションの信頼性のために使用されるMessage IDが含まれています。(Message IDはコンパクトです; その16ビットサイズにより、デフォルトのプロトコルパラメータで1つのエンドポイントから別のエンドポイントへ毎秒約250メッセージまで可能です。)
信頼性は、メッセージをConfirmable (CON) としてマークすることによって提供されます。Confirmableメッセージは、受信者が対応するエンドポイントから同じMessage ID (この例では0x7d34) を持つAcknowledgementメッセージ (ACK) を送信するまで、デフォルトのタイムアウトと再送信間の指数バックオフを使用して再送信されます; 図2を参照してください。受信者がConfirmableメッセージをまったく処理できない場合 (つまり、適切なエラーレスポンスを提供することさえできない場合)、Acknowledgement (ACK) の代わりにResetメッセージ (RST) で応答します。
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
図 2: 信頼性のあるメッセージ伝送
信頼性のある伝送を必要としないメッセージ (例えば、センサーデータストリームからの各単一測定値) は、Non-confirmableメッセージ (NON) として送信できます。これらは確認応答されませんが、重複検出のためのMessage IDを持っています (この例では0x01a0); 図3を参照してください。受信者がNon-confirmableメッセージを処理できない場合、Resetメッセージ (RST) で応答することができます。
Client Server
| |
| NON [0x01a0] |
+----------------->|
| |
図 3: 信頼性のないメッセージ伝送
CoAPメッセージの詳細については、Section 4を参照してください。
CoAPはUDP上で実行されるため、マルチキャストIP宛先アドレスの使用もサポートし、マルチキャストCoAPリクエストを可能にします。Section 8では、マルチキャストアドレスを使用したCoAPメッセージの適切な使用と、レスポンス輻輳を回避するための予防措置について説明します。
Section 9では、セキュリティなしから証明書ベースのセキュリティまで、CoAPのいくつかのセキュリティモードが定義されています。この文書は、プロトコルを保護するためのDTLSへのバインディングを規定しています; CoAPでのIPsecの使用については [IPsec-CoAP] で議論されています。
2.2. Request/Response Model (リクエスト/レスポンスモデル)
CoAPリクエストとレスポンスのセマンティクスは、それぞれMethod CodeまたはResponse Codeを含むCoAPメッセージで運ばれます。URIやペイロードメディアタイプなどのオプション (またはデフォルト) のリクエストおよびレスポンス情報は、CoAPオプションとして運ばれます。Tokenは、基盤となるメッセージから独立してレスポンスをリクエストにマッチングするために使用されます (Section 5.3)。(TokenはMessage IDとは別の概念であることに注意してください。)
リクエストはConfirmable (CON) またはNon-confirmable (NON) メッセージで運ばれ、すぐに利用可能な場合、Confirmableメッセージで運ばれたリクエストへのレスポンスは、結果として得られるAcknowledgement (ACK) メッセージで運ばれます。これはピギーバックレスポンスと呼ばれ、Section 5.2.1で詳述されています。(ピギーバックレスポンスを運ぶAcknowledgementメッセージが失われた場合、クライアントはリクエストを再送信するため、ピギーバックレスポンスを個別に確認する必要はありません。) ピギーバックレスポンスを伴う基本的なGETリクエストの2つの例が図4に示されています。1つは成功し、もう1つは4.04 (Not Found) レスポンスになります。
Client Server Client Server
| | | |
| CON [0xbc90] | | CON [0xbc91] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x72) |
+----------------->| +----------------->|
| | | |
| ACK [0xbc90] | | ACK [0xbc91] |
| 2.05 Content | | 4.04 Not Found |
| (Token 0x71) | | (Token 0x72) |
| "22.5 C" | | "Not found" |
|<-----------------+ |<-----------------+
| | | |
図 4: ピギーバックレスポンスを伴う2つのGETリクエスト
サーバーがConfirmableメッセージで運ばれたリクエストにすぐに応答できない場合、単に空のAcknowledgementメッセージで応答し、クライアントがリクエストの再送信を停止できるようにします。レスポンスの準備ができると、サーバーは新しいConfirmableメッセージでそれを送信します (これは順番にクライアントによって確認される必要があります)。これは「セパレートレスポンス」と呼ばれ、図5に示され、Section 5.2.2でより詳細に説明されています。
Client Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... 時間経過 ...
| |
| CON [0x23bb] |
| 2.05 Content |
| (Token 0x73) |
| "22.5 C" |
|<-----------------+
| |
| ACK [0x23bb] |
+----------------->|
| |
図 5: セパレートレスポンスを伴うGETリクエスト
リクエストがNon-confirmableメッセージで送信された場合、レスポンスは新しいNon-confirmableメッセージを使用して送信されますが、サーバーは代わりにConfirmableメッセージを送信することもできます。このタイプの交換は図6に示されています。
Client Server
| |
| NON [0x7a11] |
| GET /temperature |
| (Token 0x74) |
+----------------->|
| |
| NON [0x23bc] |
| 2.05 Content |
| (Token 0x74) |
| "22.5 C" |
|<-----------------+
| |
図 6: Non-confirmableメッセージで運ばれるリクエストとレスポンス
CoAPは、HTTPと同様の方法でGET、PUT、POST、DELETEメソッドを使用し、セマンティクスはSection 5.8で規定されています。(CoAPメソッドの詳細なセマンティクスは、HTTPメソッドのそれとは「ほとんど、しかし完全には似ていない」[HHGTTG] ことに注意してください: HTTPの経験から得られた直感は一般的によく適用されますが、実際に本仕様を読む価値がある十分な違いがあります。)
基本的な4つを超えるメソッドは、別の仕様でCoAPに追加できます。新しいメソッドは必ずしもリクエストとレスポンスをペアで使用する必要はありません。既存のメソッドでも、単一のリクエストが複数のレスポンスを生成する場合があります。例えば、マルチキャストリクエスト (Section 8) やObserveオプション [OBSERVE] を使用する場合などです。
サーバーでのURIサポートは、クライアントがすでにURIを解析し、ホスト、ポート、パス、クエリコンポーネントに分割し、効率のためにデフォルト値を利用するため、簡素化されています。Response Codeは、Section 5.9で定義されているように、いくつかのCoAP固有のコードが追加されたHTTPステータスコードの小さなサブセットに関連しています。
2.3. Intermediaries and Caching (中継者とキャッシング)
このプロトコルは、リクエストを効率的に満たすためにレスポンスのキャッシングをサポートしています。シンプルなキャッシングは、CoAPレスポンスで運ばれる鮮度と有効性情報を使用して有効化されます。キャッシュは、エンドポイントまたは中継者に配置できます。キャッシング機能はSection 5.6で規定されています。
プロキシングは、ネットワークトラフィックを制限する、パフォーマンスを向上させる、スリープ中のデバイスのリソースにアクセスする、セキュリティ上の理由など、いくつかの理由で制約されたネットワークで有用です。別のCoAPエンドポイントに代わってリクエストをプロキシすることは、プロトコルでサポートされています。プロキシを使用する場合、リクエストするリソースのURIはリクエストに含まれ、宛先IPアドレスはプロキシのアドレスに設定されます。プロキシ機能の詳細については、Section 5.7を参照してください。
CoAPはRESTアーキテクチャ [REST] に従って設計されており、したがってHTTPプロトコルと同様の機能を示すため、CoAPからHTTPへ、およびHTTPからCoAPへのマッピングは非常に簡単です。このようなマッピングは、CoAPを使用してHTTP RESTインターフェースを実現したり、HTTPとCoAP間で変換したりするために使用できます。この変換は、MethodまたはResponse Code、メディアタイプ、オプションを対応するHTTP機能に変換し、その逆も行うクロスプロトコルプロキシ ("cross-proxy") によって実行できます。Section 10では、HTTPマッピングの詳細を提供します。
2.4. Resource Discovery (リソースディスカバリ)
リソースディスカバリはマシン・ツー・マシンの相互作用にとって重要であり、Section 7で議論されているCoRE Link Format [RFC6690] を使用してサポートされています。