ネットワークプログラミング

2013年4月21日 (日)

HTTPのキャッシュとその関連ヘッダ

今さらだが、HTTPのキャッシュの仕組みがやっとなんとなく自分なりに理解できたので、まとめてみる。詳しく知りたい人は当たり前だが、RFC 2616 HTTP/1.1 を読んでください。

ということで、ここではRFC 2616や自分のように読解力がなくて他のHTTPのキャッシュの仕組みについて長々と書いてある他のサイトを読んでも理解できない人向けに、まとめてみる。

以前にも過去に自分でHTTPのキャッシュの仕組みを色々調べたと思うが、覚えてたことは、Cache-ControlやらExpiresやらIf-Modified-Sinceやら色々、キャッシュ絡みのHTTPヘッダがたくさんあるな・・dashdashぐらいと全く覚えてなくて・・・要は全く理解してないのでほとんど覚えてない・・のであったが。遂に自分の中でまとまったupup

まず、重要なことはHTTPのキャッシュの仕組みは

  • 失効モデル(リクエスト自体の回数を減らす)
  • 検証モデル(フルレスポンスの送受信の回数を減らす)

と2段構えになっていて、

前者の失効モデルとはリクエストを行うときに、以前に行った同一リソースに対するリクエストのレスポンスのローカルコピーがあり、それが利用できるならそれを直接利用しようというのが前者で、それが利用できるかわからないので、実際にローカルコピーを使用してもよいかサーバーに問い合わせるが、その時、変更されローカルコピーが利用できなくなった時だけ(条件リクエスト)、サーバーに新しいフルレスポンスを送信してもらうのが後者と。

そして、キャッシュ絡みのHTTPヘッダがたくさんあると書いたが、基本それらは失効モデル、検証モデルのどちらか一方で使われるヘッダなので、それで分類すると随分と見通しがよくなる。

失効モデル

  • Age(レスポンス)
  • Date(汎用)
  • Expires(エンティティ)
  • Cache-Control(汎用)のmax_ageディレクティブなど

検証モデル

  • Last-Modified(エンティティ)
  • If-Modified-Since(リクエスト)
  • If-Unmodified-Since(リクエスト)
  • ETag(レスポンス)
  • If-Match(リクエスト)
  • If-None-Match(リクエスト)
  • Range(リクエスト)
  • If-Range(リクエスト)

失効モデルでは、ネットワークトラフィックを発生させる実際のリクエストを行わずに、クライアントがキャッシュしているローカルコピーを直接利用してよいかつまりローカルコピーが失効してるかを判定するが、ExpiresやAgeヘッダなどはもちろんそれらを判定するために使われる。実際の判定式などを含む詳細はRFCを読んで・・

検証モデルでは、ローカルコピーとサーバー上のエンティティを比較するために、検証子(validator)というものを使用する。サーバーがフルレスポンスを生成する時に、検証子と呼ばれるものをそれにアタッチする。クライアントは受信したレスポンスと共にその検証子をキャッシュする。そして、前述のように失効モデルで失効と判定されたローカルコピーを持つリソースに対するリクエストを再び行う時に、その検証子を指定して条件リクエストを行う。

サーバーはリクエストで指定された検証子を現在の検証子と比較して、一致すれば、特殊なステータスコード(通常、304(Not Modified))とエンティティボディなしで応答し、一致しなければ、(エンティティボディを含む)フルレスポンスで応答する。このようにして、フルレスポンスの送受信を減らす。

で、検証子として最終更新日時とエンティティタグなどが使用でき、それぞれ、Last-Modifiedヘッダ、ETagヘッダで指定され、残りのIfで始まるヘッダは検証子を使い条件リクエストを行うためのヘッダである。

とまぁ、だいたいこんな感じだろうdashdash

ポイントは繰り返すが、

  • 失効モデル(リクエスト自体の回数を減らす)
  • 検証モデル(フルレスポンスの送受信の回数を減らす)

と2段構えupという最低限の全体像を把握しましょう。

プラットフォーム特有だが他の参考資料

2010年6月26日 (土)

TwitterクライアントPiyotter(ピヨッター)

ということで、今まで何をやってたかと言うとWindows向けのTwitterクライアントを作ってましたgood

一向に開発が進まないのですが、このままだと一生公開できなさそうだったので、勢いでとりあえずリリースしますdashdash

はっきり言って、最低限必要な機能すら実装していませんのでsweat02sweat02・・・・アイコンも開発環境そのままの使ってたりします・・・

一応、開発するにあたって、既存のクライアントを参考にしながら、どんな機能を実装するか次のような目標を立てたんですが・・

  • マルチアカウント対応(まぁ、別に自分は複数アカウント切り替えて使うTwitterのヘビーユーザーじゃないけど・・・)
  • マルチカラム(とりあえず、もっと自由なレイアウトで複数のタイムライン見たいよね??)
  • レジストリを使用しない(レジストリ汚されるのは嫌なので・・・)
  • 軽量で高速?(自分のPCのメモリが1GBしか積めないので・・・)

ははは。Windowsのネイティブクライアントなので.NETやAdobe AIRとかは必要ありません。

とりあえず、現状、タイムラインを見て簡単な投稿をするぐらいの機能しか実装されていません。Twitterアカウントを持ってなくてもパブリックタイムラインや特定の公開ユーザーのユーザータイムラインは見れます。

画面はこんな感じです。

タブ形式。

Piyo1

縦に並べる。

Piyo2

横に並べる。

 

Piyo3

というより、カラムのレイアウトは上記を複数組み合わせれるのでほぼ自由自在だと思います。

アカウントはアカウントの管理画面から追加できます。

Piyo4

カラムはカラムの追加画面から。

Piyo5

リストにも対応しています。

Piyo5

また、カラム毎に更新間隔・取得件数などを設定できます。

Piyo6

というかぶっちゃけ、完成させれる気がしないんだけど・・・・wobbly

しばらくは、落ち着くまで毎週1回はアップデートしようかなと思ってます。

自作ソフトウェア

無料ブログはココログ

メモ