13 Caching (キャッシング)

13 Caching (キャッシング)

HTTP ではレスポンス-リクエストの対がキャッシュされる。RTSP はこの点で大きく異なる。DESCRIBE が返すプレゼンテーション記述または ANNOUNCE に含まれるものを除き, レスポンスはキャッシュできない。 (DESCRIBE と GET_PARAMETER 以外のレスポンスはデータを返さないため, これらのリクエストではキャッシュは実質的に問題にならない。) しかし, 通常 RTSP に対して帯域外で配送される連続メディアデータとセッション記述の双方をキャッシュすることが望ましい。

SETUP または PLAY リクエストを受信すると, プロキシは連続メディアコンテンツとその記述の最新コピーを保持しているか確認する。それぞれ SETUP または DESCRIBE を発行し Last-Modified ヘッダーをキャッシュ済みコピーと比較して最新か判断できる。最新でなければ SETUP のトランスポートパラメータを適宜変更しリクエストをオリジンサーバーへ転送する。その後の PLAY や PAUSE などの制御コマンドはプロキシを変更されず通過する。プロキシは連続メディアデータをクライアントへ配送し, 同時に後で再利用するためのローカルコピーを作成してもよい。キャッシュに許される正確な動作はセクション 12.8 のキャッシュ応答ディレクティブで与えられる。キャッシュは現在リクエスタにストリームを配信中なら DESCRIBE リクエストに必ず答えなければならない。ストリーム記述の低レベル詳細がオリジンサーバーで変わっている可能性があるためである。

RTSP キャッシュは HTTP キャッシュと異なり「カットスルー」型である。オリジンサーバーからリソース全体を取得するのではなく, クライアントへ向かう途中のストリーミングデータを単にコピーする。したがって追加の遅延を導入しない。

クライアントにとって RTSP プロキシキャッシュは通常のメディアサーバーのように見え, メディアオリジンサーバーにはクライアントのように見える。HTTP キャッシュがキャッシュするオブジェクトのコンテンツタイプやコンテンツ言語などを保存しなければならないのと同様, メディアキャッシュはプレゼンテーション記述を保存しなければならない。典型的には, キャッシュからクライアントへのデータ配送とは独立であるため, プレゼンテーション記述からすべてのトランスポート参照 (マルチキャスト情報) を除去する。エンコーディングに関する情報は同じままである。キャッシュがキャッシュ済みメディアデータを変換できる場合は, 提供できるエンコーディングの可能性をすべて含む新しいプレゼンテーション記述を作成する。