ウェブサーバー

ウェブサーバーは、 HTTP（ウェブコンテンツを配信するために作成されたネットワークプロトコル）またはその安全な変種であるHTTPSを介してリクエストを受け入れるコンピュータ ソフトウェアと基盤ハードウェアです。ユーザーエージェント（通常はウェブブラウザまたはウェブクローラー）は、 HTTPを使用してウェブページまたはその他のリソースを要求して通信を開始し、サーバーはそのリソースのコンテンツまたはエラーメッセージで応答します。ウェブサーバーは、そのように構成されている場合、ユーザーエージェントから送信されたリソースを受け入れて保存することもできます。^{[1] [2]}

Web サーバーを実行するために使用されるハードウェアは、処理する必要のあるリクエストの量に応じて異なります。範囲の下限には、構成インターフェイスとして小さな Web サーバーを実行するルーターなどの組み込みシステムがあります。トラフィック量の多いインターネット Webサイトでは、高速コンピューターのラックで実行される数百台のサーバーでリクエストを処理する場合があります。

Web サーバーから送信されるリソースは、Web サーバーで使用可能な既存のファイル(静的コンテンツ) である場合もあれば、サーバー ソフトウェアと通信する別のプログラムによって要求時に生成されるもの (動的コンテンツ) である場合もあります。前者は通常、より高速に提供され、繰り返しの要求に対してより簡単にキャッシュできますが、後者はより幅広いアプリケーションをサポートします。

一般的なコンピュータ間通信の基盤として HTTP を使用するRESTやSOAP などのテクノロジや、 WebDAV拡張機能のサポートにより、Web サーバーの用途は、人間が読めるページを提供するという本来の目的をはるかに超えて拡張されました。

これはウェブ サーバー プログラムの非常に短い歴史であるため、一部の情報は必然的にウェブ ブラウザー、ワールド ワイド ウェブ、インターネットの歴史と重複します。したがって、明確さと理解しやすさのために、以下に報告するいくつかの重要な歴史情報は、上記の歴史記事の 1 つ以上に記載されている情報と類似している可能性があります。^{[引用が必要]}

1989年3月、ティム・バーナーズ＝リー卿は、ハイパーテキストシステムを使用して科学者間の情報交換を容易にすることを目的とした新しいプロジェクトを雇用主であるCERNに提案しました。 「ハイパーテキストとCERN」と題された提案はコメントを求められ、数人の人々に読まれました。1990年10月に提案は再定式化され、充実され（ロバート・カイユが共著者として参加）、最終的に承認されました。^{[3] [4] [5]}

1990年後半から1991年初頭にかけて、このプロジェクトではバーナーズ＝リーと彼の開発者がいくつかのソフトウェアライブラリと3つのプログラムを書き、テストしました。これらは当初NeXTワークステーションにインストールされたNeXTSTEP OS上で動作しました。 ^{[6] [7] [5]}

• WorldWideWebと呼ばれるグラフィカルWeb ブラウザ。
• ポータブルライン モード Web ブラウザー。
• 後にCERN httpdとして知られるようになった Web サーバー。

これらの初期のブラウザは、 HTTP 0.9という新しい基本通信プロトコルを使用して、Web サーバーから、単純な初期の HTML 形式で記述された Web ページを取得しました。

1991年8月、ティム・バーナーズ＝リーはWWW技術の誕生を発表し、科学者にこれを採用し開発するよう奨励した。^{[8]その後すぐに、これらのプログラムは}ソースコードとともに、その利用に関心のある人々に公開された。^[6]ソースコードは正式にライセンスされておらず、パブリックドメインにもならなかったが、CERNは非公式にユーザーと開発者に実験と開発を許可した。バーナーズ＝リーはこれらのプログラムの採用と使用、および他のオペレーティングシステムへの移植を促進し始めた。^[5]

1991年12月、ヨーロッパ以外で最初のウェブサーバーがSLAC（米国）に設置されました。^[7]これは、ウェブブラウザとウェブサーバー間の大陸間ウェブ通信を開始したため、非常に重要な出来事でした。

1991 年から 1993 年にかけて、CERN ウェブ サーバー プログラムは www グループによって引き続き積極的に開発され、その一方で、ソース コードと HTTP プロトコルの公開仕様が利用可能になったことにより、他の多くのウェブ サーバーの実装が開発され始めました。

1993年4月、CERNは、Webソフトウェアの3つのコンポーネント（基本的なラインモードクライアント、Webサーバー、共通コードのライブラリ）とそのソースコードがパブリックドメインに置かれたという公式声明を発表しました。^{[11]この声明により、Webサーバーの開発者は、そのソースコードに基づく}派生作品の開発に関するあらゆる法的問題から解放されました（実際にはそのような脅威は存在しませんでした）。

1994 年の初め、新しい Web サーバーの中で最も注目されたのは、さまざまなUnixベースの OS 上で実行され、HTTP メソッドとCGI を実装して外部プログラムと通信することで動的に生成されたコンテンツを提供できる NCSA httpd でした。これらの機能と、NCSA のMosaicブラウザのマルチメディア機能 (Web サーバーにデータを送信するためにHTMLフォームを管理することも可能)により、Web テクノロジがパブリッシングおよび分散コンピューティングアプリケーション に持つ可能性が強調されました。POST

1994 年後半、NCSA httpd の開発は行き詰まり、NCSA httpd のソース コードがパブリック ドメインで利用できるようになったため、外部のソフトウェア開発者、ウェブマスター、およびこのサーバーに興味を持つ他の専門家のグループがパッチの作成と収集を開始しました。1995年の初めに、これらのパッチはすべて NCSA ソース コードの最後のリリースに適用され、いくつかのテストの後、Apache HTTP サーバープロジェクトが開始されました。^{[12] [13]}

1994 年末、Netsiteという新しい商用 Web サーバーが特定の機能を備えてリリースされました。これは、最初にNetscapeによって開発され、その後Sun Microsystemsによって開発され、最終的にOracle Corporationによって開発された、他の多くの類似製品の最初のものでした。

1995 年半ば、MicrosoftはWindows NT OS向けのIISの最初のバージョンをリリースしました。これは、Web の両側 (クライアントとサーバー) で重要な役割を果たしてきた、そして現在も果たし続けている非常に重要な商用開発者およびベンダーが、World Wide Web テクノロジの分野に参入したことを意味します。

1995 年後半には、以前のものよりも多くの機能、より多くの修正、より高いパフォーマンスを備え、開発サイクルがはるかに速い新しい Web サーバーが広く採用されたため、CERN および NCSA Web サーバーは (世界全体の使用率で) 減少し始めました。

1996年末には、インターネットドメイン名を所有したり、ウェブサイトをホストしたりしたい人なら誰でも利用できる、50種類以上のウェブサーバーソフトウェアプログラムがすでに存在していました。 ^[15]それらの多くは短期間で消滅し、他のウェブサーバーに置き換えられました。

