ウェブサーバー

静的コンテンツのみを提供するWebサーバーとネットワーク経由で通信するPCクライアント

Dell PowerEdgeサーバーの内部と前面。ラックマウント環境にマウントするように設計されたコンピューターです。このサーバーと同様のものは、Webサーバーとしてよく使用されます。

トラフィック量の多い Web サイトでは複数の Web サーバーが使用される場合があります。

超高トラフィックのウェブサイトに使用される数千台のウェブサーバーを備えたサーバーファーム

モデムの設定に使用される動的な Web ページを提供する組み込み Web サーバーを実行するADSLモデム

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

ウェブサーバーを稼働させるハードウェアは、処理すべきリクエストの量に応じて異なります。低価格帯のハードウェアとしては、ルーターなどの組み込みシステムがあり、ルーターの設定インターフェースとして小規模なウェブサーバーが稼働しています。トラフィック量の多いインターネットウェブサイトでは、高速コンピュータをラックに搭載した数百台のサーバーでリクエストを処理することもあります。^[6]

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

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

歴史

最初の Web 提案 (1989) は、「漠然としているが、興味深い」と評価されました。

世界初の Web サーバー、イーサネットを備えたNeXT Computerワークステーション、1990 年。ケースのラベルには、「このマシンはサーバーです。電源を切らないでください。」と書かれています。

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

初期のWWWプロジェクト（1989～1991年）

1989年3月、ティム・バーナーズ＝リー卿は、ハイパーテキストシステムを用いて科学者間の情報交換を容易にすることを目的とした新たなプロジェクトを、雇用主である欧州原子核研究機構（CERN ）に提案しました。 「ハイパーテキストとCERN」と題されたこの提案は、意見を求め、複数の関係者によって読み上げられました。1990年10月、この提案は（ロバート・カイヨー氏を共同執筆者として）改訂・拡充され、最終的に承認されました。^{[8] [9] [10]}

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

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

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

1991年8月、ティム・バーナーズ＝リーはWWW技術の誕生を宣言し、科学者たちにその採用と開発を奨励しました。^[13]その後まもなく、これらのプログラムとそのソースコードは、その利用に関心のある人々に公開されました。^[11]ソースコードは正式にライセンスされておらず、パブリックドメインにもなっていませんでしたが、CERNは非公式にユーザーと開発者が実験を行い、さらに開発を進めることを許可しました。バーナーズ＝リーは、これらのプログラムの採用と利用、そして他のオペレーティングシステムへの移植を促進し始めました。^[10]

急速かつ激しい発展（1991～1995年）

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

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

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

1994年初頭、新しいウェブサーバーの中で最も注目を集めたのはNCSA httpdでした。これは様々なUnixベースのOS上で動作し、HTTPメソッドとCGIを実装することで外部プログラムとの通信を可能にし、動的に生成されるコンテンツを提供できました。これらの機能と、NCSAのMosaicブラウザのマルチメディア機能（ HTMLフォームを管理してウェブサーバーにデータを送信することも可能）は、出版や分散コンピューティングアプリケーションにおけるウェブ技術の可能性を浮き彫りにしました。POST

ソースデータを表示します。

アクティブなウェブサイトの数（1991～1996年）^{[15] [16]}

1994年後半、NCSA httpdの開発は停滞し、NCSA httpdのソースコードがパブリックドメインで公開されていたことを受けて、外部のソフトウェア開発者、ウェブマスター、その他このサーバーに興味を持つ専門家グループがパッチの作成と収集を開始しました。1995年初頭、これらのパッチはすべてNCSAソースコードの最終リリースに適用され、数回のテストを経てApache HTTPサーバープロジェクトが開始されました。^{[17] [18]}

1994年末、Netsiteという名の新たな商用ウェブサーバーが、独自の機能を備えてリリースされました。これは、 Netscape社、Sun Microsystems社、そして最終的にOracle社によって開発された、多くの類似製品の最初の製品でした。

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

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

爆発的な成長と競争（1996～2014年）

ソースデータを表示します。

アクティブなウェブサイトの数（1996-2002年）^{[16] [19]}

SunのCobalt Qube 3 – コンピュータサーバーアプライアンス（2002年、販売終了）

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

