URI、リクエストパラメーター、HTTP リクエストヘッダー、カスタム変数など、HTTP リクエストのさまざまな部分に基づいてキャッシュキーを生成するルールを作成できます。 また、この機能を使用して、同じリソースの URL を同じキャッシュキーに変換することもできます。 これにより、キャッシュヒット率が向上し、オリジンサーバーにリダイレクトされるリクエストの数、応答時間、および帯域幅の使用量が削減されます。
シナリオ
カスタムキャッシュキーは、オリジン URL を変更しません。 カスタムキャッシュキーは、リクエスト内のキャッシュ識別子のみを変更します。 オリジンサーバーにリダイレクトされ、クライアントによって送信されるリクエストは、同じコンテンツ宛てです。
キャッシュキーは、配信拠点（POP）にキャッシュされたファイルの一意の ID です。 POP にキャッシュされている各ファイルには、キャッシュキーがあります。 デフォルトでは、ファイルのキャッシュキーは、ファイルを取得するために送信されるリクエスト内の URL です。 URL にはパラメーターが含まれています。
シナリオ 1
リクエスト内の URL には、複雑なパラメーターが含まれている場合があります。 そのため、リクエストが同じコンテンツを取得するために送信された場合でも、URL パラメーターのバリエーションにより、POP はリクエストが異なるリソースを取得するために送信されたと見なし、すべてのリクエストのリソースをキャッシュします。 その結果、多数のリクエストがオリジンサーバーにリダイレクトされます。
ある種のリクエストのキャッシュキーを設定して、オリジンサーバーにリダイレクトされるリクエストの数を減らすことができます。
シナリオ 2
リクエストには同じ URL が含まれています。 この場合、DCDN はリクエストが同じリソースを取得するために送信されたと見なします。 ただし、実際には、クライアント OS はリクエストの HTTP ヘッダーのクライアントフィールドで指定されています。 リクエストは異なるファイルを取得するために送信される場合があります。
2 つのキャッシュキーを作成し、キャッシュキーにクライアントフィールドの値を含めて、リクエストを区別するためにキャッシュキーを使用できます。
手順
DCDN コンソール にログインします。
左側のナビゲーションウィンドウで、ドメイン名 をクリックします。
ドメイン名 ページで、管理するドメイン名を見つけ、設定 をクリックします。
ドメイン名の左側のナビゲーションツリーで、キャッシング をクリックします。
[カスタムキャッシュキー] タブで、キャッシュキーを構成します。
説明キャッシュキー内の URI、パラメーター操作、HTTP ヘッダー、およびカスタム変数を変更できます。キャッシュキーは、URI、パラメーター操作、HTTP ヘッダー、およびカスタム変数で構成されます。
パラメーター
説明
[ルール条件]
ルール条件は、リクエスト内のパラメーターを識別して、構成がリクエストに適用されるかどうかを判断できます。
条件を使用しない
[ルールエンジン] で構成済みのルール条件を選択します。
[URI]
[ソース URI]。スラッシュ (/) で始まります。ソース URI には http:// またはドメイン名は含まれません。Perl Compatible Regular Expressions（PCRE）がソース URI でサポートされています。
[最終 URI]。スラッシュ (/) で始まります。最終 URI には http:// またはドメイン名は含まれません。最終 URI はキャッシュキーの一部です。
[パラメーター操作]
パラメーター操作はリクエスト URL に含まれています。追加、削除、変更、および予約の操作を指定できます。指定された操作が実行された後、結果はキャッシュキーの一部になります。
[HTTP ヘッダー]
HTTP ヘッダーはユーザーリクエストに含まれています。キャッシュキーに複数の HTTP ヘッダー値を追加できます。
[カスタム変数]
正規表現を使用して、リクエストパラメーター、HTTP ヘッダー、Cookie、および URI からフィールドを抽出し、抽出されたフィールドをキャッシュキーに追加できます。
OK をクリックします。
構成例
URI
URI http://aliyundoc.com/a/b/image.jpg および http://aliyundoc.com/a/b/c/image.jpg 宛てのリクエストは、同じファイルをリクエストしていると見なされます。 ファイルのキャッシュキーは http://aliyundoc.com/c/image.jpg です。
パラメーター操作
http://aliyundoc.com/a/b/image.jpg?delete_par=1&modify_par=1 宛てのリクエストの場合、add_par=1 が URI に追加され、delete_par が削除され、modify_par の値が 2 に変更されます。 この場合、最終 URI は http://aliyundoc.com/a/b/image.jpg?modify_par=2&add_par=1 です。
同じ変数に適用される操作の優先順位は、追加 > 削除 > 保持のみ > 変更です。
HTTP ヘッダー
この例では、HTTP ヘッダーの User-Agent フィールドと Accept-Language フィールドの値がキャッシュキーに含まれています。 たとえば、http://aliyundoc.com/a/b/image.jpg 宛てのリクエストに User-Agent=Mozilla/5.0 (Linux; X11) ヘッダーと Accept-Language=en ヘッダーが含まれている場合、リクエストのキャッシュキーは http://aliyundoc.com/a/b/image.jpgMozilla/5.0(Linux;X11)en です。
カスタム変数
例 1
変数名は language、ソースは リクエストヘッダー、ソースフィールドは Accept-Language、一致ルールは ([%w]+),([%w]+)、変数式は $1aa です。
http://aliyundoc.com/a/b/image.jpg 宛てのリクエストに Accept-Language=en,ch ヘッダーが含まれている場合、一致ルールによって式の $1 に値 en が割り当てられます。 文字列 aa が変数式の末尾に追加されます。 この場合、エイリアス language を持つ変数 enaa が生成されます。 その後、最終キャッシュキーは http://aliyundoc.com/a/b/image.jpgenaa になります。
変数式の $n は、n 番目の括弧で囲まれた一致コンテンツを指定します。 例 1 では、Accept-Language=en,ch で、一致ルールは ([%w]+),([%w]+) です。 したがって、$1=en および $2=ch です。
例 2
変数名は expired、ソースは リクエスト Cookie、ソースフィールドは a、一致ルールは [%w]+:(.*)、変数式は $1 です。
http://aliyundoc.com/a/b/image.jpg 宛てのリクエストに Cookie a=expired_time:12635187 ヘッダーが含まれている場合、一致ルールによって変数式の $1 に 12635187 が割り当てられます。 変数のエイリアスは expired です。 その後、最終キャッシュキーは http://aliyundoc.com/a/b/image.jpg12635187 になります。
例 3
URI ルールとカスタム変数を同時に構成します。
URI
すべてのリクエスト URI の
/abc/.*/abcを/abcに変換します。
カスタム変数
変数名は
testname、ソースはパス、一致ルールは/abc/xyz/(.*)、変数式は$1です。
リクエストが
http://aliyundoc.com/abc/xyz/abc/image.jpg宛ての場合、URI ルールに基づいて URL はhttp://aliyundoc.com/abc/image.jpgに変換されます。 URL は、カスタム変数ルールに従って/abc/xyz/(.*)と一致します。 この場合、$1に値abcが割り当てられ、キャッシュキーに追加されます。 最終キャッシュキーはhttp://aliyundoc.com/abc/image.jpgabcです。 複雑なキャッシングロジックをサポートするために、2 つのルールが同時に適用されます。キャッシュキーのカスタム変数が一致しない場合、変数式
$1はキャッシュキーに追加されません。