キャッシュの概要

キャッシュに保存可能なレスポンスとは、Cloud CDN がキャッシュに保存できる HTTP レスポンスで、すぐに取り出せるので読み込み時間が短縮されます。すべての HTTP レスポンスがキャッシュに保存可能なわけではありません。

キャッシュ モード

キャッシュ モードでは、Cloud CDN がコンテンツをキャッシュに保存するかどうかを決定する要素を制御できます。

Cloud CDN には 3 つのキャッシュ モードがあり、レスポンスがキャッシュに保存される方法、Cloud CDN が送信元から送信されたキャッシュ ディレクティブを遵守するかどうか、キャッシュ TTL の適用方法を定義します。

次の表に使用可能なキャッシュ モードを示します。

キャッシュ モード 動作
USE_ORIGIN_HEADERS 有効なキャッシュ ディレクティブと有効なキャッシュ ヘッダーを設定するには、送信元のレスポンスが必要です。
CACHE_ALL_STATIC no-store、private、または no-cache ディレクティブがない静的コンテンツを自動的にキャッシュに保存します。有効なキャッシュ ディレクティブを設定した送信元のレスポンスもキャッシュに保存されます。
FORCE_CACHE_ALL レスポンスを無条件にキャッシュに保存し、送信元で設定されたすべてのキャッシュ ディレクティブをオーバーライドします。このモードに構成された共有バックエンドを使用する場合、非公開のユーザー単位のコンテンツ（ダイナミック HTML や API レスポンスなど）はキャッシュに保存しないでください。

キャッシュ モードのベータ版リリースでは、バックエンド（送信元）で Cloud CDN を有効にすると、必要に応じてキャッシュ モードを CACHE_ALL_STATIC に設定できますが、デフォルトの動作では、Google Cloud は引き続き有効なキャッシュ ディレクティブと有効なキャッシュ ヘッダーを設定する送信元のレスポンスを必要とします。これは USE_ORIGIN_HEADERS キャッシュ モードと呼ばれるようになりました。これらのディレクティブがないレスポンスとキャッシュ不可のレスポンスは、送信元から提供されます。

  • キャッシュ モードの一般提供リリースで、Cloud CDN はデフォルトでは USE_ORIGIN_HEADERS キャッシュ モードではなく、CACHE_ALL_STATIC キャッシュ モードになります。

  • Cloud CDN がすでに有効になっている既存の送信元の動作は変更されません。これらの送信元のキャッシュ モードは USE_ORIGIN_HEADERS に設定され、Cloud CDN の既存の動作が反映されます。

次の表に、ベータ版と一般提供版のデフォルト動作をまとめます。

リリース段階 既存または新規 デフォルトのキャッシュ モード
ベータ版 新しいバックエンド USE_ORIGIN_HEADERS（変更なし）
ベータ版 既存のバックエンド USE_ORIGIN_HEADERS（変更なし）
一般提供 新しいバックエンド CACHE_ALL_STATIC（新しいデフォルト）
一般提供 既存のバックエンド USE_ORIGIN_HEADERS（変更なし）

設定手順については、キャッシュ モードの設定をご覧ください。

静的コンテンツ

静的コンテンツとは常に同じコンテンツのことであり、異なるユーザーがアクセスする場合でも同じものが表示されます。サイトのスタイル設定で使用する CSS、インタラクティビティを追加する JavaScript、動画、画像コンテンツは通常、特定の URL（キャッシュキー）にアクセスするユーザーごとに変化しないため、Cloud CDN のグローバル エッジ ネットワーク上でのキャッシュ保存のメリットが得られます。

すべての静的コンテンツをキャッシュに保存するようにキャッシュ モードを設定すると、Cloud CDN は次のレスポンスを自動的にキャッシュに保存します。

  • CSS（text/css）、JavaScript（application/javascript）、WOFF2（font/woff2）などのすべてのウェブフォントを含むウェブアセット
  • JPEG（image/jpg）や PNG（image/png）などの画像
  • H.264、H.265、MP4（video/mp4）などの動画および MP3（image/mpeg）、MP4（audio/mp4）などの音声ファイル
  • PDF（application/pdf）などのフォーマットされたドキュメント

次の表に概要を示します。