Apacheは1996年半ばから2015年末まで、最も利用されているウェブサーバーでした。その後数年間の衰退を経て、まずIISに、そしてNginxに追い抜かれました。その後、IISの利用率はApacheを大きく下回りました（市場シェアも参照）。

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

2000 年に入って数年後には、他の商用かつ競争力の高い Web サーバー ( LiteSpeedなど) だけでなく、 Hiawatha、Cherokee HTTP サーバー、Lighttpd、Nginxなどの他のオープンソース プログラムや、商用サポート付きの派生製品や関連製品も数多く登場しました。

2007年から2008年頃、多くの人気ウェブブラウザは、従来のデフォルトの持続接続数制限（ホストドメインあたり2つ、RFC-2616で推奨されている制限）^[23]を、4、6、または8に引き上げました。これは、大量の画像を含む重いウェブページの表示速度を向上させ、ウェブページ内のイベントの双方向通知に使用される動的オブジェクト専用の持続接続が不足する問題を緩和するためでした。^[24]これらの変更により、1年以内にウェブサーバーが管理する必要のある持続接続の最大数は平均で3倍近くに増加しました。この（持続接続数の増加）傾向は、低速ウェブサーバーへのリバースプロキシ導入を強力に後押しするとともに、大量のハードウェアリソース（大量のCPU、RAM、高速ディスクを搭載した高価なコンピュータ）を必要とせずに、そのスピードと膨大な同時接続処理能力を最大限に発揮できる新興のウェブサーバーに新たなチャンスを与えました。^[25]

新たな課題（2015年以降）

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

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

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

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

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

技術概要

インターネット経由でウェブサーバーに接続されたPCクライアント

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

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

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

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

共通の特徴

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

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

• 静的コンテンツの提供: HTTP プロトコル経由でクライアントに静的コンテンツ (Web ファイル) を提供できるようになります。
• HTTP : クライアントの HTTP 要求のバージョンと互換性のある HTTP 応答のバージョンを送信するために、1 つ以上の HTTP プロトコルのバージョンをサポートします (例: HTTP/1.0、HTTP/1.1、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 トラフィックまたはそのパフォーマンスに関する統計を生成します。
• その他のカスタムタスク。

要求メッセージを読む

ウェブサーバープログラムは以下を実行できます: ^{[29] [30] [31]}

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

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

URLの正規化

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

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

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

URLマッピング

URLマッピングとは、URLを分析して参照先のリソースを特定し、そのリソースをリクエスト元のクライアントに返すプロセスです。このプロセスは、ウェブサーバーへのリクエストごとに実行されます。リクエストによっては、HTML文書やGIF画像などのファイルが提供される場合もあれば、CGIプログラムの実行結果が提供される場合もあり、また、組み込みモジュールハンドラ、PHPドキュメント、Javaサーブレットなどの他のプロセスによって提供される場合もあります。^{[32] [要更新]}

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

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

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

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

URL パスをファイル システムに変換

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

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

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

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

ウェブサーバーは、要求された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
ホスト: www.example.com
接続: キープアライブ

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

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

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

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

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

http://www.example.com/directory1/directory2/

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

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

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

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

ウェブサーバーはディレクトリの存在を確認し、ディレクトリが存在しアクセス可能な場合はインデックスファイル（この場合は存在しません）を検索します。そして、ディレクトリ一覧表示専用の内部モジュールまたはプログラムにリクエストを渡し、最終的に出力データを読み取り、クライアントのウェブブラウザに応答を送信します。応答にはディレクトリの内容（含まれるサブディレクトリとファイルのリスト）が記載されるか、ディレクトリが存在しない、またはアクセスが禁止されていることを示すエラーメッセージが返されます。

動的プログラムリクエストの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
ホスト: 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 ヘッダーの値が含まれる場合があります）に応じて管理される必要があります。

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

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

静的コンテンツを提供する

静的コンテンツのみを提供するWebサーバーとネットワーク経由で通信するPCクライアント

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

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

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

• OPTIONS
• HEAD
• GET

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

ディレクトリインデックスファイル

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

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

通常のファイル

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

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

動的コンテンツを提供する

静的および動的コンテンツを提供するウェブサーバーとネットワーク経由で通信する PC クライアント

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

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

• POST

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

標準的かつ歴史的なゲートウェイ インターフェイスは次の 3 つです。

CG

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

SCGI

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

高速CGI

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

ディレクトリリスト

ウェブサーバーによって動的に生成されるディレクトリリスト

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

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

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

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

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

プログラムまたはモジュールの処理

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

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

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

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

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

応答メッセージを送信する

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

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

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

エラーメッセージ

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

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

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

URL認証

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

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

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

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

URLリダイレクト

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

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

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

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

送信元:
  /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/

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

成功メッセージ

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

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

コンテンツキャッシュ

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

コンテンツは通常、そのオリジンによってキャッシュされます。

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

ファイルキャッシュ

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

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

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

実際には、今日では多くのウェブサーバープログラムには、ウェブサーバーの使用に合わせてカスタマイズされた独自のユーザーランド ファイルキャッシュが含まれており、特定の実装とパラメータを使用しています。 ^{[46] [47] [48]}

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

動的キャッシュ

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

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

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

カーネルモードとユーザーモードのウェブサーバー

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

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

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

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

公演

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

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

パフォーマンスメトリック

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

• の数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 プログラムを含む)。
• Web サーバーが実行されるコンピューターのハードウェアおよびソフトウェアの制限またはOSの設定。
• その他の軽微な症状。