プロトコル バージョン 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 (現在は廃止) と呼ばれる、非常に革新的で注目に値する商用 Web サーバーもありました。Zeus は、使用率が低かったにもかかわらず、少なくとも 2000 年代の最初の 10 年間までは、市場で入手可能な最も高速でスケーラブルな Web サーバーの 1 つとして知られていました。

Apache は、1996 年半ばから 2015 年末まで、最も使用されている Web サーバーでしたが、数年間の衰退の後、最初は IIS に、次に Nginx に追い抜かれました。その後、IIS の使用率は Apache よりも大幅に低下しました (市場シェアも参照)。

2005年から2006年にかけて、Apacheは新しいパフォーマンス機能（イベントMPMや新しいコンテンツキャッシュなど）を導入することで、速度とスケーラビリティレベルの向上を開始しました。^{[16] [17]}これらの新しいパフォーマンス改善は当初実験的なものとされていたため、長い間ユーザーには有効にされず、Apacheは商用サーバー、そしてとりわけ他のオープンソースサーバーとの競争にさらに苦しみました。それらのサーバーは開発当初から（主に静的コンテンツを提供する場合）はるかに優れたパフォーマンスを達成しており、Apacheの衰退時には十分にテストされた高度な機能を多数提供できました。

実際、2000 年に入って数年後には、LiteSpeedなどの他の商用で競争力の高い Web サーバーだけでなく、優れた品質と非常に高いパフォーマンスを備えた多くの他のオープン ソース プログラムも登場しました。その中でも注目すべきは、Hiawatha、Cherokee HTTP サーバー、Lighttpd、Nginxなどの派生製品や関連製品で、商用サポートも利用できるものもありました。

2007～2008 年頃、ほとんどの人気ウェブブラウザは、以前のデフォルトの制限であるホストドメインあたりの持続接続数 2 個 (RFC-2616 で推奨されている制限) ^[18]を、ホストドメインあたりの持続接続数 4、6、または 8 個に増やしました。これは、大量の画像を含む重いウェブページの取得を高速化し、ウェブページ内のイベントの双方向通知に使用される動的オブジェクト専用の持続接続が不足するという問題を緩和するためです。^[19] 1 年以内に、これらの変更により、ウェブサーバーが管理する必要のある持続接続の最大数は平均で 3 倍近くになりました。この傾向 (持続接続数の増加) は、低速ウェブサーバーの前でリバース プロキシを採用する大きな推進力となり、また、ハードウェア リソース (多数の CPU、RAM、高速ディスクを備えた高価なコンピューター) をあまり必要とせずに、そのスピードと非常に多くの同時接続を処理する能力を発揮できる新しいウェブサーバーが登場するチャンスももう 1 つ与えました。^[20]

2015年にRFCで新しいプロトコルバージョン[HTTP/2]が公開されましたが、新しい仕様の実装は決して簡単ではなかったため、あまり人気のないウェブサーバー（使用率が1％～2％未満など）の開発者の間で、新しいプロトコルバージョンのサポートを追加するかどうかというジレンマが生じました。^{[21] [22]}

実際、HTTP/2 をサポートするには、多くの要因 (実質的に常に必要な暗号化された接続、同じ TCP ポートでの HTTP/1.x と HTTP/2 の接続を区別する機能、HTTP メッセージのバイナリ表現、メッセージの優先度、HTTP ヘッダーの圧縮、TCP/IP サブ接続とも呼ばれるストリームの使用、および関連するフロー制御など) により、内部実装に根本的な変更が必要になることが多く、そのため、これらの Web サーバーの開発者の中には、次の主な理由により、新しい HTTP/2 バージョンをサポートしないことを選択した人もいます (少なくとも近い将来は)。^{[21] [22]}

• プロトコル HTTP/1.x は、将来クライアントとサーバー間の非互換性が生じないように、ブラウザによって非常に長い間 (おそらく永久に) サポートされるはずです。
• HTTP/2 の実装は、 2015 年まで存在しなかったまったく新しい種類のバグを招く可能性のある、非常に複雑なタスクであると考えられており、そのため、新しいプロトコルの実装の開発とテストに多大な投資が必要でした。
• HTTP/2 サポートの追加は、その努力が正当化される場合には、将来いつでも実行できます。

その代わりに、最も人気のあるウェブサーバーの開発者は、新しいプロトコルの提供を急いでいた。それは、彼らにそのための労働力と時間があったからというだけでなく、通常、以前のSPDYプロトコルの実装を出発点として再利用することができ、また、同じ理由でほとんどの使用されているウェブブラウザーがそれを非常に迅速に実装したからである。開発者が迅速に行動したもう1つの理由は、ウェブマスターが、増え続けるウェブトラフィックのプレッシャーを感じており、TCP/IP接続の数を大幅に減らし、ホストされているウェブサイトへのアクセスを高速化できるものを、できるだけ早くインストールして試したいと本当に思っていたからである。^[23]

2020年から2021年にかけて、 HTTP/3プロトコルに関する将来のRFCの高度なドラフトが公開された後、HTTP/2の実装（主要なWebサーバーと一般的なWebブラウザーによる）に関する動向が部分的に再現されました。

以下の技術概要は、このトピックに関する十分に幅広いシナリオを提供するために、 Web サーバーに実装できる機能と、Web サーバーが実行できるタスクの一部について、ごく限られた例をいくつか示す試みとしてのみ考えてください。

Webサーバー プログラムは、 HTTP プロトコルの 1 つ以上のバージョンを実装することにより、クライアント サーバー モデルでサーバーの役割を果たします。これには、多くの場合、HTTPS セキュア バリアントや、計画された使用法に役立つと考えられるその他の機能や拡張機能が含まれます。

ウェブサーバープログラムの複雑さと効率は、次のような要因によって大きく異なります。^[1]

• 共通機能が実装されています。
• 実行される一般的なタスク。
• 目標とするパフォーマンスとスケーラビリティレベル。
• 望ましいパフォーマンスとスケーラビリティ レベルを達成するために採用されたソフトウェア モデルとテクニック。
• 対象ハードウェアと使用カテゴリ (例: 組み込みシステム、低～中トラフィックの Web サーバー、高トラフィックのインターネットWeb サーバー)。

Web サーバー プログラムの実装方法はそれぞれ異なりますが、ほとんどのプログラムには次の共通機能が備わっています。

これらは、ほとんどの Web サーバーが通常備えている 基本的な機能です。

• 静的コンテンツの提供: HTTP プロトコル経由でクライアントに静的コンテンツ (Web ファイル) を提供できるようになります。
• HTTP : クライアントの HTTP 要求のバージョンと互換性のある HTTP 応答のバージョンを送信するために、1 つ以上の HTTP プロトコルのバージョンをサポートします。たとえば、 HTTP/1.0、HTTP/1.1 (最終的には暗号化された接続HTTPSでもサポートされます)、さらに、使用可能な場合はHTTP/2、HTTP/3 をサポートします。
• ログ記録: 通常、Web サーバーには、セキュリティと統計の目的で、クライアントの要求とサーバーの応答に関する情報をログ ファイルに記録する機能もあります。

