メインコンテンツまでスキップ

2. 制約付きアプリケーションプロトコル

CoAPの相互作用モデルは、HTTPのクライアント/サーバーモデルに似ています。ただし、マシンツーマシンの相互作用では、通常、CoAP実装がクライアントとサーバーの両方の役割を果たします。CoAPリクエストはHTTPのリクエストと同等であり、クライアントによって送信され、サーバー上のリソース（URIによって識別される）に対するアクション（メソッドコードを使用）を要求します。その後、サーバーはレスポンスコードとともにレスポンスを送信します。このレスポンスには、リソース表現が含まれる場合があります。

HTTPとは異なり、CoAPはUDPなどのデータグラム指向トランスポート上でこれらのやり取りを非同期的に処理します。これは、オプションの信頼性（指数バックオフ付き）をサポートするメッセージのレイヤーを使用して論理的に行われます。CoAPは、Confirmable（確認可能）、Non-confirmable（確認不要）、Acknowledgement（確認応答）、Reset（リセット）の4種類のメッセージを定義しています。これらのメッセージの一部に含まれるメソッドコードとレスポンスコードにより、それらはリクエストまたはレスポンスを運びます。4種類のメッセージの基本的な交換は、リクエスト/レスポンスの相互作用とは多少直交しています。リクエストはConfirmableおよびNon-confirmableメッセージで運ぶことができ、レスポンスもこれらで運ぶことができるほか、Acknowledgementメッセージにピギーバックすることもできます。

CoAPは論理的に2層アプローチを使用していると考えることができます。UDPと相互作用の非同期性を処理するために使用されるCoAPメッセージング層と、メソッドおよびレスポンスコードを使用するリクエスト/レスポンス相互作用です（図1を参照）。ただし、CoAPは単一のプロトコルであり、メッセージングとリクエスト/レスポンスはCoAPヘッダーの単なる機能です。

                        +----------------------+
                        |    アプリケーション    |
                        +----------------------+
                        +----------------------+  \
                        | リクエスト/レスポンス |  |
                        |----------------------|  | CoAP
                        |      メッセージ       |  |
                        +----------------------+  /
                        +----------------------+
                        |          UDP         |
                        +----------------------+

                    図 1: CoAPの抽象レイヤリング

2.1. メッセージングモデル​

CoAPメッセージングモデルは、エンドポイント間でのUDP上のメッセージ交換に基づいています。

CoAPは、コンパクトなバイナリオプションとペイロードが続く可能性のある短い固定長バイナリヘッダー（4バイト）を使用します。このメッセージ形式は、リクエストとレスポンスで共有されます。CoAPメッセージ形式はセクション3で規定されています。各メッセージには、重複を検出し、オプションの信頼性のために使用されるメッセージIDが含まれています。（メッセージIDはコンパクトです。その16ビットサイズにより、デフォルトのプロトコルパラメータを使用して、あるエンドポイントから別のエンドポイントへ毎秒最大約250メッセージが可能になります。）

信頼性は、メッセージをConfirmable（CON）としてマークすることによって提供されます。Confirmableメッセージは、受信者が対応するエンドポイントから同じメッセージID（この例では0x7d34）を持つAcknowledgementメッセージ（ACK）を送信するまで、デフォルトのタイムアウトと再送信間の指数バックオフを使用して再送信されます（図2を参照）。受信者がConfirmableメッセージをまったく処理できない場合（つまり、適切なエラー応答さえ提供できない場合）、Acknowledgement（ACK）の代わりにResetメッセージ（RST）で応答します。

                        クライアント          サーバー
                           |                  |
                           |   CON [0x7d34]   |
                           +----------------->|
                           |                  |
                           |   ACK [0x7d34]   |
                           |<-----------------+
                           |                  |

                  図 2: 信頼性の高いメッセージ送信

信頼性の高い送信を必要としないメッセージ（たとえば、センサーデータのストリームからの各単一測定値）は、Non-confirmableメッセージ（NON）として送信できます。これらは確認されませんが、重複検出用のメッセージID（この例では0x01a0）は引き続き持っています（図3を参照）。受信者がNon-confirmableメッセージを処理できない場合、Resetメッセージ（RST）で応答する場合があります。

                        クライアント          サーバー
                           |                  |
                           |   NON [0x01a0]   |
                           +----------------->|
                           |                  |

                 図 3: 信頼性のないメッセージ送信

CoAPメッセージの詳細については、セクション4を参照してください。

CoAPはUDP上で実行されるため、マルチキャストIP宛先アドレスの使用もサポートし、マルチキャストCoAPリクエストを可能にします。セクション8では、マルチキャストアドレスを使用したCoAPメッセージの適切な使用と、レスポンスの輻輳を回避するための予防措置について説明します。

