第4回ＣＤＮの仕組み HTTPヘッダとは

今回はCDNを利用する上で避けては通れない、HTTPヘッダの重要性についてご紹介します。

一般的なCDNはオリジンサーバー側のHTTPヘッダをみてキャッシュ時間を決める等、様々な判定を行う為CDNを利用する上でHTTPヘッダとオトモダチになっておくことは大変重要です。

HTTPヘッダって？

WEBサイトを表示する時、http://　もしくはhttps:// から始まっていますが、「http」とは通信プロトコルの一つでWebサーバーとクライアント（ブラウザなど）が、相互に通信するためのお約束ごとです。

Aさんがhttp://www.google.co.jpにアクセスすると、GoogleさんのWEBサーバーがコンテンツを返却し、AさんのブラウザにGoogleのサイトが表示されます。

「このコンテンツみたいです（リクエスト）」　→　「はい。どうぞ！（レスポンス）」

というやりとりがHTTPという決まり事に従ってやりとりされているわけです。その中でどういった情報をリクエストして、どのようなコンテンツを返すのかを定義する文字列がHTTPヘッダです。
HTTPヘッダにはリクエストヘッダとレスポンスヘッダの2種類が存在します。

HTTPヘッダの種類（リクエストヘッダ）

HTTPリクエストヘッダは「コンテンツがみたい！」「WEBみたい！」　という情報をサーバーに送る為の情報です。そのため、HTTPリクエストヘッダを作成するのはアクセス元のブラウザやアプリ本体ということになります。
WEBサーバーは、受け取ったHTTPリクエストヘッダの内容からどんな情報をブラウザやアプリに返すかを判断します。

アクセス元が生成するわけですから当然、ChromeやIE,Firefox、Safariなどブラウザによって若干生成する値は異なりますが基本的なリクエストヘッダは以下の3つのパートがあります。

HTTPリクエスト行

HTTPリクエスト行には、「メソッド」　「URL」　「HTTPバージョン」の3つの情報が含まれています。

メソッド

GETやPOSTなどの情報をメソッドといいます。WEBを閲覧する時は、ほぼGETリクエストですのでインターネット上の多くはGETリクエストが飛び交っていることになります。しかし、WEBフォームから問い合わせを行う場合はPOSTが利用されますし、WEBAPIを呼び出す場合もPOSTが使われる場合があります。

URL

WEBサイトのURLやパスが入ります。

HTTPバージョン

こちらは初めにご案内したHTTPプロトコルのバージョンです。現在主流はHTTP1.1ですが今後次世代プロトコルHTTP2.0という物に置き換わってくるであろうと言われています。
HTTP2.0ではHTTP1.1より効率が良い通信が出来るように、HTTPヘッダや通信の仕組みそのものが見直されているのですが今回は割愛させて頂きます。

データ本体

ブラウザから何かしらデータをサーバーに送る際、そのデータの内容がこちらに格納されます。
すなわちGETなどのメソッドでは空の状態となります。

HTTPリクエストヘッダ

ようやくHTTPヘッダのお話です。HTTPヘッダは主に以下のような情報が入ります。

フィールド名	内容
Authorization	ユーザ認証用データ。サーバからのWWW-Authenticateヘッダに応える
From	要求送信元のメールアドレス
If-Modified-Since	ここに指定された日付以降に更新された情報のみを要求
Referer	現在のページを取得するときにユーザが使ったリンクを含むページのURL
User-Agent	ブラウザのタイプ、ブラウザ固有のコンテンツを返すときに有用
Accept	そのブラウザが欲しいMIMEのタイプ
Accept-Charset	そのブラウザが期待する文字セット
Accept-Encoding	そのブラウザがデコードできるデータのエンコーディング。大きなファイルのダウンロードに有効
Accept-Language	そのブラウザが予期している言語。サーバが多国語に対応しているときなどに使う
Host	もとのURLにリストされているホストとポート
If-Match	指定した ETag にマッチする場合にのみ、メソッドを実行することをサーバに依頼します。
If-None-Match	指定した ETag にマッチしない場合にのみ、メソッドを実行することをサーバに依頼します。
If-Range	情報が更新されていないときはRangeで指定した範囲の情報を、そうでなければ全体を要求
If-Unmodified-Since	指定された日時以降更新されていなかったときに応答を返す
Max-Forwards	TRACEメソッドとともに使う。経由するポートの最大数指定
Proxy-Authorization	Proxy-Authenticateに対応して、プロキシにユーザ認証情報を通知
Range	データの一部を要求する

HTTPリクエストヘッダだけでも結構種類がありますね。

HTTPヘッダの種類（レスポンスヘッダ）