その他のより高度で人気のある機能(ごく一部) は次のとおりです。

• 動的コンテンツの提供: HTTP プロトコルを介してクライアントに動的コンテンツ (オンザフライで生成) を提供できるようにします。
• 仮想ホスティング: 1 つのIP アドレスのみを使用して、多数の Web サイト (ドメイン名)を提供できるようになります。
• 承認: Web サイトのパス (Web リソース) の一部へのアクセスを許可、禁止、または承認できるようにします。
• コンテンツ キャッシュ: サーバーの応答を高速化するために、静的コンテンツや動的コンテンツをキャッシュできるようにします。
• 大容量ファイルのサポート: 32 ビットOS上で 2 GB を超えるサイズのファイルを提供できるようになります。
• 帯域幅調整: ネットワークが飽和しないようにし、より多くのクライアントにサービスを提供できるように、コンテンツ応答の速度を制限します。
• 書き換えエンジン:クリーンな URL (クライアント要求内) の一部を実際の名前にマッピングします。
• カスタム エラー ページ: カスタマイズされた HTTP エラー メッセージのサポート。

ウェブサーバープログラムは、実行時に、通常、いくつかの一般的なタスクを実行します（例：^{[1]） 。}

• 起動し、オプションで構成ファイルまたはその他の場所にある設定を読み取って適用し、オプションでログ ファイルを開き、クライアント接続/要求のリッスンを開始します。
• オプションで、設定と現在の動作条件に応じて一般的な動作を適応させようとします。
• クライアント接続を管理します（必要に応じて新しい接続を受け入れたり、既存の接続を閉じたりします）。
• クライアント要求を受信します(HTTP メッセージを読み取ることによって):
  • 各 HTTP 要求メッセージを読み取って検証します。
  • 通常は URL の正規化を実行します。
  • 通常は URL マッピングを実行します (デフォルトでは URL パス変換になる場合があります)。
  • 通常、さまざまなセキュリティ チェックとともに URL パスの変換を実行します。
• 要求された HTTP メソッドを実行または拒否します。
  • オプションで URL 認証を管理します。
  • オプションで URL リダイレクトを管理します。
  • オプションで静的リソース(ファイルの内容)の要求を管理します。
    • オプションでディレクトリインデックスファイルを管理します。
    • オプションで通常のファイルを管理します。
  • オプションで動的リソースのリクエストを管理します:
    • オプションでディレクトリリストを管理します。
    • オプションでプログラムまたはモジュールの処理を管理し、動的コンテンツの生成に使用される外部プログラムの可用性、実行の開始、および停止を確認します。
    • オプションで、動的コンテンツを生成するために使用される外部プログラム/内部モジュールとの通信を管理します。
• クライアントの要求に応答し、適切な HTTP 応答 (要求されたリソースやエラー メッセージなど) を送信し、最終的には動的プログラム/モジュールによって送信されたHTTP ヘッダーを検証または追加します。
• オプションで、クライアント要求および/またはその応答を、通常は共通ログ形式を使用して、外部のユーザー ログ ファイルまたはsyslogによるシステム ログ ファイルに(部分的にまたは完全に)記録します。
• オプションで、検出された異常やその他の注目すべきイベント(クライアント要求や内部機能など)に関するプロセス メッセージをsyslog またはその他のシステム機能を使用して記録します。これらのログ メッセージには通常、デバッグ、警告、エラー、アラートのレベルがあり、設定に応じてフィルター処理 (記録しない) できます (重大度レベルも参照)。
• オプションで、管理されている Web トラフィックやそのパフォーマンスに関する統計を生成します。
• その他のカスタムタスク。

ウェブサーバープログラムは以下が可能です: ^{[24] [25] [26]}

• HTTP リクエスト メッセージを読み取る。
• それを解釈する;
• 構文を検証する。
• 既知のHTTP ヘッダーを識別し、そこから値を抽出します。

HTTP リクエスト メッセージがデコードされ検証されると、その値を使用してそのリクエストを満たすことができるかどうかを判断できます。これには、セキュリティ チェックを含む他の多くの手順が必要です。

Web サーバー プログラムは通常、次の目的で 何らかのURL 正規化(ほとんどの HTTP 要求メッセージに含まれるURL ) を実行します。

• リソース パスを常に Web サイトのルート ディレクトリからのクリーンな均一パスにします。
• セキュリティ リスクの低減 (例: ウェブサイトのルート ディレクトリ外の静的リソースへのアクセスや、ウェブサイトのルート ディレクトリ以下の禁止されているパスや認証が必要なパスへのアクセスをより簡単に傍受する)。
• ウェブ リソースのパスを、人間やウェブ ログ分析プログラム(ログ アナライザー/統計アプリケーションとも呼ばれる) が認識しやすくなります。

URL 正規化という用語は、一貫した方法で URL を変更および標準化するプロセスを指します。実行できる正規化には、スキームとホストの小文字への変換など、いくつかの種類があります。最も重要な正規化には、「.」および「..」パス セグメントの削除と、空でないパス コンポーネントへの末尾のスラッシュの追加があります。

「URL マッピングとは、URL を分析して、それがどのリソースを参照しているかを判断し、そのリソースを要求元のクライアントに返すプロセスです。このプロセスは、Web サーバーに送信されるすべての要求で実行されます。要求の中には、HTML ドキュメントや gif 画像などのファイルで提供されるものもあれば、CGI プログラムの実行結果で提供されるものもあり、組み込みモジュール ハンドラー、PHP ドキュメント、Java サーブレットなどの他のプロセスによって提供されるものもあります。」^{[27] [更新が必要]}

実際には、単純な静的コンテンツの提供(URL 書き換えエンジン、動的コンテンツの提供など) を超えた高度な機能を実装する Web サーバー プログラムでは、通常、URL を次のように処理する方法を把握する必要があります。

• URL リダイレクト、別の URL へのリダイレクト。
• ファイルコンテンツの静的リクエスト。
• 動的リクエスト:
  • そのディレクトリに含まれるファイルまたはその他のサブディレクトリのディレクトリリスト。
  • 他の種類の動的リクエストは、その種類の URL パスを処理できるプログラム/モジュール プロセッサを識別し、それに他のURL 部分(通常はパス情報とクエリ文字列変数) を渡します。

ウェブサーバーの1つ以上の構成ファイルは、 URLパスの一部（例えば、ファイルパスの最初の部分、ファイル名拡張子、その他のパス構成要素）を特定のURLハンドラー（ファイル、ディレクトリ、外部プログラム、または内部モジュール）にマッピングすることを指定する場合がある。^[28]

ウェブ サーバーが上記の高度な機能の 1 つ以上を実装している場合、有効な URL のパス部分は、動的要求の内部または外部モジュール プロセッサの仮想名を参照する可能性があるため、ウェブサイトのディレクトリ ツリー (ファイル システム内のファイルまたはディレクトリ) の下の既存のファイル システム パスと必ずしも一致しないことがあります。