セクション9では、セキュリティなしから証明書ベースのセキュリティまで、CoAPのいくつかのセキュリティモードが定義されています。このドキュメントでは、プロトコルを保護するためのDTLSへのバインディングを指定しています。CoAPでのIPsecの使用については、[IPsec-CoAP]で説明されています。

2.2. リクエスト/レスポンスモデル​

CoAPリクエストおよびレスポンスのセマンティクスはCoAPメッセージで運ばれ、それぞれメソッドコードまたはレスポンスコードが含まれます。URIやペイロードメディアタイプなどのオプション（またはデフォルト）のリクエストおよびレスポンス情報は、CoAPオプションとして運ばれます。トークンは、基礎となるメッセージとは無関係にレスポンスをリクエストに一致させるために使用されます（セクション5.3）。（トークンはメッセージIDとは別の概念であることに注意してください。）

リクエストはConfirmable（CON）またはNon-confirmable（NON）メッセージで運ばれ、すぐに利用可能な場合、Confirmableメッセージで運ばれたリクエストへのレスポンスは、結果のAcknowledgement（ACK）メッセージで運ばれます。これはピギーバック応答と呼ばれ、セクション5.2.1で詳しく説明されています。（クライアントは、ピギーバック応答を運ぶAcknowledgementメッセージが失われた場合にリクエストを再送信するため、ピギーバック応答を個別に確認する必要はありません。）ピギーバック応答を伴う基本的なGETリクエストの2つの例を図4に示します。1つは成功し、もう1つは4.04（Not Found）レスポンスになります。

        クライアント          サーバー     クライアント          サーバー
           |                  |             |                  |
           |   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に示され、セクション5.2.2で詳しく説明されています。

                        クライアント          サーバー
                           |                  |
                           |   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に示します。

                        クライアント          サーバー
                           |                  |
                           |   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メソッドを使用し、セマンティクスはセクション5.8で規定されています。（CoAPメソッドの詳細なセマンティクスは、HTTPメソッドのそれと「ほとんど、しかし完全には異ならない」[HHGTTG]ことに注意してください。HTTPの経験から得られる直感は一般によく当てはまりますが、実際に現在の仕様を読む価値があるだけの十分な違いがあります。）

基本的な4つ以外のメソッドは、別の仕様でCoAPに追加できます。新しいメソッドは、必ずしもリクエストとレスポンスをペアで使用する必要はありません。既存のメソッドであっても、単一のリクエストが複数のレスポンスを生成する場合があります（例：マルチキャストリクエスト（セクション8）やObserveオプション[OBSERVE]を使用する場合）。

サーバーでのURIサポートは、クライアントがすでにURIを解析し、ホスト、ポート、パス、およびクエリコンポーネントに分割し、効率のためにデフォルト値を使用するため、簡素化されています。レスポンスコードは、セクション5.9で定義されているように、いくつかのCoAP固有のコードが追加されたHTTPステータスコードの小さなサブセットに関連しています。

2.3. 仲介者とキャッシング​

プロトコルは、リクエストを効率的に満たすためにレスポンスのキャッシュをサポートしています。単純なキャッシュは、CoAPレスポンスで運ばれる鮮度と有効性の情報を使用して有効になります。キャッシュは、エンドポイントまたは仲介者に配置できます。キャッシュ機能はセクション5.6で規定されています。

プロキシは、ネットワークトラフィックの制限、パフォーマンスの向上、スリープ状態のデバイスのリソースへのアクセス、セキュリティ上の理由など、いくつかの理由で制約のあるネットワークで役立ちます。別のCoAPエンドポイントに代わってリクエストをプロキシすることは、プロトコルでサポートされています。プロキシを使用する場合、リクエストするリソースのURIはリクエストに含まれますが、宛先IPアドレスはプロキシのアドレスに設定されます。プロキシ機能の詳細については、セクション5.7を参照してください。

CoAPはRESTアーキテクチャ[REST]に従って設計されており、HTTPプロトコルの機能と同様の機能を示すため、CoAPからHTTPへ、およびHTTPからCoAPへのマッピングは非常に簡単です。このようなマッピングを使用して、CoAPを使用してHTTP RESTインターフェイスを実現したり、HTTPとCoAPの間で変換したりできます。この変換は、メソッドまたはレスポンスコード、メディアタイプ、およびオプションを対応するHTTP機能に変換するクロスプロトコルプロキシ（「クロスプロキシ」）によって実行できます。セクション10では、HTTPマッピングの詳細について説明します。

2.4. リソース検出​

リソース検出はマシンツーマシンの相互作用にとって重要であり、セクション7で説明されているようにCoRE Link Format [RFC6690]を使用してサポートされています。

に最終更新