サマリー
WEB+DB EXPRESS vol122より。前回はクライアントとサーバーを結ぶHTTPのプロトコルにいて述べた。今回はサーバー技術について述べる。尚ITインフラ技術全般に関しては“ITインフラストラクチャ技術“を参照のこと。
Webサーバー概要
Webサーバーでの基本的な処理の流れは以下のようになる。
まず、Webサーバーは常時ネットワークに接続していて、いつでもクライアントから接損を受けられるようになっている。クライアントからデータが尊信されたら、それを受信してHTTPリクエストの解析処理にデータを渡し、解析されたリクエストに応じてリスポンスデータを返す。
具体的なウェブサーバーの動作は、以下に示すようなHTTPリクエストがあったときに
POST /index.html HTTP/1.1
Host www.examle.com
Content-Type:application/x-www-form-urlencoded
name=foo以下のようなHTTPレスポンスを返す動作となる。
HTTP/1.1 200OK
Content-Type:text/html
Connection:close
<html>
<body>hello foo!!</body>
</html>具体的な実装例はwebサーバーとDBの連携にて述べる。
webサーバーの特徴として、複数のクライアントからのリクエストを同時並行で行うものがある。複数リクエストの処理には大きく分けて「prefork型」と「イベント型」の2つの種類がある。
Prefork型は、OSが持つ複数のプログラム(プロセス)を高速で切り替えてあたかも並行に動いているかのように振る舞う機能を用いて、複数クライアントからのリクエストを同時並行で処理する機能となる。このときwebサーバーは複数のプロセスを生成して、一つのプロセスが一つのコネクションを処理するものとなる。プロセスの切り替えはOSがやってくれるので、Webサーバーはそれぞれのプロセスで自分が担当しているリクエストの処理だけを担当すればよい。prefork型を採用している代表的なサーバーにはApache HTTP Serverがある。Apacheサーバーの詳細と具体的な実装は”ApacheサーバーとLAMPのインストールと動作“にて述べる。
prefork型はプロセスを使って処理するために、多くのリクエストを同時に処理するためには多くのプロセスを立ち上げる必要がある。プロセスの数がや役なるとOSによるプロセス切り替えの割合が増えて、コンピューターの処理に時間がかかる問題(C10K問題:クライアント1万台問題)が生じる。
上記の問題を解決するために、一つのプロセスで複数のリクエストを処理するようにしたものが「イベント駆動型」となる。
イベント駆動型では、一つのプロセスで複数のリクエストを処理するため非同期I/Oを用いる。これはネットワークやディスクへのアクセスなどCPUから見ると低速なデータのやりとりの待ち時間に別の処理を実行すると言うもので、このしくみにより高速な動作が可能となった。イベント駆動を採用している代表的なWebサーバーにnginxがある。nginxの詳細と具体的な実装に関しては”nginxサーバーの概要とインストール“にて述べる。
HTTPは元来サーバー上にあるHTMLを返すためのプロトコルとして実装されてきた。そのため同じリクエストに対しては毎回同じレスポンスを返すのが基本的な動作となる。ところがwebが発展してくるにつれて、同じリソースに対してのリクエストでも状況に応じて返すレスポンスを変更したいと言う要求が増えてきた。例えばECサイトを作った時のカートの商品んの保持に対して、内容を変更するようなものでは、中身がユーザーごとに変わるので同じリソースへのアクセスでも表示する内容を変える必要が出る。
上記のようなものを動的コンテンツを配信するWebサーバーと呼ぶ。
これら対して毎回同じリソースを返すものを静的コンテンツを配信する静的Webサーバーと呼ぶ。元来Webサーバーはこの静的コンテンツを返すために実装されてきた。この静的コンテンツは返すコンテンツが最初から決まっているので、オリジナルのWebサーバーが返さず別のサーバーが返すことでも成立する。これらの方式としてHTTPのリスポンスのCahe-Controlヘッダーフィールドでキャッシュさせたり、CDNを使うものがある。
CDN(Contents Delivery Network)は静的コンテンツを効率よく配信するためのシステムを使ったサービスで、CDNを提供する業者は、インターネット上の色々な場所にWebサーバーを持ち、サーバーを分散させることで大量ユーザーからのアクセス集中を回避して負荷分散したり、近くのサーバーからユーザーにアクセスさせることですばやく目的のコンテンツを取得できるようにする。SDNはAkamaiやFastlyのように専門で提供する業者があったり、AWSのCloudFrontのようにクラウドサービス上で提供されているものがある。
これに対して動的コンテンツの配信の場合には、効率的な処理を行う方法として(1)Webサーバー自体に動的な処理を入れる。(2)Webサーバーが動的処理を行うプログラムと連携する。の2つがある。(1)の代表的なのはSSI(Server Side Includes)だが、現在はほとんど使われていない。(2)の方式にはいつくかの手法がある。
上記の手法の一つがCGI(Common Gateway Interface)で、現在はほとんど利用されていないが初期のサーバーにおいて外部プログラムと連携するための機能として実装されていたものとなる。CGIは外部プログラムと標準入出力をやりとりして動的コンテンツを提供できるようにしたもので、リスエストのたびに毎回プログラムをきどうさせる方式となる。そのためアクセスが増えると高速に処理できないと言う問題が生じた。
上記の問題を解決するためにApacheモジュールを使った方式が開発された。ApacheモジュールはPerlやPHPという言語処理系で実装されたものだが、prefork型となっているため、よりスケールしたケースに利用できないと言う問題が生じた。
上記の問題を解決するために、FastCGIが登場した。CGIの問題点は、リクエストごとにプログラムが起動することによる速度低下であった為、毎回プログラムを起動するのではなく、Webサーバーと外部プログラムの接続を維持したまま常駐させることで速度低下を改善したものがFastCGIとなる。
FastCGIでは、Webサーバーと外部プログラムはINIXドメインソケットという技術や、ローカルでのTCP/IPを使って通信する。外部プログラムはWebサーバーと同じように常駐しつづて、いつでもリスエストに答えられるように動作する。webサーバーと外部プログラムの接続も維持し続けて接続された状態も保つものとなる。
HTTPでサーバーからのレスポンスを中継し、コンテンツのキャッシュやフィルタリングをするサーバーをプロキシと呼び、これと逆方向(クライアンとからのリクエストを中継し、内部のサーバーにリクエストリレーする)に行うものをリバースプロキシと呼ぶ。
近年はこのHTTPを使ってアプリケーションレイヤーで動作するリバースプロキシをつかって、Webサーバーと外部プログラムの連携をするケースが増えている。
WebアプリケーションのフレームワークようにWSGI/Rack/PSGIのようなWebサーバーとつなげるインターフェースが登場し、これによりWebアプリケーションをHTTPサーバーとして動作させることが容易になってきたため、専用の仕組みであるFastCGIではなく、既存の仕組みであるHTTPを使ってWebサーバーと連携することが可能となる。
WebサーバーのOSSの実装としてはLinuxによるものが著名となる。
次回はブラウザとHTML、CSS、JavaScriptについて述べる。
コメント
[…] 次回はWebサーバーについて述べる。 […]
[…] WEB+DB EXPRESS vol122より。前回はWebサーバーについて述べた。今回はブラウザとHTML、CSS、Javascriptについて述べる。 […]
[…] Linuxディストリビューションには、様々なサーバーソフトウェアが標準で装備されている。以下に代表的なサーバーソフトウェアを示す。 […]
[…] Webサーバー概要 […]
[…] Webサーバー概要 […]
[…] Webサーバー概要 […]