ウェブサーバープログラムは、物理的なファイルシステムパスを参照するURLパス（全体または一部）を、対象ウェブサイトのルートディレクトリ下の絶対パスに変換することができます。 ^[28]

ウェブサイトのルートディレクトリは、設定ファイルまたはウェブサーバーの内部ルールによって、 HTTPクライアントリクエストのURLのホスト部分であるウェブサイトの名前を使用して指定されることがあります。 ^[28]

ファイル システムへのパス変換は、次の種類の Web リソースに対して実行されます。

• ローカルの、通常は実行不可能なファイル (ファイル コンテンツに対する静的要求)。
• ローカル ディレクトリ (動的リクエスト: ディレクトリ リストはオンザフライで生成されます)。
• プログラム名 (CGI または SCGI インターフェイスを使用して実行され、その出力が Web サーバーによって読み取られ、HTTP 要求を行ったクライアントに再送信される動的要求)。

Web サーバーは、要求された URL (HTTP 要求メッセージ) で見つかったパスを (ホスト) Web サイトのルート ディレクトリのパスに追加します。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
ホスト: www.example.com
接続: キープアライブ

結果はローカル ファイル システム リソースになります。

/home/www/www.example.com/path/file.html

次に、Web サーバーは、ファイルが存在する場合はそれを読み取り、クライアントの Web ブラウザーに応答を送信します。応答には、ファイルの内容が記述され、ファイル自体が含まれます。または、ファイルが存在しないか、アクセスが禁止されていることを示すエラー メッセージが返されます。

ディレクトリ要求の URL パス変換 (静的インデックス ファイルなし)

次の URL で指定された既存のディレクトリの 暗黙的な動的要求の例:

http://www.example.com/ディレクトリ1/ディレクトリ2/

クライアントのユーザー エージェントは に接続しwww.example.com、次のHTTP /1.1 要求を送信します。

GET /ディレクトリ1/ディレクトリ2 HTTP/1.1
ホスト: www.example.com
接続: キープアライブ

結果はローカル ディレクトリ パスになります。

/home/www/www.example.com/ディレクトリ1/ディレクトリ2/

次に、Web サーバーはディレクトリの存在を確認し、ディレクトリが存在し、アクセスできる場合は、インデックス ファイル (この場合は存在しません) を見つけようとします。そのため、要求を内部モジュールまたはディレクトリ一覧専用のプログラムに渡し、最後にデータ出力を読み取って、クライアントの Web ブラウザーに応答を送信します。応答には、ディレクトリの内容 (含まれるサブディレクトリとファイルのリスト) が記載されるか、ディレクトリが存在しない、またはディレクトリへのアクセスが禁止されているというエラー メッセージが返されます。

動的プログラムリクエストの URL パス変換

動的リクエストの場合、クライアントが指定したURLパスは、Webサーバーが動的コンテンツを生成するために使用する既存の外部プログラム（通常はCGIを含む実行可能ファイル）を参照する必要があります。^[29]

プログラム ファイルを使用して出力を生成する 動的リクエストの例:

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
ホスト: www.example.com
接続: キープアライブ

結果はプログラム (この例ではPHPプログラム) のローカル ファイル パスになります。

/home/www/www.example.com/cgi-bin/forum.php

ウェブ サーバーはそのプログラムを実行し、パス情報とクエリ文字列 action=view&orderby=thread&date=2021-10-15を渡して、プログラムが実行に必要な情報を持つようにします (この場合、2021 年 10 月 15 日のスレッド順に並べられたフォーラム エントリのビューを含む HTML ドキュメントが返されます)。これに加えて、ウェブ サーバーは外部プログラムから送信されたデータを読み取り、そのデータを要求元のクライアントに再送信します。

リクエストが読み取られ、解釈され、検証されると、そのメソッド、URL、およびパラメータ（HTTP ヘッダーの値が含まれる場合があります）に応じてリクエストを管理する必要があります。

実際には、ウェブサーバーは次のいずれかの応答パスを使用してリクエストを処理する必要があります。^[28]

• リクエスト内の何かが受け入れられない場合 (ステータス ラインまたはメッセージ ヘッダー内)、Web サーバーはすでにエラー応答を送信しています。
• リクエストに Web サーバーの一般的なコードで満たすことができるメソッド (例OPTIONS) がある場合は、成功した応答が送信されます。
• URL に認証が必要な場合は、認証エラー メッセージが送信されます。
• URL がリダイレクトにマップされる場合はリダイレクト メッセージが送信されます。
• URL が動的リソース (仮想パスまたはディレクトリ リスト) にマップされる場合、そのハンドラー (内部モジュールまたは外部プログラム) が呼び出され、そのリクエストに応答できるようにリクエスト パラメーター (クエリ文字列とパス情報) が渡されます。
• URL が静的リソース (通常はファイル システム上のファイル) にマップされる場合、そのファイルを送信するために内部の静的ハンドラーが呼び出されます。
• リクエストメソッドが不明な場合、またはその他の許容できない条件（リソースが見つからない、内部サーバーエラーなど）がある場合は、エラー応答が送信されます。

ウェブサーバープログラムが静的コンテンツを提供でき、そのように構成されている場合、リクエストメッセージに有効なURLパス（URLマッピング、URL変換、URLリダイレクト後）がウェブサイトのルートディレクトリの下にある既存のファイルのパスと一致し、そのファイルがウェブサーバープログラムの内部ルールで要求される属性と一致する場合はいつでも、ファイルコンテンツを送信できます。^[28]

この種のコンテンツは、通常、クライアントに送信されるときに Web サーバーによって変更されず、何らかのプログラムによって変更 (ファイルの変更) されるまで同じままであるため、 静的と呼ばれます。

注:静的コンテンツのみを提供する場合、Web サーバー プログラムは通常、提供される Web サイトのファイル コンテンツを変更しません(読み取りのみが行われ、書き込みは行われないため)。そのため、次のHTTP メソッドのみをサポートすれば十分です。

• OPTIONS
• HEAD
• GET

静的ファイル コンテンツの応答は、ファイル キャッシュによって高速化できます。

Web サーバー プログラムが、既存のディレクトリの 1 つに一致するパスを持つ URL を含むクライアント要求メッセージを受信し、そのディレクトリがアクセス可能であり、ディレクトリ インデックス ファイルの提供が有効になっている場合、Web サーバー プログラムは、そのディレクトリで見つかった最初の既知の (または構成された) 静的インデックス ファイル名 (通常のファイル) を提供しようとします。インデックス ファイルが見つからないか、その他の条件が満たされていない場合は、エラー メッセージが返されます。

静的インデックス ファイルで最もよく使用される名前はindex.html、、index.htmおよびですDefault.htm。

Web サーバー プログラムが、パスが既存ファイルのファイル名と一致する URL を含むクライアント要求メッセージを受信し、そのファイルが Web サーバー プログラムからアクセス可能であり、その属性が Web サーバー プログラムの内部ルールと一致する場合、Web サーバー プログラムはそのファイルをクライアントに送信できます。

