コネクション受付制御のパラメータ
Webサーバにおけるコネクション受付制御方法
「第1回：コネクション受付制御とは？（http://www.thinkit.co.jp/article/118/1/）」で説明したように、ユーザーはWebサイトに対して、確実なコネクションの確立および高速な応答の双方を求めている。これらトレードオフにある要望に対し、Webサイトでは可能な限り応えていかなければならない。そこで今回は、これらの要望に応えるべくWebサーバにおいて設定可能である代表的なパラメータについて説明を行う。
対象とするWebサーバー構築ソフトウェアは、さまざまなOSに対応し最も普及しているApacheとし、バージョンは2.0とした。また、WebサーバとWebブラウザ間でリクエストおよびデータの送受信に使われるHTTP（HyperText Transfer Protocol）のバージョンは1.1とした。
Apache 2.0はマルチスレッドに対応しているが、デフォルト設定ではプロセスベース（prefork）の処理になっている。ここでは、プロセスベースで起動されていることを前提に説明する。また、サーバーパフォーマンスの向上を目的とした「MinSpareServers」や「MaxSpareServers」などのディレクティブが設定できるが、本連載ではコネクション受付制御に着目しているので説明は割愛する。
Webページ閲覧の仕組み
Webページを表示する時、視覚的にはWebページを構成するすべての情報は同時に入手され、一度に表示されているかのように見える。しかし、実際は以降で説明するように、コネクションの確立を行った後、Webページの表示に必要なファイルのダウンロードを順次行っている。つまり、Webページの情報すべてが一度に取得・表示されているわけではない。
図1にWebページが表示されるまでに起こる通信手順の流れを示す。クライアントがWebサイトを表示する際、まず、Webサーバとの間でTCPコネクションを確立しなければならない。TCPコネクションを確立する際は、3ウェイハンドシェイクと呼ばれる手順を実行しなければならない。3ウェイハンドシェイクとは、クライアントからコネクション確立要求（SYN）の送信、それを受けたサーバがコネクション確立許可（SYN+ACK）の応答、最後にクライアントからコネクション確立完了（ACK）の送信、という3つの手順によりTCPコネクションを確立するものである。
コネクションが正常に確立された後、Webブラウザは、Webサーバーとの間で情報交換を行うための通信プロトコルであるHTTPにより、WebページのHTML（HyperText Markup Language）文章の入手を試みる。
そしてHTML文章を入手したWebブラウザは、HTML文章の解析を行い画面を表示する。HTML文章の解析の結果、Webページの表示に必要となるファイルがほかにもある場合は、それらのファイルを入手するため、WebブラウザはHTTPリクエストを送信し、サーバーの応答を待ち受信し表示する。Webページ内に複数のファイルが存在している場合は、これを順次繰り返すことで、Webページのすべての情報が表示される。コネクション確立・解放をリクエストごとに行うのか否かは、HTTPのバージョンやパラメータ設定により異なる。
次ページでは、そのパラメータについて説明する。
接続可能なコネクション数を制限するMaxClients
Webサーバは、1台のクライアントからのリクエストに対してのみ、サービスを提供するのではなく、同時に複数のクライアントからのリクエストを受け入れ、サービスを提供する。したがって、接続するクライアントが増加するとリクエスト数も増加するため、応答時間が増大する可能性が高くなる。
そこで、Webサーバではクライアントに対する応答時間の増大を防止するため、同時接続可能なコネクション数の制限を行っている。Apacheにおいて、その設定を行うのが「MaxClients」ディレクティブである。デフォルト値は256に設定されている。
また、このMaxClientsに設定可能な上限値を設定するのは「ServerLimit」ディレクティブであり、デフォルト値はMaxClientsと同様に256である。当然、MaxClientsをデフォルト値より大きくする場合は、ServerLimitの設定も変更しなければならない。
MaxClients制限数を超えているときに接続してきたコネクションは、棄却されるのではなく、「ListenBacklog」ディレクティブ（デフォルト値は511）で設定した数まで処理待ちとしてキューに格納され保留状態になる。キューに格納されたコネクションは、確立中のコネクションが解放されしだい順次リクエストに応答する仕組みになっている（図2）。
コネクション数とクライアント数
ここで注意しなければならないのは、同時接続可能なコネクション数とクライアント数は等価ではないということである。一般的なWebブラウザでは複数のコネクションを確立しており、HTTP/1.1では標準2コネクションになっている。
例えば、MaxClientsで設定した値がSの場合、すべてのクライアントが2コネクションずつ確立すると、同時接続可能なクライアント数は最大S/2人となる。また、ListenBacklogで設定を行ってもOSによる制限の方が優先され、さらに、その制限はOSにより異なるので注意しなければならない。
以上で説明したように、MaxClientsにて同時コネクション数の上限を設けることにより、クライアントに対する応答時間の増大を抑えることができる。
しかし、クライアントに対する応答時間の短縮を求めるあまりMaxClientsの値を小さく設定しすぎると、サーバの処理能力に余裕があるのに棄却率が増大してしまう可能性が高くなる。
反対にMaxClientsの値を大きく設定すると、棄却率を小さく抑えることは可能だが、サーバの処理能力を超えたリクエストが到着する可能性が大きくなり、応答時間が増大してしまう。
よって、サーバが有している処理能力や提供しているWebコンテンツ、ユーザに提供したい応答時間、Webサイトとして許容できる棄却率などを考慮し値の設定を行わなければならない。
次のページでは、同一コネクションを利用した複数ファイル転送に関するKeepAliveのパラメータ設定について解説する。
コネクションを維持するKeepAlive
HTTP/1.0（RFC1945にて規格化）では、コネクションの確立を行い1つのリクエスト処理が完了すると同時にコネクションは解放される。参照したいWebページが単一のHTML文章のみで記述されている場合は、この方法でなんら問題ない。
しかし、クライアントが表示しようとしているWebページが複数のファイルで構成されている場合、そのファイルの数だけコネクションの確立・解放を繰り返すことになる。
WWWが文章ファイルのやりとりに用いられていた90年代当初は、Webページを構成するファイル数が少なかったので、コネクションの確立・解放が応答時間に与える影響はさほど大きくはなかった。
しかし、現在では多くのファイルによりWebページが構成されているため、Webページを表示する際には数多くのリクエストを送らなければならない。つまり、リクエスト1つ1つに対して3ウェイハンドシェイクを行い、コネクションの確立・解放を行っていたのでは、ネットワークやサーバに負担がかかり、応答時間の悪化を招きかねない。この問題を解決すべくHTTP/1.1（RFC2616にて規格化）から標準でサポートされた手法が「KeepAlive」である。
「KeepAlive」は、HTTP/1.1から正式に採用された機能（HTTP/1.0では拡張機能）であり、クライアント―サーバ間のコネクション維持に関する設定である。
KeepAliveを有効にするか否かの設定を行うのが、「KeepAlive」ディレクティブであり、デフォルトではONになっている。以降で説明する「KeepAliveTimeout」は「KeepAlive」が有効であることが前提であることに注意されたい。
「KeepAlive」により、1つのリクエストが完了するたびにコネクションを開放することを防ぎ、以降に示す「KeepAliveTimeout」ディレクティブで設定された条件に達するまで、コネクションを維持することができる。
つまり、コネクションの確立・解放を無駄に繰り返すことなく、確立された1つのコネクションを利用し複数のリクエストを処理することができる。よって、サーバやネットワークにかかる負担を軽減でき、応答時間の改善が期待できる。
維持する最大時間を設定するKeepAliveTimeout
「KeepAliveTimeout」は、コネクションをアイドル状態で維持できる最大時間（最後のリクエストの処理が完了してから、コネクションが解放されるまでの待ち時間）を設定するディレクティブである。
デフォルト値は15に設定されており、単位は秒である。1つのリクエストに対する応答が完了すると同時に、カウントダウンが開始される。タイムアウトになるまでの間に新たなリクエストがWebサーバーに到着すれば、Webサーバはそのコネクションを再度利用しリクエストの処理を完了させる。そして、デフォルト値の状態から再びカウントダウンが始まる。もしカウントダウン中にリクエストがサーバに到着しなければ、コネクションは解放される（図3）。
ここで問題となるのが「KeepAliveTimeout」の設定値の見積もりである。前述の「MaxClients」とも密接に関係してくることに注意していただきたい。例えばKeepAliveの時間を非常に小さくした場合を考えると、コネクションを維持することができなくなる。
よって、HTTP/1.0の時と同様、リクエストごとに3ウェイハンドシェイクの手順を行いコネクションの確立・解放を繰り返さざるを得なくなるため、応答時間の悪化を招く危険性が高くなる。しかし、リクエスト処理中のみコネクションが確立されるようになるので、無駄な空コネクションはほとんど存在しない。
つまり、コネクションを有効に利用できるので、棄却率を小さく抑えることが可能となる。反対に、大きく設定した場合は、コネクションの確立・解放を繰り返す必要がないので、応答時間は改善される。しかし、リクエスト処理が終了しても、利用されない空コネクションが維持されたままとなるので、棄却率が増大する可能性が高くなる。
次回は、「MaxClients」、「KeepAlive」の設定に密接に関係する、Webサーバの転送ファイルサイズ、新規クライアントとHTTPリクエストの到着について述べ、棄却率や応答時間に及ぼす影響について説明する。
