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