通常、セキュリティ上の理由から、ほとんどのウェブサーバープログラムは、通常のファイルのみを提供するか、デバイスファイルなどの特殊なファイルタイプや、それらへのシンボリックリンクやハードリンクを使用しないように事前に構成されています。その目的は、静的なウェブリソースを提供する際に望ましくない副作用を回避することです。^[30]

ウェブ サーバー プログラムが動的コンテンツを提供でき、そのように構成されている場合、適切な内部モジュールまたは外部プログラム (要求された URL パスに関連付けられている) と通信して、クライアント要求のパラメータを渡すことができます。その後、ウェブ サーバー プログラムはそこからデータ応答 (多くの場合、オンザフライで生成) を読み取り、要求を行ったクライアント プログラムに再送信します。^{[引用が必要]}

注:静的および動的コンテンツを提供する場合、Web サーバー プログラムは通常、クライアントからデータを安全に受信できるようにするために、また、Web サーバー/外部プログラム/モジュールに大量のデータ セット (大量のデータ入力やファイルのアップロードなど)を送信する可能性のある対話型フォームを含む Web サイトもホストできるようにするために、次の HTTP メソッドもサポートする必要があります。

• POST

内部モジュールや外部プログラムと通信できるようにするには、Web サーバー プログラムに、使用可能な多数のゲートウェイ インターフェイスの 1 つ以上を実装する必要があります(動的コンテンツに使用される Web サーバー ゲートウェイ インターフェイスも参照)。

標準および履歴ゲートウェイ インターフェイスには次の 3 つがあります。

CG

外部 CGI プログラムは、各動的リクエストに対して Web サーバー プログラムによって実行され、Web サーバー プログラムはそこから生成されたデータ応答を読み取り、クライアントに再送信します。

SCGI

外部 SCGI プログラム (通常はプロセス) は、Web サーバー プログラムまたは他のプログラム/プロセスによって一度起動され、ネットワーク接続を待機します。新しいリクエストがあるたびに、Web サーバー プログラムはリクエスト パラメータを送信し、データ応答を読み取るために新しいネットワーク接続を確立し、その後ネットワーク接続が閉じられます。

高速CGI

外部 FastCGI プログラム (通常はプロセス) は、Web サーバー プログラムまたは他のプログラム/プロセスによって一度起動され、Web サーバーによって永続的に確立されるネットワーク接続を待機します。その接続を通じて、要求パラメータが送信され、データ応答が読み取られます。

ウェブサーバープログラムは、ファイルとサブディレクトリのディレクトリインデックスリストを動的に（オンザフライで）生成する機能を持つ場合があります。 ^[31]

Web サーバー プログラムがそのように構成されており、要求された URL パスが既存のディレクトリと一致し、そのアクセスが許可され、そのディレクトリの下に静的インデックス ファイルが見つからない場合、上記のディレクトリのファイルおよび/またはサブディレクトリのリストを含む Web ページ (通常は HTML 形式) が動的に生成されます(オンザフライ)。生成できない場合は、エラーが返されます。

一部の Web サーバー プログラムでは、Web ページ テンプレート (プレースホルダー ( など) を含む HTML ドキュメント。Web$(FILE_NAME), $(FILE_SIZE)サーバーによってディレクトリで見つかった各ファイル エントリのフィールド値に置き換えられます) の使用 (など)、index.tplまたは HTML と、その場で解釈されて実行される埋め込みソース コードの使用 (など)、index.aspおよび/または CGI、SCGI、FCGI などの動的インデックス プログラムの使用をサポートすることによって、ディレクトリ リストのカスタマイズが可能です (例: index.cgi、、index.php) index.fcgi。

動的に生成されたディレクトリ リストの使用は、静的なインデックス ページを送信する場合よりも多くの OS リソースが消費されるため、通常は避けるか、Web サイトの選択されたいくつかのディレクトリに限定されます。

ディレクトリリストの主な用途は、ファイル（通常、ファイルの名前、サイズ、変更日時、ファイル属性がランダムまたは頻繁に変更される可能性がある場合）をそのままダウンロードできるようにすることです。要求元のユーザーに詳細情報を提供する必要はありません。^[32]

外部プログラムまたは内部モジュール（処理ユニット）は、1つ以上のデータリポジトリからデータを取得したり、1つ以上のデータリポジトリにデータを保存したりするために使用できる何らかのアプリケーション関数を実行できます。例：^[要出典]

• ファイル（ファイルシステム）
• データベース（DB）
• ローカル コンピューターまたは他のコンピューターにあるその他のソース。

処理ユニットは、データリポジトリから取得したデータを使用して、あらゆる種類のWebコンテンツを返すことができます。例: ^{[引用が必要]}

• 文書（例：HTML、XMLなど）
• 画像;
• ビデオ
• 構造化データ。たとえば、 Web インターフェイスの動的ページ ( DHTML ) によって表示される 1 つ以上の値を更新するために使用される可能性があり、 XMLHttpRequest APIによって要求された可能性があります(動的ページも参照)。

実際には、クライアント要求または構成設定に含まれる 1 つ以上のパラメータに応じて変化する可能性があるコンテンツがある場合は、通常、そのコンテンツは動的に生成されます。

ウェブサーバープログラムは、クライアントの要求メッセージに対する返信として応答メッセージを送信することができます。^[24]

要求メッセージが正常に読み取られなかったり、デコードされなかったり、分析されなかったり、実行されなかったりすると、エラー応答メッセージが送信されることがあります。^[25]

注意: 以下のセクションは、Web サーバーがどのような機能を果たすかを理解するための例としてのみ記載されており、網羅的でも完全でもありません。

Web サーバー プログラムは、クライアントの要求メッセージに対してさまざまな種類のエラー メッセージで応答することがあります。これらのエラーは主に次の 2 つのカテゴリに分類されます。

• HTTPクライアントエラー（リクエストメッセージの種類やリクエストされたWebリソースの可用性による）^[33]
• HTTPサーバーエラー、内部サーバーエラーによる。^[34]

クライアント ブラウザーがエラー応答/メッセージを受信すると、それがメインのユーザー要求 (Web ページなどの Web リソースの URL など) に関連している場合、通常、そのエラー メッセージが何らかのブラウザー ウィンドウ/メッセージに表示されます。

ウェブサーバープログラムは、要求されたURLパスが次のものであるかどうかを確認できる場合がある: ^[35]

• 誰でも自由にアクセスできます。
• ユーザー認証が必要です（ユーザー名やパスワードなどのユーザー資格情報の要求）。
• 一部またはすべての種類のユーザーへのアクセスが禁止されています。

承認/アクセス権機能が実装され、有効になっていて、Web リソースへのアクセスが許可されていない場合、必要なアクセス権に応じて、Web サーバー プログラムは次の処理を実行します。

• 特定のエラーメッセージ（例：アクセス禁止）を送信してアクセスを拒否できます。
• 特定のエラー メッセージ (例: アクセス権限がありません)を送信してアクセスを拒否することがあります。通常、このエラー メッセージにより、クライアント ブラウザーはユーザーに必要なユーザー資格情報を提供するよう要求します。認証資格情報が提供された場合、Web サーバー プログラムはそれを検証し、受け入れるか拒否します。

