ポイントオブプレゼンス (POP) がオリジンサーバーからリソースを取得すると、オリジンサーバーはPOPにHTTPステータスコードを返します。 Alibaba Cloud CDN では、HTTPステータスコードのキャッシュルールを作成できます。 クライアントが同じリソースを要求すると、POPはリクエストをオリジンサーバーにリダイレクトする代わりにステータスコードを返します。 配信元サーバーの負荷が軽減されます。 キャッシュされたHTTPステータスコードの有効期限が切れると、コードをトリガーするリクエストはオリジンサーバーにリダイレクトされます。
シナリオ
TTL値は、オリジンサーバーがエラーコードを返した場合にPOPのキャッシュ動作を制御するために使用されます。
通常、リクエストされたリソースがオリジンサーバーから取得された場合、HTTP 2xxステータスコードが返され、リソースは、「既定のキャッシュルールとキャッシュルールの優先順位」で説明されているキャッシュルールに基づいてPOPにキャッシュされます。 HTTP 2xx以外のステータスコードなどのHTTPステータスコードをPOPに返すことでオリジンサーバーがリクエストに応答できず、オリジンサーバーがすべてのリクエストに応答しない場合は、POP上のコードをキャッシュするHTTPステータスコードのTTLを指定できます。 このようにして、POPはHTTPステータスコードをクライアントに直接返すことができます。 これにより、オリジンサーバーの負荷が軽減されます。
例
ファイルAはオリジンサーバーから削除され、POPにキャッシュされませんが、クライアントはファイルAにアクセスしようとします。ファイルAに対するすべてのリクエストはオリジンサーバーにリダイレクトされ、オリジンサーバーはリクエストごとにHTTP 4xxステータスコードを返す必要があります。 これにより、オリジンサーバーの負荷が増加します。 HTTP 4xxステータスコードのキャッシュルールを作成すると、最初のリクエストに対して返されたHTTP 4xxステータスコードがPOPにキャッシュされます。 HTTPステータスコードのTTLが終了する前に、POPはHTTP 4xxステータスコードを後続のリクエストに返します。
HTTPステータスコードのキャッシュルール
次の図は、HTTPステータスコード204、305、400、403、404、405、414、500、501、502、503、および504のキャッシュルールを示しています。
リクエストがrange origin fetch機能によって処理される場合、次のキャッシュルールが適用されます。
204、305、400、403、404、405、414、500、200、206、503、504など、501および502以外のHTTPステータスコードの場合、リソースはキャッシュされません。
HTTPステータスコード200および206の場合、リソースは、既定のキャッシュルールおよびキャッシュルールの優先順位に記載されているキャッシュルールに基づいてキャッシュされます。
HTTP 5xxステータスコードにより、POPはキャッシュされたファイルチャンクを削除できます。 オリジンフェッチがタイムアウトした場合、ファイルチャンクは削除されません。
説明範囲オリジンフェッチ機能を有効にすると、オリジンサーバーは大きなファイルをチャンクに分割してから、ファイルがPOPに返されます。 たとえば、ファイルは10個のチャンクに分割され、そのうち5個がPOPにキャッシュされます。 ユーザーが6番目のチャンクを要求すると、オリジンサーバーはHTTP 5xxステータスコードを返し、POPはキャッシュされている5つのチャンクを削除します。
[range origin fetch] に記載されているレンジオリジンフェッチ機能によってリクエストが処理されない場合、次のキャッシュルールが適用されます。
オリジンサーバーが
Set-Cookieレスポンスヘッダーを返した場合、POPは取得したリソースをキャッシュしません。オリジンサーバーが
Set-Cookieレスポンスヘッダーを返さない場合、取得されたリソースはAlibaba Cloud CDNコンソールで設定されたキャッシュルールに基づいてキャッシュされます。 詳細については、「キャッシュルールの適用方法」をご参照ください。オリジンサーバーが
Set-Cookieレスポンスヘッダーを返さず、Alibaba Cloud CDNコンソールでキャッシュルールが設定されていない場合、取得したリソースはPragma、cache-Control、またはExpiresレスポンスヘッダーのディレクティブに基づいて処理されます。オリジンサーバーが
Set-Cookie、Pragma、Cache-Control、またはExpiresレスポンスヘッダーを返さず、Alibaba Cloud CDNコンソールでキャッシュルールが設定されていない場合、取得したリソースは1秒間キャッシュされます。
HTTP 303、304、401、407、600、601のステータスコードでは、リソースはキャッシュされません。
キャッシュルールの適用方法
複数のキャッシュルールを設定できます。 リクエストが複数のキャッシュルールに一致する場合、ルールの1つのみが適用されます。 ルールは次の優先順位で適用されます。
ルールの優先順位:
ルールは、そのタイプに基づいて優先順位が付けられる。 ファイル名拡張子用に構成されたキャッシュルールは、ディレクトリ用に構成されたキャッシュルールよりも優先度が高くなります。 同じタイプのルールは、作成時間に基づいて優先順位が付けられます。 より早い作成時間を有するルールは、より高い優先度を有する。
さまざまな種類のルール: ファイル名拡張子のルール> ディレクトリのルール。
たとえば、リクエストは2つのルールに一致し、どちらのルールもHTTP 404ステータスコードを使用します。 一方のルールはファイル名拡張子に設定され、もう一方のルールはディレクトリに設定されます。 HTTP 404ステータスコードは、ファイル名拡張子に対して設定されたルールに基づいて期限切れになります。 詳細については、「設定例」をご参照ください。
同じタイプのルール: 以前のルール> 後のルール
ルールは作成時の順にコンソールに表示されます。 たとえば、リクエストは2つのルールに一致し、どちらのルールもHTTP 404ステータスコードを使用します。 どちらのルールも、ファイル名拡張子またはディレクトリ用に設定されています。 この場合、HTTP 404のステータスコードは、以前のルールに基づいて期限切れになります。 詳細については、「設定例」をご参照ください。
手順
Alibaba Cloud CDNコンソール
左側のナビゲーションウィンドウで、ドメイン名.
[ドメイン名] ページで、管理するドメイン名を見つけて、アクション 列の 管理 をクリックします。
ドメイン名の左側のナビゲーションツリーで、キャッシュ設定.
HTTP ステータスコード有効期限タブをクリックします。
追加 をクリックし、パラメーターを設定します。 下表にパラメーターを示します。
パラメーター
説明
タイプ
ビジネス要件に基づいて、ディレクトリ または ファイル拡張子 を選択します。
説明ファイル名拡張子用に構成されたキャッシュルールは、ディレクトリ用に構成されたキャッシュルールよりも優先度が高くなります。 詳細については、「HTTPステータスコードのキャッシュルール」をご参照ください。
アドレス
[ディレクトリ] を選択した場合、次の制限事項に注意してください。
各ルールに追加できるディレクトリは1つだけです。
フルパスを入力できます。 パスはスラッシュ (/) で始まる必要があります。 例: /directory/aaa
[ファイル拡張子] を選択した場合、次のルールに注意してください。
1つ以上のファイル名拡張子を入力できます。 複数のファイル名拡張子はコンマ (,) で区切ります。 例:
jpg,txt説明異なる大文字小文字で指定された同じファイル名拡張子に対して異なるルールが設定されている場合、最新のルールは以前のルールを上書きします。 たとえば、ルールAがJPG、TXTに設定され、ルールBがjpg、txtに設定されている場合、ルールBはルールAを上書きします。小文字で指定されたファイル名拡張子のルールを作成する場合は、txtのルールとjpgのルールを作成できます。 ファイル名拡張子は大文字と小文字が区別されます。
アスタリスク (*) をワイルドカード文字として使用して、すべてのファイルタイプを指定することはできません。
設定
HTTPステータスコードとTTLを指定します。 TTLは秒単位です。 最大TTLは3年です。 以下のルールにご注意ください。
複数の HTTP ステータスを指定する場合、コードをコンマ (,) で区切ります。
HTTP 2xxおよび3xxステータスコードの場合、特定のコードごとにルールを作成する必要があります。 あいまい一致はサポートされていません。 たとえば、201=10は有効ですが、2xx=12は無効です。
HTTP 4xxおよび5xxステータスコードの場合、完全一致とファジー一致がサポートされます。 たとえば、401=10と4xx=12が有効です。
OK.
HTTPステータスコードのキャッシュルールを作成すると、有効期限 タブにキャッシュルールが表示されます。 ルールを変更または削除できます。
設定例
例1: ディレクトリのキャッシュルールの作成
次の図は、ディレクトリのキャッシュルールの作成方法を示しています。
/directory/aaaディレクトリには、すべてのHTTP 4xxステータスコードが10秒間キャッシュされます。 HTTP 201ステータスコードは15秒間キャッシュされます。 キャッシュされたHTTPステータスコードが期限切れになる前に、POPはリクエストにコードを返すことができます。 HTTPステータスコードの有効期限が切れると、リクエストはオリジンサーバーにリダイレクトされます。
例2: ファイル名拡張子のキャッシュルールの作成
次の図は、ファイル名拡張子のキャッシュルールの作成方法を示しています。
拡張子がjpgまたはtxtのファイルの場合、HTTP 403のステータスコードは10秒間キャッシュされ、HTTP 404のステータスコードは15秒間キャッシュされます。 HTTP 403または404ステータスコードの有効期限が切れると、jpgまたは。txtファイルはオリジンサーバーにリダイレクトされます。
例3: 異なるタイプのキャッシュルールの作成
ルールAはディレクトリに設定され、ルールBはファイル名拡張子に設定されます。 次の図に示すように、ルールは異なるHTTPステータスコードを使用します。
クライアントが
http://example.com/directory/aaa/test.jpgに要求を送信するとき、要求されたリソースはPOPにキャッシュされません。 リクエストはオリジンサーバーにリダイレクトされます。 オリジンサーバーはHTTP 404のステータスコードを返します。 ただし、ファイル名拡張子用に設定されたキャッシュルールは、ディレクトリ用に設定されたキャッシュルールよりも優先度が高くなります。 その結果、HTTP 404ステータスコードは20秒間キャッシュされます。例4: 同じタイプのキャッシュルールの作成
ルールCはディレクトリ /ディレクトリに設定され、ルールDはディレクトリ /ディレクトリ /aaaに設定されます。 次の図に示すように、ルールは異なるHTTPステータスコードを使用します。
クライアントが
http://example.com/directory/aaa/test.jpgに要求を送信するとき、要求されたリソースはPOPにキャッシュされません。 リクエストはオリジンサーバーにリダイレクトされます。 オリジンサーバーはHTTP 404のステータスコードを返します。 この場合、要求は、ルールCおよびルールDに一致する。同じタイプのルールは、作成時間に基づいて優先順位が付けられる。 以前のルールの優先度が高くなります。 その結果、HTTP 404ステータスコードは15秒間キャッシュされます。