すべてのプロダクト
Search
ドキュメントセンター

Edge Security Acceleration:カスタムキャッシュキーの作成

最終更新日:Aug 09, 2024

URI、リクエストパラメーター、HTTPリクエストヘッダー、カスタム変数など、HTTPリクエストのさまざまな部分に基づいてキャッシュキーを生成するルールを作成できます。 この機能を使用して、同じリソースのURLを同じキャッシュキーに変換することもできます。 これにより、キャッシュヒット率が向上し、オリジンサーバーにリダイレクトされるリクエストの数、応答時間、および帯域幅の使用量が削減されます。

シナリオ

重要

カスタムキャッシュキーは、オリジンURLを変更しません。 カスタムキャッシュキーは、リクエスト内のキャッシュ識別子のみを変更します。 配信元サーバーにリダイレクトされ、クライアントによって送信されるリクエストは、同じコンテンツを宛先とします。

キャッシュキーは、POP (point of presence) にキャッシュされたファイルの一意のIDです。 POPにキャッシュされる各ファイルにはキャッシュキーがあります。 既定では、ファイルのキャッシュキーは、ファイルを取得するために送信されるリクエストのURLです。 URLはパラメータを含む。

シナリオ1

要求内のURLは、複雑なパラメータを含み得る。 したがって、URLパラメータのバリエーションにより、リクエストが同じコンテンツを取得するために送信された場合でも、POPは、リクエストが異なるリソースを取得するために送信され、すべてのリクエストのリソースをキャッシュすることを考慮します。 その結果、多数のリクエストがオリジンサーバーにリダイレクトされます。 图一

リクエストの種類にキャッシュキーを設定して、オリジンサーバーにリダイレクトされるリクエストの数を減らすことができます。图二

シナリオ2

リクエストには同じURLが含まれています。 この場合、DCDNは、リクエストが同じリソースを取得するために送信されたと見なします。 しかし、実際には、クライアントOSは、リクエスト内のHTTPヘッダのクライアントフィールドで指定される。 要求は、異なるファイルを取り出すために送信され得る。 场景一

2つのキャッシュキーを作成し、クライアントフィールドの値をキャッシュキーに含めてから、キャッシュキーを使用してリクエストを区別できます。 场景二

手順

  1. DCDNコンソール

  2. 左側のナビゲーションウィンドウで、ドメイン名.

  3. On theドメイン名ページで、管理するドメイン名を見つけて、設定.

  4. ドメイン名の左側のナビゲーションツリーで、キャッシング.

  5. On theカスタムキャッシュキータブで、キャッシュキーを設定します。

    説明

    キャッシュキーのURI、パラメーターアクション、HTTPヘッダー、およびカスタム変数を変更できます。 キャッシュキーは、URI、パラメーターアクション、HTTPヘッダー、およびカスタム変数で構成されます。

    自定义Cachekey

    パラメーター

    説明

    URI

    • ソースURI。スラッシュ (/) で始まります。 ソースURIには、http:// またはドメイン名は含まれません。 Perl互換正規表現 (PCRE) は、ソースURIでサポートされています。

    • 最終URI。スラッシュ (/) で始まります。 最終的なURIには、http:// またはドメイン名は含まれません。 最終URIはキャッシュキーの一部です。

    パラメーター操作

    パラメータアクションはリクエストURLに含まれています。 追加、削除、変更、および予約アクションを指定できます。 指定されたアクションが実行されると、結果はキャッシュキーの一部になります。

    HTTPヘッダー

    HTTPヘッダーはユーザーリクエストに含まれています。 複数のHTTPヘッダー値をキャッシュキーに追加できます。

    カスタム変数

    正規表現を使用して、リクエストパラメーター、HTTPヘッダー、Cookie、URIからフィールドを抽出し、抽出したフィールドをキャッシュキーに追加できます。

  6. クリックOK.

サンプル設定

URI

URI http://aliyundoc.com/a/b/image.jpg および http://aliyundoc.com/a/b/c/image.jpg を宛先とする要求は、同じファイルを要求すると見なされます。 ファイルのキャッシュキーを http://aliyundoc.com/c/image.jpg します。 URI

パラメーター操作

http://aliyundoc.com/a/b/image.jpg?delete_par=1&modify_par=1 向けのリクエストの場合、URIにadd_par=1が追加され、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です。 HTTP Header

カスタム変数

例 1

変数名はlanguage、ソースはRequest Header、ソースフィールドはAccept-Language、マッチングルールは ([% w]+) 、([% w]+) 、変数式は $1aaです。 自定义变量

http://aliyundoc.com/a/b/image.jpg 宛てのリクエストにAccept-Language=en,chというヘッダーが含まれている場合、マッチングルールでは、式の値en$1が割り当てられます。 文字列aaは、変数式の末尾に追加されます。 この場合、エイリアスlanguageを持つenaa変数が生成されます。 そして、最終キャッシュキーを http://aliyundoc.com/a/b/image.jpgenaa する。

説明

変数式の $nは、n番目の括弧で囲まれた一致するコンテンツを指定します。 例1では、Accept-Language=en,chであり、マッチングルールは ([% w]+),([% w]+) です。 したがって、$1=enおよび $2=chである。

例 2

変数名は期限切れ、ソースはRequest Cookie、ソースフィールドはa、照合ルールは [% w]+ (.*) 、変数式は $1です。 自定义变量

http://aliyundoc.com/a/b/image.jpg 宛てのリクエストにヘッダーCookie a=expired_time:12635187が含まれている場合、マッチングルールは変数式で12635187$1に割り当てます。 変数のエイリアスが期限切れです。 そして、最終キャッシュキーを http://aliyundoc.com/a/b/image.jpg12635187 する。

例3

URIルールとカスタム変数を同時に設定します。

  • URI

    すべてのリクエストURIの /abc/.*/abc/abcに変換します。 示例三

  • カスタム変数

    変数名はtestname、ソースはPath、照合ルールは /abc/xyz/(.*) 、変数式は $1です。 示例三

    リクエストが http://aliyundoc.com/abc/xyz/abc/image.jpg 向けの場合、URLはURIルールに基づいて http://aliyundoc.com/abc/image.jpg に変換されます。 URLは、カスタム変数ルールに従って /abc/xyz/(.*) と一致します。 この場合、$1に値abcが割り当てられ、キャッシュキーに追加されます。 最終的なキャッシュキーが http://aliyundoc.com/abc/image.jpgabc される。 複雑なキャッシュロジックをサポートするために、2つのルールが同時に適用されます。

    キャッシュキーのカスタム変数が一致しない場合、変数式 $1はキャッシュキーに追加されません。