コネクション受付制御のパラメータ

コネクションを維持する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リクエストの到着について述べ、棄却率や応答時間に及ぼす影響について説明する。