カテゴリ MIME タイプ
ウェブアセット text/css text/ecmascript text/javascript application/javascript
フォント font/* に一致する Content-Type
画像 image/* に一致する Content-Type
動画 video/* に一致する Content-Type
音声 audio/* に一致する Content-Type
フォーマットされたドキュメント タイプ application/pdf と application/postscript

Cloud CDN は、配信されるコンテンツの MIME タイプを反映した Content-Type HTTP レスポンス ヘッダーを検査します。

次の点にご注意ください。

  • 送信元のウェブサーバー ソフトウェアが各レスポンスで Content-Type を設定する必要があります。多くのウェブサーバーは、NGINX、Varnish、Apache などの Content-Type ヘッダーを自動的に設定します。

  • Cloud Console または gsutil ツールを使用してコンテンツをアップロードすると、Cloud Storage により Content-Type ヘッダーがアップロード時に自動的に設定されます。

  • レスポンスが MIME タイプに基づいてキャッシュ可能であるものの、private、no-store、no-cache の Cache-Control レスポンス ヘッダー、または Set-Cookie ヘッダー（ルールの完全なリストを参照）がある場合は、キャッシュに保存されません。

Cloud CDN では、有効なキャッシュ可能なレスポンスの多くが URL に反映されないため、レスポンスがキャッシュ可能かどうかを判断するために URL パスでファイル拡張子を使用しません。

text/html および application/json のコンテンツ タイプをキャッシュに保存する場合は、1 人のユーザーのデータを誤ってキャッシュに保存して、すべてのユーザーに提供しないようにするために、レスポンスに明示的な Cache-Control ヘッダーを設定する必要があります。

キャッシュに保存可能なコンテンツ

Cloud CDN がキャッシュに保存するのは、このセクションで説明する要件をすべて満たしているレスポンスだけです。この要件の一部は RFC 7234 で規定されています。その他の要件は Cloud CDN 固有のものです。

次の条件をすべて満たしている場合にのみ、Cloud CDN キャッシュにレスポンスを保存できます。

属性 要件
提供元 バックエンドサービス、バックエンド バケット、またはカスタム送信元（Cloud CDN が有効になっているもの）
何に対するレスポンスか GET リクエスト
ステータス コード 200、203、204、206、300、301、302、307、308、404、405、410、421、451、または 501
キャッシュ ディレクティブ

USE_ORIGIN_HEADERS キャッシュ モードでの場合、レスポンスには public ディレクティブを含む Cache-Control ヘッダーが必要です。

CACHE_ALL_STATIC キャッシュ モードの場合、レスポンスには、public ディレクティブを含む Cache-Control ヘッダー、または静的コンテンツ タイプが必要です。

FORCE_CACHE_ALL キャッシュ モードの場合、レスポンスが常にキャッシュ保存の対象になります。
鮮度

USE_ORIGIN_HEADERS キャッシュ モードでは、レスポンスには、max-age または s-maxage ディレクティブを含む Cache-Control ヘッダー、または将来のタイムスタンプを含む Expires ヘッダーがあります。

CACHE_ALL_STATIC キャッシュ モードでは、静的コンテンツを保持するバックエンド レスポンスは最新とみなされます。静的ではないコンテンツの鮮度は、元のヘッダーに基づきます。

FORCE_CACHE_ALL キャッシュ モードでは、すべてのバックエンド レスポンスが最新とみなされます。
コンテンツ

有効な Content-Length、Content-Range、Transfer-Encoding ヘッダーのいずれかを含む。

たとえば、レスポンスのサイズに正しく一致する Content-Length ヘッダー。
サイズ 最大サイズ以下である

Cloud Storage バックエンド バケットの場合、これらの要件を満たすいくつかの方法を以下に示します。

デフォルトでは、バケット全体が公開されている、または個別のオブジェクトが公開されていて、個別のオブジェクトが Cache-Control メタデータを指定していない場合、Cloud Storage はそれらのオブジェクトに Cache-Control: public, max-age=3600 ヘッダーを割り当てます。Cache-Control メタデータを使用することで、さまざまな値を設定できます。

バックエンド バケットを使用して外部 HTTP(S) ロードバランサを構成する方法の例については、バックエンド バケットを使用した Cloud CDN の設定をご覧ください。

最大サイズ

Cloud CDN では、各レスポンスに最大サイズが適用されます。本文のサイズが最大サイズより大きいレスポンスはキャッシュに保存されませんが、クライアントには配信されます。

最大サイズは、送信元サーバーがバイト範囲リクエストをサポートしているかどうかによって異なります。

送信元サーバーがバイト範囲リクエストをサポートしている 送信元サーバーがバイト範囲リクエストをサポートしていない
5 TB（5,497,558,138,880 バイト） 10 MB（10,485,760 バイト）

ほとんどの最新のウェブサーバー（NGINX、Apache、Varnish を含む）は、バイト範囲リクエストをサポートしています。

元のヘッダーに基づいたキャッシュに保存できないコンテンツ

レスポンスがキャッシュに保存されるかどうか確認する方法があります。

レスポンスがキャッシュに保存可能なコンテンツの要件を満たしていない場合、つまり次のいずれかに該当する場合、レスポンスはキャッシュに保存されません。

属性 要件
提供元 バックエンドサービス、バックエンド バケット、またはカスタム送信元（Cloud CDN が有効になっていないもの）
Cookie Set-Cookie ヘッダーがある
Vary ヘッダー Accept、Accept-Encoding、Origin 以外の値が設定されている。
レスポンス ディレクティブ レスポンスに、no-store、no-cache、または private のディレクティブを含む Cache-Control ヘッダーがある（Cache-Control ヘッダーが無視される FORCE_CACHE_ALL モードを使用している場合を除く）
リクエスト ディレクティブ リクエストに Cache-Control: no-store ヘッダーがある
サイズ 最大サイズを超えている

これらの要件は今後緩和される可能性があり、その場合は Cloud CDN のキャッシュに保存されるレスポンスの種類が増えます。

Cache-Control: no-store、no-cache、または private が存在するものの、コンテンツが引き続きキャッシュに保存されている場合は、次のいずれかが原因です。

  • URL 署名が構成されている。
  • Cloud CDN キャッシュ モードが、すべてのレスポンスを強制的にキャッシュに保存するように設定されている。

キャッシュ保存の禁止

個人情報が Cloud CDN キャッシュに保存されるのを防ぐには:

  1. Cloud CDN キャッシュ モードが FORCE_CACHE_ALL モードに設定されていないことを確認してください。このモードでは、すべてのレスポンスが無条件にキャッシュに保存されます。
  2. Cloud CDN キャッシュに保存してはならないレスポンスには Cache-Control: private ヘッダーを含めます。ウェブブラウザのキャッシュを含むすべてのキャッシュに保存してはならないレスポンスには、Cache-Control: no-store ヘッダーを含めます。
  3. 個人情報へのアクセスを提供する URL に署名しないでください。署名付き URL を使ってコンテンツがアクセスされる場合は、レスポンス内の Cache-Control ディレクティブの内容に関係なく、コンテンツがキャッシュ対象になる可能性があります。

カスタム レスポンス ヘッダーの追加

カスタム レスポンス ヘッダーを使用すると、外部 HTTP(S) ロードバランサがプロキシされたレスポンスに追加するヘッダーを指定できます。カスタム レスポンス ヘッダーを使用すると、クライアント、クライアントの地理的データ、独自の静的レスポンス ヘッダーにキャッシュ ステータスを反映できます。

ヘッダーのリストについては、ヘッダー値に表示できる変数をご覧ください。

手順については、カスタム レスポンス ヘッダーの使用をご覧ください。

キャッシュキー

Cloud CDN キャッシュの各キャッシュ エントリは、1 つのキャッシュキーで識別されます。リクエストがキャッシュに到達すると、リクエストの URI がキャッシュキーに変換され、さまざまなキャッシュ済みエントリのキーと比較されます。一致するキーが見つかると、そのキーに対応するオブジェクトが返されます。

バックエンド サービスの場合、デフォルトで、Cloud CDN は完全なリクエスト URI をキャッシュキーとして使用します。たとえば、https://example.com/images/cat.jpg は cat.jpg オブジェクトを求めるリクエストの完全な URI ですが、この文字列がデフォルトのキャッシュキーとして使用され、文字列が完全に同じリクエストのみが一致します。したがって、http://example.com/images/cat.jpg または https://example.com/images/cat.jpg?user=user1 に対するリクエストは一致しません。

キャッシュキーで使用される URI の部分を変更できます。キーには常にファイル名とパスが含まれている必要がありますが、キャッシュキーをカスタマイズするときには、プロトコル、ホスト、クエリ文字列を任意に組み合わせて含めたり省略したりできます。キャッシュキーのカスタマイズ方法については、キャッシュキーの使用をご覧ください。

URI の各部分 カスタマイズ 同じキャッシュキーを持つ URL の例
プロトコル キャッシュキーからプロトコルを省略します。
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
ホスト キャッシュキーからホストを省略します。
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
クエリ文字列

キャッシュキーからクエリ文字列を省略します。

クエリ文字列を部分的に省略または追加します。
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

クエリ文字列全体を追加または省略するだけでなく、追加リストと除外リストを使用してクエリ文字列の一部を使用することもできます。

バックエンド バケットの場合、キャッシュキーは、プロトコル、ホスト、クエリ文字列を含まない URI で構成されます。

したがって、特定のバックエンド バケットについて、次の URI はキャッシュ内の同じ 1 つのオブジェクトに解決されます。

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

クエリ文字列の追加リスト

Cloud CDN がキャッシュキーに追加するクエリ文字列パラメータを選択できます。たとえば、user の追加リストを作成すると、https://example.com/images/cat.jpg?user=user1&color=blue は https://example.com/images/cat.jpg?user=user1&color=red にも一致する https://example.com/images/cat.jpg?user=user1 のキャッシュキーを作成します。

このオプションを使用するには、クエリ文字列を追加して空でない追加リストを指定する必要があります（除外リストは指定しません）。

クエリ文字列の除外リスト

除外リストを使用すると、Cloud CDN が無視するクエリ文字列パラメータを選択的に制御できます。たとえば、user の除外リストを作成すると、user を除くすべてのクエリ文字列パラメータがキャッシュキーで使用されます。

このように除外リストを構成した状態で https://example.com/images/cat.jpg?user=user1&color=blue と入力された場合、Cloud CDN はキャッシュキー https://example.com/images/cat.jpg?color=blue を作成します。このキーは https://example.com/images/cat.jpg?user=user2&color=blue にも一致しますが、https://example.com/images/cat.jpg?user=user1&color=red には一致しません。

このオプションを使用するには、クエリ文字列を追加して空でない除外リストを指定する必要があります（追加リストは指定しません）。

Vary ヘッダー

Vary ヘッダーがある場合は、クライアントのリクエスト ヘッダーに応じてレスポンスが異なります。Cloud CDN では、リクエスト URI だけでなく、送信元サーバーがレスポンスに追加する Vary ヘッダーも考慮されます。たとえば、レスポンスで Vary: Accept が指定されている場合、Cloud CDN は、Accept: image/webp,image/*,*/*;q=0.8 が指定されているリクエストと Accept: */* が指定されているリクエストに別々のキャッシュ エントリを使用します。

キャッシュに保存できないコンテンツ セクションの表には、コンテンツをキャッシュに保存できるようにする Vary ヘッダーが一覧表示されます。その他の Vary ヘッダー値は、コンテンツがキャッシュに保存されることを禁止します。

Vary ヘッダーは、圧縮済みコンテンツを配信するときに使用されることもあります。Cloud CDN はレスポンスそのものを圧縮、解凍しませんが、送信元サーバーが圧縮したレスポンスを配信できます。Accept-Encoding リクエスト ヘッダーの値に基づいて、送信元サーバーが圧縮、非圧縮コンテンツのどちらを配信するかを選択する場合は、レスポンスで Vary: Accept-Encoding が指定されていることを確認してください。

有効期間と検証リクエスト

USE_ORIGIN_HEADERS キャッシュ モードの場合、Cloud CDN キャッシュの各キャッシュ エントリには RFC 7234 に従って Cache-Control: s-maxage、Cache-Control: max-age、Expires ヘッダーで定義された有効期間が存在します。複数のヘッダーが存在する場合には、Cache-Control: s-maxage が Cache-Control: max-age よりも優先され、Cache-Control: max-age が Expires よりも優先されます。

CACHE_ALL_STATIC キャッシュ モードでは、静的コンテンツを保持するバックエンド レスポンスは最新とみなされます。静的ではないコンテンツの鮮度は、元のヘッダーに基づきます。

FORCE_CACHE_ALL キャッシュ モードでは、すべてのバックエンド レスポンスが最新とみなされます。

Cloud CDN がリクエストを受信すると、該当するキャッシュ エントリを参照して有効期間を確認します。キャッシュ エントリが存在し、有効期間が残っている場合、キャッシュからレスポンスを提供します。しかし、有効期間が過ぎている場合、Cloud CDN がレスポンスを返すには、まずいずれかのバックエンドと通信する必要があります。

Cloud CDN は、キャッシュに滞在する日数が 30 日を超えているオブジェクトを再検証します。ユーザーが生成した古いキャッシュ コンテンツは、この方法によって自動的に無効になり、削除されます。max-age または s-maxage の値が 30 日（2,592,000 秒）を超える場合、Cloud CDN はその値を 2,592,000 秒として処理しますが、ダウンストリーム クライアントには、max-age と s- maxage の値が 30 日を超える場合でも正しい値がそのまま表示されます。

Cloud CDN は、キャッシュ内のレスポンス ヘッダーに含まれる情報を使用して、バックエンドでキャッシュ エントリを検証できます。これは、次の両方に該当する場合に発生します。

  • 以前にキャッシュに保存されたレスポンスに Last-Modified または ETag ヘッダーが含まれている。
  • クライアント リクエストが、If-Modified-Since または If-None-Match ヘッダーを含まない GET リクエストである。

Cloud CDN がこの検証を行う方法は、バイト範囲リクエストを使ってレスポンスがキャッシュされたかどうかによって少々異なります。

  • バイト範囲リクエストを使ってレスポンスがキャッシュに保存された場合、Cloud CDN は If-Modified-Since または If-None-Match ヘッダー、あるいはこの両方を含む 1 つの別個の検証リクエストを開始します。
  • そうでない場合、Cloud CDN は If-Modified-Since または If-None-Match ヘッダー、あるいはこの両方をクライアント リクエストに追加し、変更したリクエストをバックエンドに転送します。

キャッシュ内のコピーがまだ最新の状態であれば、バックエンドは 304 Not Modified レスポンスを送信することで既存のキャッシュ エントリを検証できます。この場合、バックエンドから送信されるのはレスポンス ヘッダーのみであり、レスポンスの本文は送信されません。Cloud CDN は、新しいレスポンス ヘッダーをキャッシュに挿入して有効期間を更新し、新しいレスポンス ヘッダーとキャッシュ内のレスポンス本文をクライアントに送信します。

以前にキャッシュに保存されたレスポンスに Last-Modified と ETag のいずれのヘッダーもない場合、Cloud CDN は期限切れのキャッシュ エントリを無視し、クライアント リクエストをそのままバックエンドに転送します。

キャッシュ エントリの有効期間とは、そのキャッシュ エントリが有効である時間の長さの上限です。キャッシュ エントリが期限切れになるまでキャッシュに保存されるという保証はありません。新しいコンテンツの場所を確保する目的で、人気のないコンテンツのキャッシュ エントリが削除される場合もあります。指定された有効期間に関係なく、30 日間アクセスされていないキャッシュ エントリは自動的に削除されます。

詳しくは、エビクションと有効期限をご覧ください。

TTL の設定とオーバーライド

コンテンツを再検証するまでの Cloud CDN の待機時間について、Cloud CDN の動作を微調整できます。

詳細については、TTL の設定とオーバーライドを使用するをご覧ください。

バイト範囲リクエストのサポート

レスポンスが次の条件を満たしている場合、送信元サーバーはバイト範囲リクエストをサポートしていることになります。

  • ステータス コード: 200 OK または 206 Partial Content
  • ヘッダー: Accept-Ranges: bytes
  • ヘッダー: Content-Length または Content-Range
  • ヘッダー: 強いバリデータを使用した ETag
  • ヘッダー: Last-Modified

Cloud Storage は、ほとんどのオブジェクトに関してバイト範囲リクエストをサポートしています。ただし、Content-Encoding: gzip メタデータを持つオブジェクトについては、クライアント リクエストの中に Accept- Encoding: gzip ヘッダーがある場合を除き、バイト範囲リクエストがサポートされません。Cloud Storage オブジェクトが 10 MB を超える場合は、Content-Encoding: gzip メタデータがないことを確認してください。オブジェクトのメタデータの編集方法については、オブジェクトのメタデータの表示と編集をご覧ください。

一般的なウェブサーバー ソフトウェアでも、バイト範囲リクエストがサポートされています。サポートを有効にする方法の詳細については、お使いのウェブサーバー ソフトウェアのドキュメントをご覧ください。バイト範囲リクエストの詳細については、HTTP 仕様をご覧ください。

送信元サーバーがバイト範囲リクエストをサポートしている場合、次のいずれかの条件が当てはまると、Cloud CDN キャッシュは、本来ならばキャッシュ保存可能なレスポンスでも、初回リクエスト時にはキャッシュへの保存を拒否します。

  • クライアントがコンテンツの一部分だけをリクエストしたことが理由で、レスポンス本文が不完全である。
  • レスポンス本文が 1 MB（1,048,576 バイト）を超えている。

レスポンスが通常のキャッシュ保存の要件を満たしているにもかかわらず、前述の拒否が発生した場合は、送信元サーバーがそのキャッシュキーに対してバイト範囲リクエストをサポートしていることがキャッシュに記録され、送信元サーバーのレスポンスがクライアントに転送されます。

キャッシュミスが発生した場合、キャッシュは、送信元サーバーがバイト範囲リクエストをサポートしているという記録があるかどうかを調べます。そのキャッシュキーでバイト範囲リクエストがサポートされていることがわかれば、クライアント リクエストがキャッシュから外部 HTTP(S) ロードバランサに転送されることはありません。代わりに、コンテンツの不足部分を求めてキャッシュ自体がバイト範囲キャッシュ フィル リクエストを開始します。送信元サーバーからの 206 Partial Content レスポンスで、リクエストされたバイト範囲が返された場合、キャッシュはその範囲を将来のリクエストに備えて保存できます。

キャッシュが 206 Partial Content レスポンスを保存するのは、キャッシュ自体がバイト範囲リクエストを開始し、それに対してこのレスポンスを受け取った場合のみです。送信元サーバーがバイト範囲リクエストをサポートしていることが記録されている限り、キャッシュはそのキャッシュキーについてバイト範囲リクエストを開始できます。1 MB を超える大きなサイズのコンテンツが 2 回目にアクセスされるまでキャッシュに保存されない（初回リクエスト時には拒否される）のは、このようなメカニズムが背景で働いているからです。

Cloud CDN によって作成されるリクエスト

送信元サーバーがバイト範囲リクエストをサポートしている場合、単一のクライアント リクエストに対して Cloud CDN から複数のリクエストが送信元サーバーに送信されることがあります。Cloud CDN が作成できるリクエストには、検証リクエストとバイト範囲リクエストの 2 種類があります。

送信元サーバーが特定のキャッシュキーのバイト範囲リクエストをサポートしていることがレスポンスで示されていたものの、そのレスポンスの有効期間が過ぎている場合は、Cloud CDN が検証リクエストを開始します。その目的は、コンテンツが変化していないこと、また送信元サーバーが引き続きそのコンテンツの範囲リクエストをサポートしていることの確認です。送信元サーバーから 304 Not Modified レスポンスが返された場合、Cloud CDN はそのバイト範囲を使用してコンテンツを配信します。そうでない場合、Cloud CDN は送信元サーバーのレスポンスをクライアントに転送します。有効期限を制御するには、Cache-Control と Expires のレスポンス ヘッダーを使用します。

キャッシュミスが発生した場合、Cloud CDN はクライアント リクエストと重複する一連のバイト範囲に対するキャッシュ フィル リクエストを開始します。クライアントからリクエストされたコンテンツの範囲の一部がキャッシュにある場合、Cloud CDN はできる限りキャッシュから配信し、不足している範囲についてのみ、バイト範囲リクエストを送信元サーバーに送ります。

Cloud CDN が開始するバイト範囲リクエストには、それぞれ範囲が指定され、範囲の開始オフセットは 2,097,136 バイトの倍数になります。最後の範囲を除いて、各範囲も 2,097,136 バイトです。コンテンツのサイズがこのバイト数の倍数でない場合、最後の範囲がこれより小さくなります。バイト範囲リクエストで使用されるサイズとオフセットは、将来変更される可能性もあります。

例として、クライアントがコンテンツの 1,000,000 バイト目から 3,999,999 バイト目までをリクエストしたが、キャッシュにはそれが存在しないとします。この例では、Cloud CDN は 2 つの GET リクエストを開始します。1 つはコンテンツの最初の 2,097,136 バイト用、もう 1 つは 2 番目の 2,097,136 バイト用です。つまり、クライアントがリクエストしたのは 3,000,000 バイトだけでも、4,194,272 バイト分のキャッシュ フィルが行われます。

Cloud Storage バケットを送信元として使用するときは、GET リクエストごとに独立したクラス B オペレーションとして料金が発生します。料金は、Cloud Storage によって処理されたすべての GET リクエストについて発生します。これには、Cloud CDN によって作成されたリクエストも含まれます。1 つのレスポンス全体が Cloud CDN キャッシュから提供されるときは、GET リクエストが Cloud Storage に送信されないので、Cloud Storage オペレーションの料金は発生しません。

Cloud CDN によって検証リクエストやバイト範囲リクエストが開始されるときに、クライアント固有のヘッダー（たとえば Cookie や User-Agent）がリクエストに含まれることはありません。

次のステップ