ベンチマーク

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

荷重制限

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

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

過負荷の原因

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

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

過負荷の症状

ウェブ サーバーの過負荷の症状は通常、次のようになります。

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

過負荷防止技術

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

• ハードウェアの機能と使用状況に合わせて OS パラメータを調整します。
• Web サーバーのパラメータを調整して、セキュリティとパフォーマンスを向上させます。
• Web キャッシュ技術を導入する(静的コンテンツだけでなく、可能な場合は動的コンテンツにも)。
• 次のものを使用してネットワーク トラフィックを管理します。
  • 不正な IP ソースから送信される、または不正なパターンを持つ不要なトラフィックをブロックするファイアウォール。
  • 不正なHTTPパターンを持つリクエストをドロップ、リダイレクト、または書き換える HTTP トラフィック マネージャー。
  • ネットワーク使用量のピークを抑えるための帯域幅管理とトラフィック シェーピング。
• 異なるドメイン名、IP アドレス、およびコンピューターを使用して、異なる種類 (静的および動的) のコンテンツを提供します。その目的は、大きいファイル ( ) (そのドメインはCDNに置き換えられる場合もあります) を小中サイズのファイル ( ) およびメインの動的サイト (一部のコンテンツがバックエンド データベースに保存されている場合もあります) ( ) から分離することです。そのアイデアは、Web サーバー コンピューターごとに異なる設定を使用することで、大きいファイル (10 - 1000 MB 以上) を効率的に提供し (ダウンロードを調整する場合もあります)、小中サイズのファイルを完全にキャッシュして、高負荷の動的サイトのパフォーマンスに影響を与えないようにすることです。 download.*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に加えて、利用可能なウェブサーバーソフトウェアが後者の2つのプロトコルを確実にサポートしている場合はHTTP/2 、場合によってはHTTP/3も有効にする）。これにより、各クライアントが開始するTCP/IP接続の数と交換されるデータサイズが大幅に削減される（HTTPヘッダーの表現がよりコンパクトになり、データ圧縮も可能になる）。ただし、暗号化の必要性によって生じるRAMとCPUの過負荷は防げない可能性がある。また、同時実行に最適化されているため、過度に大きなファイルを高速でアップロードすることによる過負荷にも対処できない可能性がある。^{[58] [59]}

市場占有率

チャート: 2005～2021年における最も人気のあるウェブサーバーの
全サイトの市場シェア

チャート: 1995～2005年における最も人気のあるウェブサーバーの
全サイトの市場シェア

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

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

参照

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

動的コンテンツに使用される標準 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

参考文献

