前回は、インターネットの内部であるアクセス回線とプロバイダについてまとめた。ここでは、サーバ側のLAN機能であるファイアウォール、キャッシュ・サーバーそしてコンテンツ配信サービスについて説明する。
１ Webサーバーの設置場所
社内にWebサーバーを設置する場合
社内LANにサーバーを設置する場合、パケットは最寄りのPOPにあるルーター、アクセス回線、サーバー側のルーターを経由してサーバー・マシンにたどり着く。昔はこの形態が主流だったが、IPアドレスの不足やセキュリティ上の理由から減っている。代わりにファイアウォールを置く方法が一般的になっている。ファイアウォールとは、関所のようなもので、特定のサーバー上で動く特定のアプリケーションにアクセスするパケットだけ通し、それ以外のパケットを遮断する役割を持っている。
データ・センターにWebサーバーを設置する場合
プロバイダなどが運営するデータ・センターという施設にサーバーを持ち込んで設置したり、プロバイダが所有するサーバーを間借りする形で運営する場合もある。データ・センターはプロバイダの中心部分にあるNOCに直接接続されていたり、プロバイダ同士を相互接続するIXに直結されている。そのため、サーバーへのアクセスが増えたときに効果的といえる。
２ ファイアウォールの仕組みと働き
パケット・フィルタリング型が主流
様々な方法が考案されているが、価格、性能、使いやすさといった理由から、パケット・フィルタリング型が最も普及している。
パケット・フィルタリングの条件設定の考え方
アドレス変換とパケット・フィルタリングの条件設定に用いる項目には、以下の4つがある。MACヘッダー、IPヘッダー、TCPヘッダーあるいはUDPヘッダー、ヘッダーではなくICMPメッセージの中身などである。条件設定のポイントは、宛先や送信元のアドレスによって、パケットがどこからどこに流れていくのかを判断して、通すか遮断するか決めるのが第一歩である。
アプリケーションを限定するのにポート番号を使用
アプリケーションを限定するときは、TCPヘッダーやUDPヘッダーに記載されているポート番号を条件に加える（Webポートの場合80番）。
接続方向をコントロール・ビットで判断
TCPヘッダーにあるコントロール・ビットを用いて、接続方向を統制する。TCPは最初に行う接続フェーズの動作でパケットが3個流れるが、その最初のパケットだけTCPコントロール・ビットのSYNというビットが1となり、ACKというビットが0になるというしくみを活用するのである。
社内LANから公開サーバー用LANへの条件設定
公開サーバー用LANが危険な状態にさらされないよう、慎重に条件を設定しなければならない。
外から社内LANへはアクセスできない
インターネットと社内LANを行き来するパケットは、アドレス変換の設定も必要となる。アドレス変換の設定を行えば、インターネット側から社内LANへのアクセスは自然とできなくなる。
ファイアウォールを通過する
パケット・フィルタリング型のファイアウォールは、宛先IPアドレス、送信元IPアドレス、宛先ポート番号、送信元ポート番号、コントロール・ビットなどでパケットを通すか棄てるか判断する。
ファイアウォールでは防げない攻撃
ファイアウォールではパケットの流れの始点と終点を見るため、パケットの中身に問題のあるデータがあった場合などには防ぐことができない。このような場合の対処法は2つある。1つは、Webサーバー・ソフトのバグを直してダウンしないようにすること。もう1つは、パケットの中身を調べて、危険なデータが含まれている場合にパケットを遮断するような装置やソフトウェアを、ファイアウォールとは別に用意する方法である。
３ 複数サーバーにリクエストを振り分けてサーバーの負荷を分散
処理能力が不足する場合は複数サーバーで負荷分散
分散処理とは、複数のサーバーを使って処理を分担することで、サーバー1台あたりの処理量を減らす方法である。例えば、DNSサーバーで振り分ける方法がある。DNSサーバーに同じ名前でWebサーバーを複数登録しておき、DNSサーバーは問い合わせがある都度順番にIPアドレスを返すというものである（ラウンドロビン）。この方法のデメリットは、故障したサーバーを避けることができないこと、やり取りが途中で途切れてしまうことがあることである。
負荷分散装置で複数のWebサーバーに振り分け
そのような不都合を避けるために考案された機器が、負荷分散装置（ロードバランサー）である。負荷分散装置とは、DNSサーバーに負荷分散装置のIPアドレスを登録しておき、Webサーバーへのアクセスを振り分ける装置である。やり取りが複数ページにわたるかどうか（前後関係）などを調べ、一連のやり取りであれば前回と同じWebサーバーにリクエストを転送し、そうでなければ負荷の少ないWebサーバーに転送する、というように動く。
４ キャッシュ・サーバーを利用したサーバーの負荷分散
キャッシュ・サーバーの利用
キャッシュ・サーバーとは、プロキシというしくみを使って、データをキャッシュするサーバーである。プロキシとは、Webサーバーとクライアントの間に入って、Webサーバーへのアクセス動作を仲介する役割を持ったものである。アクセス動作を仲介するときに、Webサーバーから受け取ったデータをディスクに保存しておき、そのデータをWebサーバーに代わってクライアントに送り返す機能（キャッシュ）を持っている。キャッシュ・サーバーはこの機能を利用する。
キャッシュ・サーバーは更新日でコンテンツを管理
キャッシュ・サーバーは、コンテンツを一時保存し、代理で返信するというものである。更新日でコンテンツを管理することで、Webサーバーの負担が少なくなる。
プロキシの原点はフォワード・プロキシ
フォワード・プロキシとは、クライアント側に置くプロキシのことで、この方法が最初に始まった。当時のフォワード・プロキシの目的は、キャッシュの利用とファイアウォールの実現だった。つまり、プロキシでリクエスト・メッセージをいったん受け取ってインターネットに向けて転送すれば、必要なものを通すことができると考えたのである。
フォワード・プロキシを改良したリバース・プロキシ
リバース・プロキシとは、リクエスト・メッセージのURIに書いてあるディレクトリ名と転送先のWebサーバーを対応づけて設定することによって、URI部分にhttp://….と書いていない通常のリクエスト・メッセージを転送できるようにしたものである。ブラウザにプロキシを設定する必要がない。URIサーバー側に設置するキャッシュ・サーバーで採用している方式である。
トランスペアレント・プロキシ
トランスペアレント・プロキシとは、キャッシュ・サーバーで転送先を判断するために、リクエスト・メッセージのパケットのヘッダーを調べる方法である。便利なしくみだが、ブラウザからWebサーバーにリクエスト・メッセージが流れていく道筋に、トランスペアレント・プロキシを設置する必要がある。
５ コンテンツ配信サービス
コンテンツ配信サービスを利用した負荷分散
コンテンツ配信サービス（CDS：Content Delivery Service）とは、キャッシュ・サーバーを設置してそれをWebサーバー運営者に貸し出すというサービスのことである。このサービスを提供する事業者CDSP（Content Delivery Service Provider）は、主要なプロバイダと契約して、そこに多数のキャッシュ・サーバーを設置する。一方、CDSPはWebサーバー運営者とも契約して、WebサーバーとCDSPのキャッシュ・サーバーを連携させる。そのため、多数のWebサーバー運営者で共同利用することもできる。
キャッシュ・サーバーの配置場所は3種類ある。1)Webサーバーの直前（Webサーバーの負荷を抑える）、2)クライアント側（インターネットのトラフィックを抑える）、3)インターネットの縁（インターネットのトラフィックを抑えつつ、サーバー運営者はキャッシュ・サーバーを統制できる）。上記の方法は3)に当たる。
最寄りのキャッシュ・サーバーの見つけ方
DNSサーバーがWebサーバーのIPアドレスを回答するときに、最寄りのキャッシュ・サーバーのIPアドレスを回答するようDNSサーバーを細工する。ラウンドロビンではなく、クライアントとキャッシュ・サーバーの距離を判断するのである。
リダイレクト用サーバーでアクセス先を振り分ける
リダイレクトという機能を使って最寄りのキャッシュ・サーバーにアクセス先を振り向ける方法もある。リダイレクトとは、「Location」というヘッダーを用い、別のWebサーバーにアクセスするよう仕向けることである。メリットは精度が高いことで、デメリットはオーバヘッドが多いという点である。
キャッシュ内容の更新方法で性能に差が出る
キャッシュ・サーバーの効率を左右する要素には、キャッシュ内容の更新方法がある。改善方法は、Webサーバーで元データが更新されたら、それを直ちにキャッシュ・サーバーに反映する。また、毎回ページの内容が変わる部分と変わらない部分を分け、変わらない部分だけキャッシュに保存するような方法もある。
最後に
ファイアウォールとは、入ってくるパケットをチェックするもので、門番のようなものである。キャッシュ・サーバーとは、再利用できるページのデータが入っている場所で、アクセスしたページのデータがそこにあれば、Webサーバーを使わずにデータを読み出すことができる。コンテンツ配信サービスとは、インターネット全体にキャッシュ・サーバーを分散させるものである。こうしたしくみを通って、パケットはWebサーバーにたどり着く。
次回は、サーバーへの到着とブラウザへの応答についてまとめる。
 |