ウェブサーバープログラムは、新しいURL（新しい場所）へのURLリダイレクトを行う機能を持つ場合があります。これは、クライアントの要求メッセージに対して、有効なまたは既存のウェブリソースにアクセスするのに適した新しいURLを含む応答メッセージで応答することです（クライアントは新しいURLで要求をやり直す必要があります）。^[36]

場所のURLリダイレクトが使用される：^[36]

• 最後にスラッシュ「/」を追加してディレクトリ名を固定する。^[31]
• 存在しなくなった URL パスに、その種類の Web リソースが見つかる新しいパスへの新しい URL を指定します。
• 現在のドメインの負荷が大きすぎる場合に、別のドメインに新しい URL を割り当てます。

例1: URLパスはディレクトリ名を指していますが、最後のスラッシュ「/」がないため、Webサーバーはクライアントにリダイレクトを送信し、固定パス名でリクエストをやり直すように指示します。^[31]

差出人:
  /directory1/directory2
宛先:
  /directory1/directory2/

例 2:ファイル システム パスを再編成するために、 ドキュメントのセット全体がWeb サイト内で移動されました。

差出人:
  /directory1/directory2/2021-10-08/
宛先:
  /directory1/directory2/2021/10/08/

例 3: ドキュメントのセット全体が新しい Web サイトに移動されたため、それらにアクセスするには安全な HTTPS 接続を使用する必要がある。

差出人:
  http://www.example.com/directory1/directory2/2021-10-08/
宛先:
  https://docs.example.com/directory1/2021-10-08/

上記の例は、リダイレクトの可能な種類のほんの一部です。

ウェブサーバープログラムは、有効なクライアント要求メッセージに対して、要求されたウェブリソースデータをオプションで含む成功メッセージで応答することができます。^[37]

Web リソース データがクライアントに送り返される場合、そのデータは、取得方法 (ファイルから取得されたか、何らかのプログラム/モジュールの出力から取得されたか) に応じて、静的コンテンツまたは動的コンテンツになります。

平均的なHTTP応答時間と使用されるハードウェアリソースを削減してWebサーバーの応答を高速化するために、多くの一般的なWebサーバーは、それぞれがコンテンツカテゴリに特化した1つ以上のコンテンツキャッシュを実装しています。^{[38] [39]}

コンテンツは通常、その生成元によってキャッシュされます。例:

• 静的コンテンツ:
  • ファイルキャッシュ;
• 動的コンテンツ:
  • 動的キャッシュ（モジュール/プログラム出力）。

歴史的に、頻繁かつランダムにすばやくアクセスする必要のあるファイル内の静的コンテンツは、 1960 年代中期から 1970 年代後半にかけて、主に電気機械式ディスクに保存されてきました。残念ながら、これらのデバイスからの読み取りと書き込みは、 RAM の速度と比較すると常に非常に遅い操作であると考えられてきました。そのため、初期のOS以降、頻繁にアクセスされるデータやファイルのI/O操作を高速化するために、最初にディスク キャッシュが開発され、次にOSファイルキャッシュサブシステムが開発されました。

OS ファイル キャッシュの助けがあっても、ディスクに保存されたディレクトリやファイルに関連する I/O 操作の相対的または偶発的な遅さは、トップ レベルの Web サーバーに期待されるパフォーマンスの向上のボトルネックになりました。特に、インターネット/ネットワーク回線の速度が継続的に向上し、Web インターネット トラフィックが指数関数的に増加し始めた 1990 年代中期から後半以降は、その傾向が顕著でした。

静的ファイルの提供をさらに効率的に高速化し、1秒あたりのリクエスト/レスポンスの最大数（RPS）を増やす方法についての問題は、Webサーバープログラムに実装できる便利なキャッシュモデルを提案することを目的として、1990年代半ばから研究され始めました。^[40]

実際には、今日では多くの人気/高性能ウェブサーバープログラムには、ウェブサーバーの使用に合わせて調整され、特定の実装とパラメータを使用する独自のユーザーランド ファイルキャッシュが含まれています。 ^{[41] [42] [43]}

RAIDや高速ソリッド ステート ドライブ(非常に高速な I/O 速度を持つストレージ ハードウェア)が広く採用されるようになったことで、Web サーバーにファイル キャッシュを組み込むことの利点は若干減少しましたが、もちろん完全になくなったわけではありません。

内部モジュールまたは外部プログラムによって出力される動的コンテンツは、必ずしも頻繁に変更されるわけではない（キー/パラメータを持つ一意のURLが与えられている場合）ため、しばらくの間（例えば1秒から数時間以上）、結果の出力はRAMまたは高速ディスクにキャッシュされる可能性があります。^[44]

動的キャッシュの典型的な使用法は、ウェブサイトにニュース、天気、画像、地図などに関する動的なウェブページがあり、頻繁には変更されず（たとえばn分ごと）、1分または1時間あたりに膨大な数のクライアントがアクセスする場合です。このような場合、クライアントのブラウザキャッシュには要求されたコンテンツの更新されたコピーがないことが多いため、キャッシュされたコンテンツも返すことが有用です（内部モジュールまたは外部プログラムを呼び出さずに）。^[45]

いずれにせよ、ほとんどの場合、これらの種類のキャッシュは、Webサーバーとハードウェアリソース（CPU、RAM、ディスク）を競合しないように、外部サーバー（リバースプロキシなど）によって実装されるか、動的データ出力を別のコンピューターに保存し、特定のアプリケーション（memcachedなど）によって管理されます。^{[46] [47]}

Web サーバー ソフトウェアは、OSに組み込まれてカーネル空間で実行されるか、または(他の通常のアプリケーションと同様に) ユーザー空間で実行されます。

カーネル モードで実行される Web サーバー(通常はカーネル スペース Web サーバーと呼ばれます) はカーネル リソースに直接アクセスできるため、理論的にはユーザー モードで実行されるサーバーよりも高速になります。ただし、Web サーバーをカーネル モードで実行すると、ソフトウェアの開発 (デバッグ)が困難になる、実行時の 重大なエラーによってOS カーネルに深刻な問題が発生する可能性があるなどの欠点があります。

ユーザー モードで実行される Web サーバーは、より多くのメモリまたはCPUリソースを使用する許可をシステムに要求する必要があります。カーネルへのこれらの要求は時間がかかるだけでなく、システムが自身の使用のためにリソースを予約し、実行中の他のすべてのアプリケーションとハードウェア リソースを共有する責任があるため、要求が常に満たされるとは限りません。ユーザー モードで実行すると、バッファー/データ コピー (ユーザー空間とカーネル空間の間) がさらに使用される可能性があり、ユーザー モード Web サーバーのパフォーマンスが低下する可能性があります。