1. ナンシー・J・イェーガー、ロバート・E・マクグラス (1996). Webサーバー技術. モーガン・カウフマン. ISBN 1-55860-376-X. 2023年1月20日時点のオリジナルよりアーカイブ。2021年1月22日閲覧。
2. ウィリアム・ネルソン、アルヴィンド・スリニヴァサン、ムルティ・チンタラパティ (2009). Sun Web Server: The Essential Guide. ピアソン・エデュケーション. ISBN 978-0-13-712892-1. 2023年1月20日時点のオリジナルよりアーカイブ。2021年10月14日閲覧。
3. 「Webサーバーとは何か？ - MDN Web Docs」MDN Web Docs 2025年3月13日. 2025年3月20日閲覧。
4. 「Webサーバーとは何か、どのように機能するのか？ - IT用語集 | SolarWinds」www.solarwinds.com . 2025年4月26日閲覧。
5. 「ウェブサーバーとは何か？」Akamai.com 2025年4月26日
6. 「Webサーバーに関する学習教材 - eGyanKosh」(PDF) . eGyanKosh . 2025年3月20日閲覧。
7. 「Webの短い歴史」CERN . 2025年3月20日閲覧。
8. Zolfagharifard, Ellie (2018年11月24日). 「『ウェブの父』ティム・バーナーズ＝リー卿、フェイクニュース対策計画について語る」 . The Telegraph . ロンドン. ISSN  0307-1235. 2022年1月11日時点のオリジナルよりアーカイブ。 2019年2月1日閲覧。
9. 「ティム・バーナーズ＝リーのコンピュータとコンピューティング、インターネット、誕生、ワールド・ワイド・ウェブの歴史」history-computer.com。2019年1月4日時点のオリジナルよりアーカイブ。 2019年2月1日閲覧。
10. Tim Berner-Lee (1992). “WWW Project History (original)”. CERN (World Wide Web project). 2021年12月8日時点のオリジナルよりアーカイブ。 2021年12月20日閲覧。
11. Tim Berner-Lee (1991年8月20日). “WorldWideWeb 広域ハイパーテキストアプリが利用可能になりました（発表）”. CERN (World Wide Web プロジェクト). 2021年12月2日時点のオリジナルよりアーカイブ。 2021年10月16日閲覧。
12. Web Administrator. 「Web History」. CERN (World Wide Web プロジェクト). 2021年12月2日時点のオリジナルよりアーカイブ。 2021年10月16日閲覧。
13. Tim Berner-Lee (1991年8月2日). 「ハイパーテキストリンクの修飾子...」 CERN (World Wide Web プロジェクト). 2021年12月7日時点のオリジナルよりアーカイブ。 2021年10月16日閲覧。
14. Tim Smith; François Flückiger. 「Licensing the Web」. CERN (World Wide Web プロジェクト). 2021年12月6日時点のオリジナルよりアーカイブ。 2021年10月16日閲覧。
15. Ali Mesbah (2009). AjaxベースのシングルページWebアプリケーションの分析とテスト. ISBN 978-90-79982-02-8. 2021年12月18日閲覧。
16. Robert H'obbes' Zakon. 「Hobbes' Internet Timeline v5.1 (WWW Growth) NOTE: until 1996 number of web servers = number of web sites」. ISOC. 2000年8月15日時点のオリジナルよりアーカイブ。 2021年12月18日閲覧。
17. “NCSA httpd”. NCSA (ウェブアーカイブ). 2010年8月1日時点のオリジナルよりアーカイブ。 2021年12月16日閲覧。
18. 「Apache HTTPdサーバーについて：Apacheの誕生秘話」Apache：HTTPdサーバープロジェクト。1997年。2008年6月7日時点のオリジナルよりアーカイブ。 2021年12月17日閲覧。
19. 「Webサーバー調査、注：2000年のアクティブなウェブサイトの数は補間されています」Netcraft、2021年12月22日。2021年12月27日時点のオリジナルよりアーカイブ。 2021年12月27日閲覧。
20. “Netcraft: web server software (1996)”. Netcraft (ウェブアーカイブ). 1996年12月30日時点のオリジナルよりアーカイブ。 2021年12月16日閲覧。
21. 「Apache 2.2の新機能の概要」Apache: HTTPdサーバープロジェクト. 2005年. 2021年11月27日時点のオリジナルよりアーカイブ。 2021年12月16日閲覧。
22. 「Apache 2.4の新機能の概要」Apache: HTTPdサーバープロジェクト. 2012年. 2021年11月26日時点のオリジナルよりアーカイブ。 2021年12月16日閲覧。
23. 「接続、持続的接続：実践的な考慮事項」RFC 2616、ハイパーテキスト転送プロトコル -- HTTP/1.1。pp. 46–47. sec. 8.1.4. doi : 10.17487/RFC2616。RFC 2616。
24. “ブラウザの同一ドメインへの最大同時接続数”. 2017年. 2021年12月21日時点のオリジナルよりアーカイブ。 2021年12月21日閲覧。
25. “Linux Web Server Performance Benchmark - 2016 results”. RootUsers. 2016年3月8日. 2021年12月23日時点のオリジナルよりアーカイブ。 2021年12月22日閲覧。
26. 「HTTP/2はHTTP/1.xに取って代わるのか？」IETF HTTPワーキンググループ。2014年9月27日時点のオリジナルよりアーカイブ。2021年12月22日閲覧。
27. 「クライアントおよびサーバーソフトウェアにおけるHTTP/2の実装」IETF HTTPワーキンググループ。2021年12月23日時点のオリジナルよりアーカイブ。 2021年12月22日閲覧。
28. 「なぜTCP接続は1つだけなのか？」IETF HTTPワーキンググループ。2014年9月27日時点のオリジナルよりアーカイブ。 2021年12月22日閲覧。
29. "クライアント/サーバーメッセージング". RFC 7230, HTTP/1.1: メッセージ構文とルーティング. pp. 7–8. sec. 2.1. doi : 10.17487/RFC7230 . RFC 7230.
30. 「不完全なメッセージの処理」。RFC 7230、HTTP/1.1：メッセージ構文とルーティング。p. 34. sec. 3.4. doi : 10.17487/RFC7230。RFC 7230。
31. 「メッセージ解析の堅牢性」RFC 7230、HTTP/1.1: メッセージ構文とルーティング。pp. 34–35. sec. 3.5. doi : 10.17487/ RFC7230。RFC 7230 。
32. R. Bowen (2002年9月29日). 「URLマッピング」(PDF) . Apacheソフトウェア財団. 2021年11月15日時点のオリジナルよりアーカイブ(PDF) . 2021年11月15日閲覧。
33. 「URLをファイルシステムの場所へマッピングする」Apache: HTTPdサーバープロジェクト. 2021年. 2021年10月20日時点のオリジナルよりアーカイブ。 2021年10月19日閲覧。
34. “Dynamic Content with CGI”. Apache: HTTPdサーバープロジェクト. 2021年. 2021年11月15日時点のオリジナルよりアーカイブ。 2021年10月19日閲覧。
35. クリス・シフレット (2003). HTTP開発者ハンドブック. サムズ出版. ISBN 0-672-32454-7. 2023年1月20日時点のオリジナルよりアーカイブ。2021年12月9日閲覧。
36. ASF Infrabot (2019年5月22日). 「ディレクトリリスト」. Apache Foundation: HTTPdサーバープロジェクト. 2019年6月7日時点のオリジナルよりアーカイブ。2021年11月16日閲覧。
37. “Apache: ファイルをダウンロードするためのディレクトリ一覧”. Apache: HTTPdサーバー. 2021年12月2日時点のオリジナルよりアーカイブ。 2021年12月16日閲覧。
38. 「クライアントエラー 4xx」。RFC 7231、HTTP/1.1: セマンティクスとコンテンツ。p. 58. sec. 6.5. doi : 10.17487/ RFC7231。RFC 7231 。
39. 「サーバーエラー 5xx」。RFC 7231、HTTP/1.1: セマンティクスとコンテンツ。pp. 62-63. sec. 6.6. doi : 10.17487/RFC7231。RFC 7231。
40. 「はじめに」. RFC 7235, HTTP/1.1: 認証. p. 3. sec. 1. doi : 10.17487/RFC7235 . RFC 7235.
41. "レスポンスステータスコード：リダイレクト3xx". RFC 7231, HTTP/1.1: セマンティクスとコンテンツ. pp. 53–54. sec. 6.4. doi : 10.17487/RFC7231 . RFC 7231.
42. "Successful 2xx". RFC 7231, HTTP/1.1: セマンティクスとコンテンツ. pp. 51-54. sec. 6.3. doi : 10.17487/RFC7231 . RFC 7231.
43. “Caching Guide”. Apache: HTTPdサーバープロジェクト. 2021年. 2021年12月9日時点のオリジナルよりアーカイブ。 2021年12月9日閲覧。
44. “NGINXコンテンツキャッシング”. F5 NGINX. 2021年. 2021年12月9日時点のオリジナルよりアーカイブ。 2021年12月9日閲覧。
45. Evangelos P. Markatos (1996). 「Webドキュメントのメインメモリキャッシュ」. コンピュータネットワークとISDNシステム. 2023年1月20日時点のオリジナルよりアーカイブ。 2021年12月9日閲覧。
46. “IPlanet Web Server 7.0.9: file-cache”. Oracle. 2010. 2021年12月9日時点のオリジナルよりアーカイブ。 2021年12月9日閲覧。
47. “Apache Module mod_file_cache”. Apache: HTTPdサーバープロジェクト. 2021年. 2021年12月9日時点のオリジナルよりアーカイブ。 2021年12月9日閲覧。
48. “HTTPサーバー: 設定: ファイルキャッシュ”. GNU. 2021年. 2021年12月9日時点のオリジナルよりアーカイブ。 2021年12月9日閲覧。
49. “Apache Module mod_cache_disk”. Apache: HTTPdサーバープロジェクト. 2021年. 2021年12月9日時点のオリジナルよりアーカイブ。 2021年12月9日閲覧。
50. “What is dynamic cache?”. Educative. 2021年. 2021年12月9日時点のオリジナルよりアーカイブ。 2021年12月9日閲覧。
51. 「ダイナミックキャッシュオプションチュートリアル」Siteground. 2021年. 2023年1月20日時点のオリジナルよりアーカイブ。 2021年12月9日閲覧。
52. Arun Iyengar、Jim Challenger (2000). 「動的データのキャッシュによるWebサーバーパフォーマンスの向上」. Usenix . 2021年12月9日閲覧。
53. Jussara M. Almeida ; Virgilio Almeida; David J. Yates (1997年7月7日). 「WebMonitor: World Wide Webサーバーのパフォーマンスを測定するツール」. First Monday . doi : 10.5210/fm.v2i7.539 . 2021年11月4日時点のオリジナルよりアーカイブ。 2021年11月4日閲覧。
54. ティム・フィッシャー著; Lifewire. 「502 Bad Gateway エラーが発生した場合の対処法」Lifewire . 2017年2月23日時点のオリジナルよりアーカイブ。 2019年2月1日閲覧。
55. 「502 Bad Gatewayとは何か、そしてそれをどのように修正するのか？」IT PRO . 2023年1月20日時点のオリジナルよりアーカイブ。 2019年2月1日閲覧。
56. ティム・フィッシャー; Lifewire. 「503 サービス利用不可エラーが発生した場合の対処法」Lifewire . 2023年1月20日時点のオリジナルよりアーカイブ。 2019年2月1日閲覧。
57. ティム・フィッシャー、Lifewire。「504ゲートウェイタイムアウトエラーが発生した場合の対処法」Lifewire。2021年4月23日時点のオリジナルよりアーカイブ。 2019年2月1日閲覧。
58. many (2021年1月24日). “Slow uploads with HTTP/2”. github. 2021年11月16日時点のオリジナルよりアーカイブ。2021年11月15日閲覧。
59. Junho Choi (2020年8月24日). 「HTTP/2アップロード速度の向上を実現」. Cloudflare. 2021年11月16日時点のオリジナルよりアーカイブ。2021年11月15日閲覧。
60. “2021年10月 Webサーバー調査”. Netcraft . 2021年10月15日. 2021年11月15日時点のオリジナルよりアーカイブ。 2021年11月15日閲覧。
61. “February 2021 Web Server Survey”. Netcraft . 2021年2月26日. 2021年4月15日時点のオリジナルよりアーカイブ。 2021年4月8日閲覧。
62. “February 2020 Web Server Survey”. Netcraft . 2020年2月20日. 2021年4月17日時点のオリジナルよりアーカイブ。2021年4月8日閲覧。
63. “February 2019 Web Server Survey”. Netcraft . 2019年2月28日. 2021年4月15日時点のオリジナルよりアーカイブ。 2021年4月8日閲覧。
64. “February 2018 Web Server Survey”. Netcraft . 2018年2月13日. 2021年4月17日時点のオリジナルよりアーカイブ。 2021年4月8日閲覧。
65. “February 2017 Web Server Survey”. Netcraft . 2017年2月27日. 2017年3月14日時点のオリジナルよりアーカイブ。 2017年3月13日閲覧。
66. “February 2016 Web Server Survey”. Netcraft . 2016年2月22日. 2022年1月27日時点のオリジナルよりアーカイブ。 2022年1月27日閲覧。

外部リンク

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