それは無駄だろう、ということで考案された(かどうかは知りませんが) ものが、いわゆる Web キャッシュシステム(あるいは Web proxy cache server)です。というわけで情報処理センターでも、しばらく 前から試験的に運用しています( proxy.cc.hit-u.ac.jp:3128)。
「元データが更新されたときはキャッシュされているコピーデータの方はどうな るのか？」という疑問が湧くかもしれませんが、元データの更新時刻を毎回チェッ クするなど、いろいろ工夫をこらしているのでキャッシュデータが古いままにな る、ということは基本的にはおこらないようになっています。まあ実際にはいろ いろな要因が重なっておこらないはずのことがおきてしまうこともありますが。 ちなみに現在主流のWebブラウザ(Internet Explorer や Netscape Communicater など)は内部で自前のキャッシュをおこなっていますので(キャッ シュ機能を止めることは可能です)、ブラウザ単体で利用していてもこのキャッ シュの問題は避けられません。
さて、この Web キャッシュシステムには人間工学的(?)な問題点が あります。それは利用者が意識的にこのキャッシュシステムを利用する設定を Web ブラウザ に対して行なわなければならないことです。 たいした手間ではありませんが、やはり面倒ですね。またネットワーク管理者の 立場からすると、キャッシュシステムを使って欲しくても、利用者側が対応して くれないかぎりどうしようもないという難点があります。
それに対して、利用者が何も意識しなくても Web キャッシュシステム を使えるという優れもの(かどうかは立場によりますが)が、今回試験運用してみた Web トランスペアレントキャッシュシステムです。 transparent という名の通り、透過的に Web のキャッシュをおこないま すので、利用者は Web キャッシュシステムを利用していると意識する 必要がありません (建前では。実際には後述するようにいろいろと問題があったりします)。
たとえば、みなさんが国連の Web ページ( http://www.un.org/) を閲覧するとしましょう。みなさんの使っているコンピュータ(ここでは sakuraという名前だとします)からは
しかし実際には図中の「L4 スイッチ」と呼ばれる機械がネットワーク を監視していて、 www.un.orgへ送られた Web のリクエストを 「Webキャッシュサーバ」へ強制的に転送します。
この Webキャッシュサーバが実際には www.un.orgへ リクエストを送ってデータを受けとります (そのデータのコピーをキャッシュサーバの内部に保存しておきます)。 そして、そのデータを www.un.orgをよそおって sakuraへ転送する、という仕組みになっています。
そうすると、次に umeという名前の別のコンピュータから 誰かが国連の Webページを閲覧しようとしたときには、Webキャッシュサーバは 改めて www.un.orgへリクエストを送ったりしない (このへん本当はもうすこし複雑ですが省略しています) で、保存してあるデータのコピーを umeへ送ります。
こうして Mercury とインターネットの間を流れるデータの量 (トラフィック)を減らすことができる(かもしれない)わけです。