現在、ほぼすべての Web サーバー ソフトウェアはユーザー モードで実行されます (前述の小さな欠点の多くは、より高速なハードウェア、新しい OS バージョン、はるかに高速な OSシステム コール、および最適化された新しい Web サーバー ソフトウェアによって克服されているため)。Webサーバー ソフトウェアの比較も参照して、どのソフトウェアがカーネル モードまたはユーザー モード (カーネル空間またはユーザー空間とも呼ばれます) で実行されるかを確認してください。

ユーザー エクスペリエンス(クライアント/ブラウザー側)を向上させるには、Web サーバーはクライアントの要求にすばやく (できるだけ早く) 応答する必要があります。一部のファイル タイプ (大きなファイルや巨大なファイルなど) のコンテンツ応答が (構成によって) 調整されない限り、返されるデータ コンテンツもできるだけ速く (転送速度を上げて) 送信される必要があります。

言い換えれば、 Web トラフィックの負荷が高い場合でも、 Web サーバーは常に応答性が高く、応答に対するユーザーの待機時間(ブラウザー時間 + ネットワーク時間 + Web サーバーの応答時間の合計) を可能な限り短くする必要があります。

ウェブサーバーソフトウェアの場合、主要な主要パフォーマンス指標（さまざまな動作条件下で測定）は通常、少なくとも次のものになります（すなわち）：^[48]

• の数1 秒あたりのリクエスト数(RPS、QPS、 HTTP のバージョンと構成、 HTTP リクエストの種類、その他の動作条件によって異なります)。
• 1 秒あたりの接続数( CPS ) は、Web サーバーが受け入れる 1 秒あたりの接続数です (接続あたりの要求/応答の制限が非常に低い (1 〜 20) HTTP/1.0 または HTTP/1.1 を使用する場合に役立ちます)。
• ネットワーク遅延+各新規クライアント要求の応答時間。通常、ベンチマーク ツールは、一定時間内 (例: 1 ミリ秒、3 ミリ秒、5 ミリ秒、10 ミリ秒、20 ミリ秒、30 ミリ秒、40 ミリ秒) に満たされた要求の数、および/または最短、平均、最長の応答時間を表示します。
• 応答のスループット（バイト/秒単位）。

動作条件の中で、テスト中に使用される同時クライアント接続の数(1 .. n )は、Web サーバーでサポートされる同時実行レベルとテストされたパフォーマンスメトリックの結果を相関させることができるため、重要なパラメーターです。

採用された特定の Web サーバーソフトウェア設計とモデル(例):

• 単一プロセスまたはマルチプロセス。
• 各プロセスに対してシングルスレッド（スレッドなし）またはマルチスレッド。
• コルーチンを使用するかどうか。

...およびその他のプログラミング手法、例えば次のようなもの:

• CPU キャッシュミスの可能性を最小限に抑える。
• 速度向上のためのクリティカルパスにおけるCPU 分岐予測ミスの可能性を最小限に抑える。
• 特定の機能/タスクを実行するために使用されるシステムコールの数を最小限に抑えます。
• その他のトリック;

... Web サーバー プログラムを実装するために使用される場合、パフォーマンス、特に高負荷時やハイエンド ハードウェア (多数の CPU、ディスク、大量の RAM) の使用時に達成できるスケーラビリティレベルに大きな偏りが生じる可能性があります。

実際には、一部の Web サーバー ソフトウェア モデルでは、正常に動作して目標のパフォーマンスを達成するために、他のモデルよりも多くの OS リソース (特に、より多くの CPU と RAM) が必要になる場合があります。

Web サーバーの パフォーマンスに影響を与える可能性のある動作条件は多数あり、パフォーマンス値は次のような要因によって変化する可能性があります。

• ウェブサーバーの設定（ログファイルが有効かどうかなどを含む）
• クライアント要求で使用される HTTP バージョン。
• 平均的な HTTP リクエスト タイプ (メソッド、HTTP ヘッダーの長さ、オプションの本文)。
• 要求されたコンテンツが静的か動的か。
• コンテンツがキャッシュされているかどうか（サーバーおよび/またはクライアントによって）
• コンテンツがオンザフライで圧縮されるか（転送時）、事前圧縮されるか（つまり、ファイル リソースがすでに圧縮された状態でディスクに保存され、Web サーバーがそのファイルをコンテンツが圧縮されていることのみを示す形でネットワークに直接送信できる場合）、またはまったく圧縮されないか。
• 接続が暗号化されているかどうか。
• Web サーバーとそのクライアント間の平均ネットワーク速度。
• アクティブなTCP接続の数。
• Web サーバーによって管理されるアクティブなプロセスの数 (外部 CGI、SCGI、FCGI プログラムを含む)。
• ウェブサーバーが実行されるコンピューターのハードウェアおよびソフトウェアの制限またはOSの設定。
• その他の軽微な症状。

Web サーバーのパフォーマンスは通常、利用可能な 自動負荷テスト ツールを使用してベンチマークされます。

Web サーバー (プログラムのインストール) には通常、動作条件の組み合わせごとに事前定義された負荷制限があります。これは、OS リソースによって制限され、限られた数のクライアント同時接続しか処理できないためです (通常、アクティブな Web サーバー プロセスごとに 2 ～ 数万の間、C10k 問題とC10M 問題も参照)。

Web サーバーが負荷制限に近づいたり、負荷制限を超えたりすると、過負荷状態になり、応答しなくなる可能性があります。

ウェブ サーバーは、次のいずれかまたは複数の原因により、いつでも過負荷になる可能性があります (例)。

• 過剰な正当な Web トラフィック。短時間に数千または数百万のクライアントが Web サイトに接続する (例: Slashdot 効果)。
• 分散型サービス拒否攻撃。サービス拒否攻撃 (DoS 攻撃) または分散型サービス拒否攻撃 (DDoS 攻撃) は、コンピューターまたはネットワーク リソースを対象ユーザーが利用できないようにする攻撃です。
• 数百万台の感染したコンピュータ（それらの間で調整されていない）が原因で、異常なトラフィックを引き起こすことがあるコンピュータ ワーム。
• XSS ワームは、何百万ものブラウザや Web サーバーが感染するため、大量のトラフィックを発生させる可能性があります。
• インターネット ボットネットワーク リソース (帯域幅など) やハードウェア リソース (CPU、RAM、ディスク)が非常に少ない大規模な Web サイトでは、トラフィックがフィルタリング/制限されません。
• インターネット(ネットワーク) の速度低下 (例: パケット損失による) により、クライアント要求の処理速度が低下し、接続数が増加してサーバーの制限に達します。
• 動的コンテンツを提供するWeb サーバーは、バックエンドコンピューター(データベースなど)からの応答が遅いことを待機しています。これは、クエリが多すぎることと、DB データの挿入または更新が多すぎることが原因である可能性があります。このような場合、Web サーバーは、HTTP クライアントに応答する前にバックエンド データの応答を待機する必要がありますが、待機中に新しいクライアント接続/要求が多すぎると、サーバーが過負荷になります。
• Web サーバー (コンピューター)が部分的に使用不可になります。これは、必要なまたは緊急のメンテナンスやアップグレード、バックエンド(データベースなど) の障害などのハードウェアまたはソフトウェアの障害が原因で発生することがあります。このような場合、残りの Web サーバーのトラフィックが多すぎて過負荷になる可能性があります。

