Real World HTTPの１章2.7「プロキシ」〜2章終わりまで読んだ
プロキシ
- HTTPなどの通信を中継する仕組み。中継するだけでなく、様々な付加機能が実装されることもある
- キャッシュ機能を持ったプロキシを組織のネットワークの出入り口に置くことで、コンテンツを置くウェブサーバーの負担を減らし、かつ各ユーザーが高速にページを閲覧できるようになる
- プロキシを実現する仕組みは単純で、GETなどのメソッドの次にくるパス名の形式だけが変わる。メソッドの直後のパスは通常
/helloworldといったスラッシュから始まるUNIX形式のパス名になるが、プロキシを設定するとスキーマも追加されて、http://やhttps://から始まるURL形式になる
プロキシとゲートウェイの違い
プロキシ 通信内容を理解する。必要に応じてコンテンツを改変したり、サーバーの代わりに応答したりする
ゲートウェイ 通信内容をそのまま転送する。内容の改変も許さない。クライアントからは途中に存在することを気づかれてはならない
キャッシュ
- すでにダウンロード済みで内容に変化がなければダウンロードを抑制し、それによってページを高速に表示するなど、パフォーマンスを上げるメカニズムのこと
- GETとHEADメソッド以外は基本的にキャッシュされない
- 現在のキャッシュ周りのルールはとても複雑だが、最初はシンプルだったのでバージョンを追って仕組みを理解しよう
更新日時によるキャッシュ
- HTTP1.0のキャッシュの仕組み
- Webサーバーのレスポンスをキャッシュして、そのレスポンスに
Last-Modifiedヘッダーが存在すれば、Webブラウザはその値を持っておく。Webブラウザがキャッシュ済みのURLを再度読み込む時はサーバーレスポンスのLast-Modifiedの値をそのままIf-Modified-Sinceヘッダーに入れてリクエストを送る。ウェブサーバーはリクエストに付与された日時とサーバー上のコンテンツの日時を比較して、変更があれば通常通りステータスコード200 OKを返してコンテンツをレスポンスボディに載せて送信する。変更がなければステータスコード304 Not Modifiedを返し、ボディはレスポンスに含まれなくなる。 - つまり、前回問い合わせた時と今回でサーバーのコンテンツの内容が変更されているかいないかを確認し、変更されていなければボディ自体をブラウザに返さないようにするということ
- Webサーバーのレスポンスをキャッシュして、そのレスポンスに
Expires
- 上記の更新日時を使ったキャッシュの場合、キャッシュの有効性を確認するために通信が発生してしまう。この通信自体を無くしてしまう仕組みが
Expiresヘッダーである。（HTTP1.0で導入） - Expiresヘッダーには日時が格納され、クライアントはこの期限内であれば強制的にキャッシュを利用する。つまり、リクエストを一切送信しなくなる。
- サーバーに変更があるかどうかの問い合わせ自体を送信しなくなるので、指定された期限以内に変更された新しいコンテンツを一切見られなくなる。そのため、SNSのトップページなどに使うのは間違いで、CSSなど更新が滅多に行われない静的コンテンツで使用するのが望ましい
Pragma: no-cache
Pragma
no-cacheは途中のプロキシサーバーに対して、「リクエストしたコンテンツがキャッシュされていたとしても、本来のサーバーまでリクエストを届けてほしい」という指示
- HTTP/1.1ではCache-Controlにマージされた
- 今後あまり積極的に使われることはない。
ETagの追加
- サーバーのコンテンツに動的に変更する要素が増えれば増えるほど、どの日時を根拠にキャッシュの有効性を判断すれば良いかの判断が難しくなる。
- その解決案がHTTP/1.1で追加されたETagである。
- シーケンシャルな更新日時と違い、ファイルに関連するハッシュ値を使って比較を行う。
- 1回目のレスポンス時にサーバーはレスポンスにETagヘッダーを付与する。２度目以降では、クライアントはIf-None-Matchヘッダーにダウンロード済みのキャッシュに付いていたETagの値を付けてリクエストする。サーバーはこれを見てこれから送りたいファイルのETagと比較し、値が同じならばファイルに変更は行われていないと判断して304 Not Modifiedをレスポンスとして返す。
- また、ETagはサーバーが自由に決定して返すことができる
Cache-Control
- ETagと同時期にHTTP/1.1で追加されたヘッダー。
- より柔軟なキャッシュ制御をサーバー側から支持することができ、Expires（設定された期限内であれば通信自体せずにキャッシュを利用する仕組み）よりも優先される。
Cache-Controlで使用できるキー
public
- 同一コンピュータを使う複数ユーザ間でキャッシュを再利用することを許可する
private
- 同一コンピュータを使う別のユーザ間でキャッシュを再利用しない。同じURLからユーザごとに異なるコンテンツが返される場合に利用
max-age=n
- キャッシュの鮮度を秒で設定する。指定時間以内であればサーバーに問い合わせずにキャッシュを利用する
s-maxage=n
- max-ageと同等だが共有のキャッシュに対する設定値
no-cache
- キャッシュが有効かどうか毎回サーバーに問い合わせる。max-age=0とほぼ同じ
- Pragma: no-cacheと同じで、キャッシュしないわけでなく、時間を見てサーバーにアクセスしないでコンテンツを再利用することをやめるだけ。サーバーから304 Not Modifiedが返ってきたらキャッシュを利用する
no-store
- キャッシュしない
Vary
ページの表示が変わる理由にあたるヘッダー名をVaryに列挙することで間違ったコンテンツがキャッシュとして使われないようにする仕組み
リファラー
- ユーザーがどの経路からウェブサイトに到達したからをサーバーが把握するために、クライアントがサーバーに送るヘッダー
- クライアントがリンクをクリックして別のサイトにジャンプするときにリンク元ページのURLを送信したり、ウェブページが画像やスクリプトを取得する場合のリソースのリクエストに、それを利用しているHTMLファイルのURLがリファラーとして送信されたりする
- ウェブサービスはリファラー情報を収集することによってどのページが自分のサービスにリンクを張っているのかを知ることができる
検索エンジン向けのコンテンツのアクセス制御
robots.txt
- サーバーのコンテンツ提供者が、クローラーに対してアクセスの許可・不許可を伝えるためのプロトコルのこと
- robots.txtはそのルールを記述するファイルの名前
- ウェブサイト提供者とクローラーの作者間で契約書が取り交わされることはないが、robots.txtを設置することでウェブサイト提供者はきちんと意思表示をしたことになり、クローラーはこれを守らなければならない