レスポンスヘッダとは、ブラウザやアプリから送られてきたリクエストヘッダをサーバー側が受信した後、サーバー側でレスポンスヘッダを作成しブラウザやアプリに送ります。送られてきたレスポンスヘッダをクライアントが受信して、初めてWEBコンテンツを表示することが出来ます。

レスポンスヘッダには「レスポンス状態コード」「HTTPヘッダ」「データ本体」の3つのパートがあります。

レスポンス状態コード

こちらは、リクエストに対する返答の状態を番号で表した物が入ります。「状態コード」（「HTTPステータスコード」で一般的なのは４０４ NotFound などでしょうか。　こちらはコンテンツがサーバーにありませんというHTTPステータスコードです。

HTTPステータスコードはHTTPヘッダと同様に複数にグループに分かれ、非常に多くのコードがあります。

ステータスコードは大まかに分けて5つです。

100番台 : 処理中
200番台 : 成功
300番台 : リダイレクト
400番台 : クライアントエラー
500番台 : サーバエラー

100番台

100番台はクライアントからのリクエストを処理中であることを示すステータスとなります。
Webサーバー側からクライアント側（ブラウザなど）に対して少しレスポンスに時間がかかることや、詳細な情報をリクエストしてほしい等のレスポンスを返している際に利用します。100番台のステータスコードはあまり利用されることはありません。

200番台

200番台はクライアントからのリクエストが受付に成功したというステータスです。つまりサーバー側ではエラーもなくコンテンツをクライアントに返すことが出来る状態というコードです。多くのCDNでは200番台のステータスコードは普通にファイルをキャッシュします。

300番台

300番台は簡単にいうと「リダイレクト」ですが、実際はブラウザ側で追加の処理を実行する必要があるということを通知する時のステータスコードです。CDN側では200番台と同様キャッシュして配信します。

400番台・500番台

400番台　500番台のステータスコードはエラーコードです。サーバー側でリクエストされたものが返せない状態のときに使用されます。400番台はクライアント側に原因があるエラーとなり、一方500番台はWebサーバ側が原因のエラーです。

CDNではこのようなエラーコードはネガティブレスポンスといい、デフォルトで数分間キャッシュする場合があります。ネガティブレスポンスをキャッシュするメリットとしては大量の不要なエラーアクセスをオリジンサーバー側に到達させないという目的があり、弊社のCDNもデフォルトで最大5分間ネガティブレスポンスをキャッシュします。

このように、弊社のCDNではステータスコードによってなるべくオリジンサーバーにリクエストを行わないよう、CDNキャッシュサーバー側で出来る処理は全力で行っています。

HTTPレスポンスヘッダ

ようやく、HTTPヘッダのお話です。

HTTPヘッダはデータ本体の前に送られてくる、各種の状態を示す情報が入れられている部分です。HTTPレスポンスヘッダは以下のような種類があります

フィールド名	内容
Server	ウェブサーバの名前とバージョン情報。
Date	現在の日付（グリニッジ標準時）
Last-Modified	リソースの更新日
Content-Length	出力のバイト単位の長さバイナリデータも含みます。
Content-Type	出力のMIMEタイプ
Expires	リソースの有効期限この日付以降は無効です。キャッシュは破棄されます。
Location	リダイレクト URL 情報 Location で指定されたリソースが送信されます。単独ヘッダとして出力されます。
Pragma	リソースのキャッシングを有効/無効にする「Pragma: no-cache」と指定すると、リソースのキャッシュを無効にします。
Status	リクエストのステータス単独ヘッダとして出力されます。
WWW-Authenticate	認証データ。認証に必要なユーザー名やパスワードなどの情報が含まれます。
Refresh	指定されたドキュメントを再ロードする。
Set-Cookie	データをクライアント側に保存する。
Etag	サーバー固有の情報が付与され、ブラウザキャッシュを再利用するかどうか判断させます。

リクエストヘッダと同じくそこそこ種類がありますね。

データ本体

データ本体にはHTMLや画像、動画などの実際表示するコンテンツ自身が入ってます。
ブラウザは、データ本体の前に先ほどの「レスポンス状態コード」と「HTTPヘッダ」を受け取っていますが、画面には表示しないため意識することは出来ないです。

まとめ

今回はCDNを運用していく上で重要となるHTTPヘッダのお話をしていみました。CDNではHTTPヘッダ部分もキャッシュするため、ユーザーエージェントやその他情報が毎回異なるだけで、別のキャッシュと認識してしまいます。
そうなると、毎回オリジンサーバーにコンテンツを取りに行ってしまいキャッシュヒット率が低下しCDNを利用している意味が無くなってしまいますね。

そのため、オリジンサーバー側では不要なヘッダは出力せず、本当に付与しなければいけないヘッダのみに限定することがCDNを利用する上でまず初めにできるチューニングです。