ウェブサーバーが過負荷になった場合の症状は通常、次のようになります (例)。

• リクエストは（おそらく長い）遅延（1 秒から数百秒）を伴って処理されます。
• ウェブサーバーは、500、502、^{[49] [50]} 503、^[51] 504、^[52] 408、または断続的に404などのHTTPエラーコードを返します。
• Web サーバーは、コンテンツを返す前にTCP接続を拒否またはリセット (中断) します。
• 非常にまれなケースですが、Web サーバーが要求されたコンテンツの一部のみを返すことがあります。この動作は、通常は過負荷の症状として発生しますが、バグと見なすことができます。

平均以上の負荷制限を部分的に克服し、過負荷を防ぐために、ほとんどの人気のある Web サイトでは、次のような一般的な手法が使用されています (例)。

• ハードウェアの機能と使用状況に合わせて OS パラメータを調整します。
• Web サーバーのパラメータを調整して、セキュリティとパフォーマンスを向上させます。
• Web キャッシュ技術を導入する(静的コンテンツだけでなく、可能な場合は動的コンテンツにも適用)。
• 次のものを使用してネットワーク トラフィックを管理します。
  • 不正な IP ソースから送信される、または不正なパターンを持つ不要なトラフィックをブロックするファイアウォール。
  • 不正なHTTPパターンを持つリクエストをドロップ、リダイレクト、または書き換える HTTP トラフィック マネージャー。
  • ネットワーク使用量のピークを抑えるための帯域幅管理とトラフィック シェーピング。
• 異なるドメイン名、IP アドレス、およびコンピュータを使用して、異なる種類のコンテンツ (静的および動的) を提供します。その目的は、大きいファイル ( ) (そのドメインはCDNによっても置き換えdownload.*られる場合があります) を小中サイズのファイル ( ) およびメインの動的サイト (一部のコンテンツがバックエンド データベースに保存されている可能性があります) ( ) から分離することです。アイデアは、Web サーバー コンピュータごとに異なる設定を使用することで、負荷の高い動的サイトのパフォーマンスに影響を与えることなく、大きいファイル (10 - 1000 MB 以上) を効率的に提供し (ダウンロードを制限)、小中サイズのファイルを完全にキャッシュできるようにすることです。例: static.*www.*
  • https://download.example.com
  • https://static.example.com
  • https://www.example.com
• ロード バランサーの背後でグループ化された多数の Web サーバー (コンピューター) を使用することで、1 つの大きな Web サーバーとして動作したり認識されたりします。
• 各コンピューターにハードウェア リソース ( RAM、高速ディスクなど) を追加します。
• Web サーバーに、より効率的なコンピュータ プログラムを使用します (「ソフトウェア効率」も参照)。
• 最も効率的なWeb サーバー ゲートウェイ インターフェイスを使用して動的リクエストを処理します (動的ページが取得されるたびに 1 つ以上の外部プログラムが生成されるため、パフォーマンスが低下します)。
• 特に動的コンテンツが関係している場合は、他のプログラミング手法や回避策を使用して、HTTP 応答を高速化します (つまり、スタイルシート、画像、スクリプトなどの変更されない、またはほとんど変更されないオブジェクトを取得するための動的呼び出しを回避し、そのコンテンツを静的ファイルに一度コピーして、動的コンテンツと同期させます)。
• 最新の効率的なバージョンのHTTPを使用することで(たとえば、一般的な HTTP/1.1 を使用するだけでなく、使用可能な Web サーバー ソフトウェアが後者の 2 つのプロトコルを確実にサポートしている場合は、 HTTP/2と場合によってはHTTP/3も有効にします)、各クライアントによって開始される TCP/IP 接続の数と交換されるデータのサイズを大幅に削減します (HTTP ヘッダーの表現がよりコンパクトになり、データ圧縮が行われるため)。

HTTP/2 および HTTP/3 プロトコルの使用に関する注意事項

新しい HTTP (2 および 3) プロトコルは通常、各リクエスト/レスポンス データに対して生成されるネットワーク トラフィックが少なくなりますが、Web サーバー ソフトウェアによって使用されるOSリソース (RAM や CPU)が多く必要になる場合があります(暗号化されたデータ、大量のストリーム バッファー、その他の実装の詳細のため)。さらに、Web サーバーとクライアント プログラムの設定にもよりますが、HTTP/2 やおそらく HTTP/3 も、データ ストリームがリクエストの同時実行に最適化されているため、大容量または巨大なファイルのデータ アップロードに最適なオプションではない可能性があります。そのため、多くの場合、HTTP/1.1 TCP/IP 接続を使用すると、より良い結果やより高速なアップロード速度が得られます (使用状況によって異なる場合があります)。^{[53] [54]}

以下は、 Netcraftによるインターネット上のトップ Web サーバーの全サイトの市場シェアの最新統計です。

注: (*) パーセンテージは、小数値がソースページで公開されていないため、整数に丸められています (グラフでは丸められた値のみが報告されます)。

• サーバー（コンピューティング）
• アプリケーションサーバー
• ウェブサーバーソフトウェアの比較
• HTTP サーバー(HTTP リクエストを処理する Web サーバー プログラムのコア部分)
• HTTP 圧縮
• ウェブアプリケーション
• オープンソースのウェブアプリケーション
• AMP パッケージのリスト
• バリアントオブジェクト
• 仮想ホスティング
• ウェブホスティングサービス
• ウェブコンテナ
• ウェブプロキシ
• ウェブサービス

動的コンテンツに使用される標準 Web サーバー ゲートウェイ インターフェイス:

• CGI共通ゲートウェイ インターフェース
• SCGIシンプル コモン ゲートウェイ インターフェイス
• FastCGI高速共通ゲートウェイ インターフェース

動的コンテンツに使用されるその他の Web サーバー インターフェイス (サーバーまたはプログラミング言語に固有) は次のとおりです。

• SSIサーバーサイドインクルードは、めったに使用されない、SSI ディレクティブを含む静的 HTML ドキュメントで、ページが提供されるときに、日付と時刻、その他の静的ファイルの内容などの小さな動的データをサーバーソフトウェアによって即座に含めるように解釈されます。
• SAPIサーバー アプリケーション プログラミング インターフェイス:
  • ISAPIインターネット サーバー アプリケーション プログラミング インターフェイス
  • NSAPI Netscape サーバー アプリケーション プログラミング インターフェイス
• PSGI Perl Web サーバー ゲートウェイ インターフェース
• WSGI Python Web サーバー ゲートウェイ インターフェース
• ラックラック Web サーバー ゲートウェイ インターフェース
• JSGI JavaScript Web サーバー ゲートウェイ インターフェイス
• Java サーブレット、JavaServer Pages
• アクティブ サーバー ページ、ASP.NET

• Mozilla: Web サーバーとは何ですか?
• Netcraft: Web サーバー調査に関するニュース