Loading article…
ウェブサーバーは、 HTTP（ウェブコンテンツを配信するために作成されたネットワークプロトコル）またはその安全なバリアントであるHTTPSを介してリクエストを受け付けるコンピュータソフトウェアです。ユーザーエージェント（一般的にはウェブブラウザまたはウェブクローラー）は、HTTPを使用してウェブページまたはその他のリソースをリクエストすることで通信を開始し、サーバーはそのリソースのコンテンツまたはエラーメッセージで応答します。ウェブサーバーは、そのように設定されている場合、ユーザーエージェントから送信されたリソースを受け入れて保存することもできます。[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
ウェブサーバーを実行するために使用されるハードウェアは、処理する必要のあるリクエストの量に応じて異なります。範囲の下限は、構成インターフェースとして小型ウェブサーバーを実行するルーターなどの組み込みシステムです。トラフィックの多いインターネットウェブサイトは、高速コンピューターのラック上で動作する数百台のサーバーでリクエストを処理する場合があります。[ 6 ]
ウェブサーバーから送信されるリソースは、ウェブサーバーが既に用意しているファイル（静的コンテンツ）である場合もあれば、サーバーソフトウェアと通信する別のプログラムによってリクエスト時に生成されるファイル（動的コンテンツ）である場合もある。前者は通常、より高速に配信でき、繰り返しリクエストが発生した場合でもキャッシュしやすい一方、後者はより幅広いアプリケーションに対応できる。
HTTPを基盤とした一般的なコンピュータ間通信を行うRESTやSOAPといった技術、そしてWebDAV拡張機能のサポートにより、Webサーバーの用途は、人間が読めるページを提供するという本来の目的をはるかに超えて拡大した。
これはウェブサーバープログラムの非常に簡潔な歴史であるため、一部の情報はウェブブラウザ、ワールドワイドウェブ、インターネットの歴史と必然的に重複します。したがって、明確さと理解しやすさのために、以下に報告する重要な歴史情報の一部は、上記の1つ以上の歴史記事にも見られるものと類似している可能性があります。[ 7 ]
1989年3月、ティム・バーナーズ＝リー卿は、ハイパーテキストシステムを使用して科学者間の情報交換を容易にすることを目的とした新しいプロジェクトを雇用主であるCERNに提案しました。 「ハイパーテキストとCERN」と題されたこの提案はコメントを求め、数人が読みました。1990年10月、この提案は（ロバート・カイリューを共著者として）再構成され、内容が充実し、最終的に承認されました。[ 8 ] [ 9 ] [ 10 ]
1990年後半から1991年初頭にかけて、このプロジェクトによりバーナーズ＝リーと彼の開発者たちは、いくつかのソフトウェアライブラリと3つのプログラムを作成およびテストし、それらは当初NeXTワークステーションにインストールされたNeXTSTEP OS上で動作しました。[ 11 ] [ 12 ] [ 10 ]
初期のブラウザは、HTTP 0.9と呼ばれる新しい基本的な通信プロトコルを使用して、ウェブサーバーからシンプルな初期の HTML 形式で書かれたウェブページを取得していました。
1991年8月、ティム・バーナーズ＝リーはWWW技術の誕生を発表し、科学者たちにその採用と開発を奨励した。[ 13 ]その後まもなく、これらのプログラムはソースコードとともに、その利用に関心のある人々に公開された。[ 11 ]ソースコードは正式にライセンスされたりパブリックドメインに置かれたりはしなかったが、CERNは非公式にユーザーや開発者が実験したり、その上でさらに開発したりすることを許可した。バーナーズ＝リーは、これらのプログラムの採用と利用、および他のオペレーティングシステムへの移植を推進し始めた。[ 10 ]
1991年12月、ヨーロッパ以外で最初のウェブサーバーがSLAC （米国）に設置されました。[ 12 ]これは、ウェブブラウザとウェブサーバー間の大陸を越えたウェブ通信を開始したため、非常に重要な出来事でした。
1991年から1993年にかけて、CERNのウェブサーバープログラムはwwwグループによって活発に開発され続け、そのソースコードとHTTPプロトコルの公開仕様のおかげで、他の多くのウェブサーバーの実装が開発され始めた。
1993年4月、CERNは、Webソフトウェアの3つのコンポーネント（基本的なラインモードクライアント、Webサーバー、共通コードライブラリ）とそのソースコードをパブリックドメインに置くという公式声明を発表しました。[ 14 ]この声明により、Webサーバー開発者は、そのソースコードに基づく派生作品の開発に関するあらゆる法的問題（実際には存在しなかった脅威）から解放されました。
1994年初頭、新しいWebサーバーの中で最も注目を集めたのはNCSAのhttpdでした。これは様々なUnix系OS上で動作し、HTTPメソッドとCGIを実装することで外部プログラムと通信し、動的に生成されたコンテンツを提供することができました。これらの機能に加え、NCSAのMosaicブラウザのマルチメディア機能（Webサーバーにデータを送信するためにHTMLフォームを管理することもできた）は、出版や分散コンピューティングアプリケーションにおけるWebテクノロジーの可能性を際立たせました。POST
1994 年後半、NCSA httpd の開発は停滞し、外部のソフトウェア開発者、ウェブマスター、その他このサーバーに関心のある専門家グループが、 NCSA httpd のソースコードがパブリックドメインで利用可能になったおかげでパッチの作成と収集を開始しました。1995 年初頭、これらのパッチはすべて NCSA ソースコードの最終リリースに適用され、いくつかのテストの後、Apache HTTP サーバープロジェクトが開始されました。[ 17 ] [ 18 ]
1994年末、Netsiteという名の新しい商用ウェブサーバーが、特定の機能を備えてリリースされた。これは、 Netscape、Sun Microsystems、そして最終的にはOracle Corporationによって開発された、数多くの類似製品の最初のものであった。
1995年半ば、マイクロソフトはWindows NT OS向けにIISの最初のバージョンをリリースしました。これは、ワールドワイドウェブ技術の分野において、ウェブの両側（クライアント側とサーバー側）で重要な役割を果たしてきた、そして現在も果たし続けている商用開発者兼ベンダーの参入を意味しました。
1995年後半、CERNとNCSAのウェブサーバーは、開発サイクルがはるかに速く、機能が多く、修正が多く、パフォーマンスも向上した新しいウェブサーバーが広く採用されたため、（世界全体の利用率において）減少に転じた。
1996年末には、インターネットドメイン名を所有したりウェブサイトをホストしたりしたい人なら誰でも利用できる、50種類以上の異なるウェブサーバーソフトウェアプログラムが既に存在していた。[ 20 ]その多くは短命に終わり、他のウェブサーバーに取って代わられた。
HTTP/1.0（1996年）およびHTTP/1.1（1997年、1999年）プロトコルバージョンに関するRFCの公開により、ほとんどのWebサーバーは（必ずしも完全ではないものの）これらの標準に準拠せざるを得なくなった。TCP/IPの永続接続（HTTP/1.1）の使用により、Webサーバーは同時接続の最大数を増やすとともに、スケーラビリティを向上させる必要が生じた。
1996年から1999年にかけて、Netscape Enterprise ServerとMicrosoftのIISが主要な商用オプションとして台頭した一方、無料で利用できるオープンソースプログラムの中では、Apache HTTP Serverが（その信頼性と豊富な機能のため）好ましいサーバーとしてトップの座を維持した。
当時、Zeus（現在はサービス終了）という別の商用ウェブサーバーも存在し、利用率は低かったものの、少なくとも2000年代前半までは、市場で入手可能なウェブサーバーの中で最も高速で拡張性の高いものの1つとして知られていた。
Apacheは1996年半ばから2015年末まで最も利用されたWebサーバーでしたが、数年間の衰退の後、最初はIISに、次にNginxに追い抜かれました。その後、IISの利用率はApacheよりもはるかに低い割合にまで低下しました（市場シェアも参照）。
2005年から2006年にかけて、Apacheは新しいパフォーマンス機能（イベントMPMや新しいコンテンツキャッシュなど）を導入することで、速度と拡張性のレベルを向上させ始めました。[ 21 ] [ 22 ]これらの新しいパフォーマンス改善は当初実験的なものとしてマークされていたため、長期間ユーザーによって有効化されず、その結果、Apacheは商用サーバー、そして何よりも他のオープンソースサーバーとの競争にさらに苦しむことになりました。これらの他のオープンソースサーバーは、開発開始当初から（主に静的コンテンツの提供時）はるかに優れたパフォーマンスを達成しており、Apacheが衰退した時点では、十分にテストされた高度な機能の長いリストも提供できていました。
2000年以降数年経つと、LiteSpeedなどの商用で競争力の高いウェブサーバーだけでなく、 Hiawatha、Cherokee HTTPサーバー、lighttpd、nginxなどの多くのオープンソースプログラムや、商用サポート付きの派生製品や関連製品も登場した。
2007～2008年頃、ほとんどの人気ウェブブラウザは、ホストドメインごとに2つの永続接続という以前のデフォルトの制限（RFC-2616で推奨されている制限）[ 23 ]を、ホストドメインごとに4、6、または8つの永続接続に増やしました。これは、画像が多い重いウェブページの取得を高速化し、ウェブページ内のイベントの双方向通知に使用される動的オブジェクト専用の永続接続の不足の問題を軽減するためです。[ 24 ] 1年以内に、これらの変更により、ウェブサーバーが管理しなければならない永続接続の最大数は平均でほぼ3倍になりました。この傾向（永続接続数の増加）は、間違いなく、低速なウェブサーバーの前にリバースプロキシを採用する大きな推進力となり、また、多くのハードウェアリソース（多数のCPU 、RAM 、高速ディスクを備えた高価なコンピュータ）を必要とせずに、その速度と非常に多くの同時接続を処理する能力をすべて発揮できる新しいウェブサーバーにもう1つの機会を与えました。[ 25 ]
2015年にRFCは新しいプロトコルバージョン[HTTP/2]を公開したが、新しい仕様の実装は決して容易ではなかったため、あまり人気のないWebサーバー（例えば、使用率が1%～2%未満）の開発者の間で、その新しいプロトコルバージョンのサポートを追加するかしないかというジレンマが生じた。[ 26 ] [ 27 ]
実際、HTTP/2 をサポートするには、多くの要因 (ほぼ常に暗号化された接続が必要、同じ TCP ポートで HTTP/1.x と HTTP/2 接続を区別する機能、HTTP メッセージのバイナリ表現、メッセージの優先度、HTTP ヘッダーの圧縮、TCP/IP サブ接続としても知られるストリームの使用、および関連するフロー制御など) により、内部実装に根本的な変更が必要になることが多く、そのため、これらの Web サーバーの開発者の一部は、次の主な理由から、新しい HTTP/2 バージョンをサポートしないことを選択しました(少なくとも近い将来は)。[ 26 ] [ 27 ]
その代わりに、最も人気のあるウェブサーバーの開発者たちは、新しいプロトコルの提供に急いだ。それは、彼らに人員と時間があったからだけでなく、通常、以前のSPDYプロトコルの実装を起点として再利用できたこと、そして、最もよく使われているウェブブラウザが同じ理由でそれを非常に迅速に実装したからでもある。開発者たちが迅速に行動するきっかけとなったもう 1 つの理由は、ウェブマスターがウェブ トラフィックの増加によるプレッシャーを感じており、TCP/IP 接続の数を大幅に減らし、ホストされている Web サイトへのアクセスを高速化できるものをできるだけ早くインストールして試したいと強く望んでいたからである。[ 28 ]
2020年から2021年にかけて、 HTTP/3プロトコルに関する将来のRFCの高度なドラフトが公開された後、主要なWebサーバーや人気のあるWebブラウザによるHTTP/2の実装に関する動向が部分的に再現された。
以下の技術概要は、ウェブサーバーに実装可能な機能や、ウェブサーバーが実行可能なタスクについて、ごく限られた例をいくつか示すことで、このテーマに関する十分な範囲のシナリオを提示しようとする試みとしてのみ捉えるべきです。
ウェブサーバープログラムは、クライアント・サーバーモデルにおいてサーバーとしての役割を果たし、HTTPプロトコルの1つ以上のバージョンを実装します。多くの場合、HTTPSのセキュリティ保護版や、計画された用途に役立つと考えられるその他の機能や拡張機能が含まれます。
ウェブサーバープログラムの複雑さと効率は、以下の要因によって大きく異なる場合があります。[ 1 ]
ウェブサーバープログラムは実装方法に違いがあるものの、そのほとんどが以下の共通機能を備えている。
これらは、ほとんどのウェブサーバーが通常備えている基本的な機能です。
その他、より高度で人気のある機能（ごく一部ですが）は以下のとおりです。
ウェブサーバープログラムは、実行中は通常、いくつかの一般的なタスクを実行します。[ 1 ]
Webサーバープログラムには以下の機能があります。[ 29 ] [ 30 ] [ 31 ]
HTTPリクエストメッセージがデコードされ検証されると、その値を使用して、そのリクエストを満たすことができるかどうかを判断できます。これには、セキュリティチェックを含む多くの手順が必要です。
Webサーバープログラムは通常、以下の目的で何らかのURL正規化（ほとんどのHTTPリクエストメッセージに含まれるURLの正規化）を実行します。
URL正規化とは、URLを統一的な方法で変更・標準化するプロセスを指します。正規化にはいくつかの種類があり、スキームやホストを小文字に変換することなどが含まれます。最も重要な正規化としては、パスセグメント「.」と「..」の削除、および空でないパス要素への末尾スラッシュの追加などが挙げられます。
URL マッピングとは、Web サーバーまたはアプリケーション フレームワークが、受信した URL リクエストを適切なリソース、ハンドラー、またはアクションにルーティングする方法を決定するプロセスです。最新の URL マッピング メカニズムは、要求された URL の構造を分析し、ルーティング ルールまたは構成パターンを使用して、ファイルシステム パスに直接依存することなく、静的リソースを配信したり、動的ハンドラーを呼び出したり、書き換えやリダイレクトを実行したりします。このアプローチにより、クリーンで人間が読みやすい URL と柔軟なアプリケーション アーキテクチャが実現します。[ 32 ]
実際には、単純な静的コンテンツ配信（URL書き換えエンジン、動的コンテンツ配信など）を超えた高度な機能を実装するWebサーバープログラムは、通常、そのURLを次のように処理する必要があるかどうかを判断する必要があります。
ウェブサーバーの1つ以上の設定ファイルでは、 URLパスの一部（ファイルパスの先頭部分、ファイル名の拡張子、その他のパスコンポーネントなど）を特定のURLハンドラ（ファイル、ディレクトリ、外部プログラム、内部モジュール）にマッピングするように指定できます。[ 33 ]
ウェブサーバーが上記の高度な機能の 1 つ以上を実装する場合、有効な URL のパス部分は、動的なリクエストのための内部または外部モジュールプロセッサの仮想名を参照する可能性があるため、ウェブサイトのディレクトリツリー内の既存のファイルシステムパス (ファイルシステム内のファイルまたはディレクトリ) と常に一致するとは限りません。
Webサーバープログラムは、物理ファイルシステムパスを参照するURLパス（全部または一部）を、ターゲットWebサイトのルートディレクトリ下の絶対パスに変換することができます。 [ 33 ]
ウェブサイトのルートディレクトリは、設定ファイルまたはウェブサーバーの内部ルールによって、HTTPクライアントリクエストに含まれるURLのホスト部分であるウェブサイト名を使用して指定されることがあります。 [ 33 ]
以下の種類のWebリソースについては、ファイルシステムへのパス変換が行われます。
ウェブサーバーは、リクエストされたURL（HTTPリクエストメッセージ）に含まれるパスを、（ホスト）ウェブサイトのルートディレクトリのパスに追加します。Apacheサーバーでは、これは通常次のようになります/home/www/website（Unixマシンでは通常次のようになります/var/www/website）。結果の例を以下に示します。
静的ファイルリクエストのURLパス変換
次のURLで指定された既存ファイルに対する静的リクエストの例：
http://www.example.com/path/file.htmlクライアントのユーザーエージェントは接続しwww.example.com、次のHTTP /1.1リクエストを送信します。
GET /path/file.html HTTP/1.1 Host: www.example.com Connection: keep-alive
その結果として得られるのが、ローカルファイルシステムのリソースです。
/home/www/www.example.com/path/file.htmlウェブサーバーは、ファイルが存在する場合はそれを読み込み、クライアントのウェブブラウザに応答を送信します。応答にはファイルの内容を記述した説明とファイル自体が含まれるか、ファイルが存在しないかアクセスが禁止されていることを示すエラーメッセージが返されます。
ディレクトリリクエストのURLパス変換（静的インデックスファイルなし）
次のURLで指定された既存ディレクトリに対する暗黙的な動的リクエストの例：
http://www.example.com/directory1/directory2/クライアントのユーザーエージェントは接続しwww.example.com、次のHTTP /1.1リクエストを送信します。
GET /directory1/directory2 HTTP/1.1 Host: www.example.com Connection: keep-alive
結果として得られるのは、ローカルディレクトリのパスです。
/home/www/www.example.com/directory1/directory2/ウェブサーバーはまずディレクトリの存在を確認し、存在してアクセス可能な場合はインデックスファイル（この場合は存在しない）を探し、ディレクトリ一覧表示専用の内部モジュールまたはプログラムにリクエストを渡します。そして、出力されたデータを読み取ってクライアントのウェブブラウザにレスポンスを送信します。レスポンスにはディレクトリの内容（含まれるサブディレクトリとファイルのリスト）が表示されるか、ディレクトリが存在しないかアクセスが禁止されていることを示すエラーメッセージが返されます。
動的プログラムリクエストのURLパス変換
動的なリクエストの場合、クライアントによって指定された URL パスは、Web サーバーが動的コンテンツを生成するために使用する既存の外部プログラム (通常は CGI を含む実行可能ファイル) を参照する必要があります。[ 34 ]
プログラムファイルを使用して出力を生成する動的リクエストの例：
http://www.example.com/cgi-bin/forum.php?action=view&orderby=thread&date=2021-10-15クライアントのユーザーエージェントは接続しwww.example.com、次のHTTP /1.1リクエストを送信します。
GET /cgi-bin/forum.php?action=view&ordeby=thread&date=2021-10-15 HTTP/1.1 Host: www.example.com Connection: keep-alive
結果として得られるのは、プログラムのローカルファイルパスです（この例ではPHPプログラム）。
/home/www/www.example.com/cgi-bin/forum.phpウェブサーバーは、パス情報とクエリ文字列action=view&orderby=thread&date=2021-10-15を渡してそのプログラムを実行し、プログラムが実行に必要な情報を取得します。（この場合、2021年10月15日以降のフォーラム投稿をスレッド順に表示したHTMLドキュメントが返されます。）さらに、ウェブサーバーは外部プログラムから送信されたデータを読み取り、リクエストを行ったクライアントにそのデータを再送信します。
リクエストが読み取られ、解釈され、検証された後は、そのメソッド、URL、およびHTTPヘッダーの値を含む可能性のあるパラメータに応じて管理する必要があります。
実際には、Webサーバーはこれらの応答パスのいずれかを使用してリクエストを処理する必要があります。[ 33 ]
OPTIONSリクエストに、Webサーバーの一般的なコードで処理できるメソッド（例：）が含まれている場合、成功レスポンスが送信されます。ウェブサーバープログラムが静的コンテンツを配信できる機能を持ち、そのように設定されている場合、リクエストメッセージに、ウェブサイトのルートディレクトリの下にある既存ファイルのURLパス（URLマッピング、URL変換、URLリダイレクト後）と一致する有効なURLパスがあり、かつそのファイルにウェブサーバープログラムの内部ルールで要求される属性と一致する属性がある場合、ファイルコンテンツを送信することができます。[ 33 ]
そういったコンテンツは、通常、Webサーバーがクライアントに送信する際に変更されないこと、そして何らかのプログラムによって変更（ファイル変更）されるまで同じ状態を維持することから、静的コンテンツと呼ばれます。
注:静的コンテンツのみを提供する場合、Webサーバープログラムは通常、提供されるWebサイトのファイルの内容を変更しません(読み取りのみで書き込みは行われないため)。したがって、以下のHTTPメソッドのみをサポートすれば十分です。
OPTIONSHEADGET静的ファイルコンテンツの応答速度は、ファイルキャッシュによって向上させることができます。
ウェブサーバープログラムが、パスが既存のディレクトリのいずれかと一致するURLを含むクライアント要求メッセージを受信し、そのディレクトリにアクセス可能で、ディレクトリインデックスファイルの提供が有効になっている場合、ウェブサーバープログラムは、そのディレクトリ内で見つかった既知の（または設定された）静的インデックスファイル名（通常のファイル）の最初のものを提供しようとする場合があります。インデックスファイルが見つからない場合、またはその他の条件が満たされない場合は、エラーメッセージが返されます。
静的インデックスファイルで最もよく使われる名前は、、index.htmlおよびindex.htmですDefault.htm。
ウェブサーバープログラムが、パスが既存ファイルのファイル名と一致するURLを含むクライアント要求メッセージを受信し、そのファイルがウェブサーバープログラムからアクセス可能であり、かつその属性がウェブサーバープログラムの内部ルールに一致する場合、ウェブサーバープログラムはそのファイルをクライアントに送信できます。
通常、セキュリティ上の理由から、ほとんどのウェブサーバープログラムは、通常のファイルのみを提供するか、デバイスファイルなどの特殊なファイルタイプや、それらへのシンボリックリンクやハードリンクの使用を避けるように事前に設定されています。これは、静的ウェブ リソースを提供する際に望ましくない副作用を回避するためです。[ 35 ]
ウェブサーバープログラムが動的コンテンツを提供できる機能を持ち、そのように構成されている場合、クライアント要求のパラメータを渡すために、適切な内部モジュールまたは外部プログラム（要求された URL パスに関連付けられている）と通信することができます。その後、ウェブサーバープログラムは、そこからデータ応答（多くの場合、その場で生成されたもの）を読み取り、要求を行ったクライアントプログラムに再送信します。[ 36 ]
注:静的コンテンツと動的コンテンツを配信する場合、Web サーバー プログラムは通常、クライアントからデータを安全に受信できるように、次の HTTP メソッドもサポートする必要があります。これにより、Web サーバー、外部プログラム、またはモジュールに大量のデータセット (たとえば、大量のデータ入力やファイルのアップロード)を送信する可能性のあるインタラクティブ フォームを備えた Web サイトもホストできるようになります。
POST内部モジュールや外部プログラムと通信できるようにするには、Webサーバープログラムは、利用可能な多数のゲートウェイインターフェースのうち1つ以上を実装している必要があります（動的コンテンツに使用されるWebサーバーゲートウェイインターフェースも参照）。
標準的で従来から使用されている3つのゲートウェイインターフェースは以下のとおりです。
ウェブサーバープログラムは、ファイルとサブディレクトリのディレクトリインデックスリストを動的に（オンザフライで）生成する機能を備えている可能性がある。 [ 37 ]
ウェブサーバープログラムがそのように設定されており、要求されたURLパスが既存のディレクトリと一致し、そのディレクトリへのアクセスが許可されており、かつそのディレクトリ内に静的インデックスファイルが見つからない場合、上記のディレクトリ内のファイルまたはサブディレクトリのリストを含むウェブページ（通常はHTML形式）が動的に（その場で）生成されます。生成できない場合はエラーが返されます。
一部のウェブサーバープログラムは、ウェブページテンプレート（プレースホルダー（例：$(FILE_NAME), $(FILE_SIZE)、など）を含むHTMLドキュメント）の使用を許可することによってディレクトリ一覧のカスタマイズを可能にします。これらのプレースホルダーは、ウェブサーバーによってディレクトリ内で見つかった各ファイルエントリのフィールド値に置き換えられます（例：）。index.tplまた、解釈および実行されるHTMLと埋め込みソースコードの使用（例：、index.asp）や、CGI、SCGI、FCGIなどの動的インデックスプログラムの使用をサポートすることによってもカスタマイズが可能です（例：index.cgi、、、index.php）index.fcgi。
動的に生成されるディレクトリ一覧の使用は、静的なインデックスページを送信するよりもはるかに多くのOSリソースを消費するため、通常は避けられるか、Webサイトのごく一部のディレクトリに限定されます。
ディレクトリ一覧の主な用途は、要求するユーザーにさらなる情報を提供する必要なく、ファイル（通常、ファイル名、サイズ、更新日時、ファイル属性がランダムかつ頻繁に変更される場合）をそのままダウンロードできるようにすることです。[ 38 ]
外部プログラムまたは内部モジュール（処理ユニット）は、1つまたは複数のデータリポジトリからデータを取得したり、1つまたは複数のデータリポジトリにデータを保存したりするために使用できる何らかのアプリケーション機能を実行できます。
処理ユニットは、データリポジトリから取得したデータを使用して、あらゆる種類のウェブコンテンツを返すことができます。
実際には、クライアントのリクエストや設定に含まれる1つ以上のパラメータに応じて変化する可能性のあるコンテンツがある場合、通常は動的に生成されます。
Webサーバープログラムは、クライアントのリクエストメッセージへの応答としてレスポンスメッセージを送信することができます。[ 29 ]
リクエストメッセージが正常に読み取れなかったり、デコードできなかったり、解析できなかったり、実行できなかったりした場合、エラー応答メッセージが送信されることがあります。[ 30 ]
注：以下のセクションは、Webサーバーがおおまかにどのような動作をするのかを理解するのに役立つ例としてのみ記載されています。これらのセクションは、決して網羅的でも完全でもありません。
ウェブサーバープログラムは、クライアントからのリクエストメッセージに対して様々な種類のエラーメッセージを返すことがありますが、これらのエラーは主に2つのカテゴリに分類されます。
クライアントブラウザがエラー応答またはエラーメッセージを受信した場合、それがメインのユーザー要求（例えば、ウェブページなどのウェブリソースのURL）に関連している場合は、通常、そのエラーメッセージがブラウザのウィンドウまたはメッセージに表示されます。
ウェブサーバープログラムは、要求されたURLパスが正しいかどうかを検証できる可能性があります。[ 41 ]
認証またはアクセス権限機能が実装され有効化されているにもかかわらず、Webリソースへのアクセスが許可されない場合、必要なアクセス権限に応じて、Webサーバープログラムが次の処理を実行します。
ウェブサーバープログラムは、新しいURL（新しい場所）へのURLリダイレクトを行う機能を備えている場合があります。これは、クライアントのリクエストメッセージに対して、有効な既存のウェブリソースにアクセスするのに適した新しいURLを含むレスポンスメッセージで応答することによって行われます（クライアントは新しいURLを使用してリクエストを再送信する必要があります）。[ 42 ]
場所のURLリダイレクトが使用されています: [ 42 ]
例1：URLパスがディレクトリ名を指しているが、末尾にスラッシュ「/」がないため、Webサーバーはクライアントにリダイレクトを送信し、修正されたパス名でリクエストをやり直すように指示します。[ 37 ]
差出人: 宛先: /directory1/directory2 /directory1/directory2/
例2：ファイルシステムのパスを再編成するために、一連のドキュメント全体がウェブサイト内で移動されました。
差出人: 宛先: /directory1/directory2/2021-10-08/ /directory1/directory2/2021/10/08/
例3：一連の文書全体が新しいウェブサイトに移動され、それらにアクセスするには安全なHTTPS接続を使用することが必須となった。
差出人: 宛先: http://www.example.com/directory1/directory2/2021-10-08/ https://docs.example.com/directory1/2021-10-08/
上記の例は、考えられるリダイレクトの種類のごく一部にすぎません。
ウェブサーバープログラムは、有効なクライアント要求メッセージに対して、要求されたウェブリソースデータを含む成功メッセージで応答することができる。[ 43 ]
Webリソースデータがクライアントに返送される場合、そのデータは取得方法（ファイルから、または何らかのプログラムやモジュールの出力から）に応じて、静的コンテンツにも動的コンテンツにもなり得る。
平均HTTP応答時間とハードウェアリソースの使用を削減することでWebサーバーの応答を高速化するために、多くの一般的なWebサーバーは、それぞれがコンテンツカテゴリに特化した1つ以上のコンテンツキャッシュを実装しています。[ 44 ] [ 45 ]
コンテンツは通常、その発信元によってキャッシュされます。
歴史的に、頻繁にランダムかつ迅速にアクセスする必要のあるファイル内の静的コンテンツは、1960年代中後半から1970年代にかけて、主に電気機械式ディスクに保存されてきました。残念ながら、これらのデバイスからの読み書きは、RAMの速度と比較すると常に非常に遅い操作と考えられていました。そのため、初期のOSから、まずディスクキャッシュ、次にOSファイルキャッシュサブシステムが開発され、頻繁にアクセスされるデータのI/O操作を高速化しました。
OSのファイルキャッシュの助けがあっても、ディスクに保存されているディレクトリやファイルに関わるI/O操作の相対的または一時的な遅さは、特に1990年代半ばから後半にかけて、インターネットやネットワーク回線の速度が絶えず向上するにつれてWebインターネットトラフィックが指数関数的に増加し始めた頃から、トップレベルのWebサーバーに期待されるパフォーマンス向上のボトルネックとなった。
静的ファイルの配信をさらに効率的に高速化し、1秒あたりのリクエスト数またはレスポンス数（RPS）を最大化する方法についての問題は、Webサーバープログラムに実装できる有用なキャッシュモデルを提案することを目的として、1990年代半ばから研究され始めました。[ 46 ]
実際には、今日では多くのウェブサーバープログラムが、ウェブサーバーの使用に合わせて調整され、独自の実装とパラメータを使用する独自のユーザーランドファイルキャッシュを含んでいます。 [ 47 ] [ 48 ] [ 49 ]
RAIDや高速ソリッドステートドライブ（非常に高速なI/O速度を持つストレージハードウェア）の普及により、Webサーバーにファイルキャッシュを組み込むことの利点は若干減少しましたが、もちろん完全にはなくなりました。
内部モジュールまたは外部プログラムによって出力される動的コンテンツは、（キーまたはパラメータを持つ一意の URL が与えられた場合）必ずしも頻繁に変更されるとは限らないため、結果として得られる出力は、しばらくの間（たとえば、1 秒から数時間以上）、RAM または高速ディスクにキャッシュされる可能性があります。[ 50 ]
動的キャッシュの典型的な使用例は、ニュース、天気、画像、地図などに関する動的なウェブページが頻繁に変更されない（たとえば、 n分ごと）ウェブサイトにあり、毎分毎時間膨大な数のクライアントがアクセスする場合です。このような場合、クライアントは要求されたコンテンツの最新のコピーをブラウザのキャッシュに持っていないことが多いため、キャッシュされたコンテンツも返すことが有用です（内部モジュールや外部プログラムを呼び出すことなく）。[ 51 ]
いずれにせよ、ほとんどの場合、そのようなキャッシュは外部サーバー（リバースプロキシなど）によって実装されるか、Webサーバーとハードウェアリソース（CPU、RAM、ディスク）を競合しないように、動的なデータ出力を別のコンピューターに保存し、特定のアプリケーション（memcachedなど）によって管理されます。[ 52 ] [ 53 ]
ウェブサーバーソフトウェアは、OSに組み込まれてカーネル空間で実行される場合と、（他の通常のアプリケーションと同様に）ユーザー空間で実行される場合がある。
カーネルモードで動作するWebサーバー（通常はカーネル空間Webサーバーと呼ばれる）は、カーネルリソースに直接アクセスできるため、理論的にはユーザーモードで動作するWebサーバーよりも高速になる可能性がある。しかし、カーネルモードでWebサーバーを実行することには欠点もある（例えば、ソフトウェアの開発やデバッグが困難になるなど）。また、実行時に重大なエラーが発生すると、OSカーネルに深刻な問題を引き起こす可能性がある。
ユーザーモードで動作するWebサーバーは、より多くのメモリやCPUリソースを使用するために、システムに許可を求める必要があります。カーネルへのこれらの要求は時間がかかるだけでなく、システムが自身の使用のためにリソースを確保し、他のすべての実行中のアプリケーションとハードウェアリソースを共有する責任を負っているため、必ずしも要求が満たされるとは限りません。ユーザーモードでの実行は、ユーザー空間とカーネル空間の間でより多くのバッファやデータコピーを使用することを意味し、ユーザーモードWebサーバーのパフォーマンス低下につながる可能性があります。
現在では、ほとんどすべてのウェブサーバーソフトウェアはユーザーモードで実行されます（前述の多くの小さな欠点は、より高速なハードウェア、新しいOSバージョン、はるかに高速なOSシステムコール、および最適化された新しいウェブサーバーソフトウェアによって克服されているためです）。ウェブサーバーソフトウェアの比較も参照して、どのソフトウェアがカーネルモードまたはユーザーモード（カーネル空間またはユーザー空間とも呼ばれます）で実行されるかを確認してください。
ユーザーエクスペリエンス（クライアント側またはブラウザ側）を向上させるため、Webサーバーはクライアントからのリクエストに迅速に（できるだけ早く）応答する必要があります。また、特定の種類のファイル（例えば、大きなファイルや巨大なファイル）に対してコンテンツ応答が（設定によって）制限されていない限り、返されるデータコンテンツも可能な限り速く（高速な転送速度で）送信されるべきです。
つまり、ウェブサーバーは、ウェブトラフィックの負荷が高い場合でも常に非常に応答性が高くなければならず、ユーザーが応答を待つ合計時間（ブラウザ時間＋ネットワーク時間＋ウェブサーバーの応答時間の合計）をできるだけ短くする必要があります。
ウェブサーバーソフトウェアの場合、主な主要パフォーマンス指標（さまざまな動作条件下で測定）は通常、少なくとも次のものになります。[ 54 ]
動作条件の中でも、テスト中に使用される同時クライアント接続数（1～n）は重要なパラメータです。なぜなら、これにより、Webサーバーがサポートする同時接続レベルとテストされたパフォーマンス指標の結果を関連付けることができるからです。
採用された具体的なWebサーバーソフトウェアの設計とモデル：
...その他、以下のようなプログラミング技術：
...ウェブサーバープログラムを実装するために使用される場合、パフォーマンス、特に高負荷時やハイエンドハードウェア（多数のCPU、ディスク、大量のRAM）使用時に達成できるスケーラビリティレベルに大きく影響する可能性があります。
実際には、一部のWebサーバーソフトウェアモデルは、正常に動作し、目標とするパフォーマンスを達成するために、他のモデルよりも多くのOSリソース（特にCPUとRAM）を必要とする場合があります。
ウェブサーバーのパフォーマンスに影響を与える可能性のある動作条件は数多くあり、パフォーマンス値は以下の要因によって変動する可能性があります。
ウェブサーバーのパフォーマンスは、通常、利用可能な自動負荷テストツールの1つ以上を使用して ベンチマークされます。
ウェブサーバー（プログラムのインストール）は通常、動作条件の組み合わせごとに事前に定義された負荷制限を持っています。これは、OSのリソースによって制限されることと、同時接続できるクライアント接続数が限られているためです（通常、アクティブなウェブサーバープロセスごとに2～数万の接続数です。C10k問題とC10M問題も参照してください）。
ウェブサーバーが負荷制限に近づいたり、それを超えたりすると、過負荷状態になり、応答しなくなる可能性があります。
ウェブサーバーは、以下の原因の1つまたは複数によって、いつでも過負荷状態になる可能性があります。
ウェブサーバーの過負荷状態を示す症状は、通常以下のとおりです。
平均以上の負荷制限を部分的に克服し、過負荷を防ぐために、多くの人気ウェブサイトでは次のような一般的な手法が用いられています。
download.*static.*www.*https://download.example.comhttps://static.example.comhttps://www.example.com
以下は、 Netcraftによるインターネット上のトップウェブサーバー全サイトの市場シェアに関する最新の統計情報です。
注: (*) パーセンテージは整数に丸められています。これは、ソースページで小数値が公開されていないためです (グラフには丸められた値のみが表示されます)。
動的コンテンツに使用される標準Webサーバーゲートウェイインターフェース：
動的コンテンツに使用されるその他のWebサーバーインターフェース（サーバーまたはプログラミング言語固有のもの）をいくつか紹介します。