用語辞典・サーバー・Web運営

Webサーバー

Webサーバーとは

Webサーバーは、HTTPやHTTPSの要求を受け、Webページやファイル、アプリの応答を返すソフトウェアまたは機器です。中心はHTTPのサーバーとして動くプログラムで、Apache HTTP Serverやnginxなどがあります。

日常会話では、そのソフトウェアを動かす物理機や仮想機まで「Webサーバー」と呼びます。仕組みを考えるときは、要求へ応答するソフトウェアと、それを実行するコンピューターを分けます。

Webサーバーは保存されたHTMLを返すだけではありません。要求のホスト名とパスを読み、静的ファイル、別のアプリ、キャッシュ、リバースプロキシなど適切な処理へ振り分けます。

ブラウザーの要求を受け、静的ファイルまたはアプリ処理へ分岐し、一つのHTTP応答を返すURLの資源を、状態コード・ヘッダー・内容として表現する
ブラウザーからTLSで保護された要求がWebサーバーへ入り、静的ファイル棚とアプリ処理へ分岐し、状態・ヘッダー・内容を持つ応答とログを返すWebサーバーのピクトグラム図解
図1RFC 9110のオリジンサーバーは、対象資源について権威ある応答を生成できるプログラムを指します。前段にプロキシがあっても、背後にオリジンが存在します。

要求を受けて応答するまで

接続からログ記録まで、要求が通る判定点を順に切り分ける表示できない原因を、DNS・TLS・HTTP・アプリ・ファイルへ分けられる
  1. 01
    接続を受け付ける

    設定されたIPアドレスとポート番号でTCPまたはQUICの接続を受ける。

  2. 02
    TLSを確立する

    HTTPSでは証明書と秘密鍵を使い、ホスト名を検証できる暗号化通信路を作る。

  3. 03
    HTTP要求を解析する

    方式、対象、Host、ヘッダー、必要ならコンテンツを読み、形式と大きさを検査する。

  4. 04
    処理先を選ぶ

    仮想ホストとURLパスから、静的ファイル、アプリ、プロキシ、リダイレクト、拒否を決める。

  5. 05
    応答を組み立てる

    ステータスコード、応答ヘッダー、表現データを生成してクライアントへ返す。

  6. 06
    結果を記録する

    時刻、要求先、状態、転送量、処理時間をアクセスログへ、失敗理由をエラーログへ残す。

図2前段のCDNやリバースプロキシで一部手順を行う構成もあります。どの層が応答したかをログとヘッダーで確認します。

ドメイン名から仮想ホストを選ぶ

一つのWebサーバーは複数サイトを扱えます。HTTPSの接続開始時はSNI、HTTP要求ではHost情報を使い、要求されたホスト名に対応するvirtual host(バーチャル・ホスト)を選びます。

DNSはドメイン名を接続先IPへ案内しますが、どのフォルダーやアプリを返すかはWebサーバーの設定です。DNSが正しくても仮想ホストに名前が登録されていなければ、既定サイトやエラーが表示されます。

文書ルートはURLとファイルを結ぶ基点

document root(ドキュメント・ルート)は、静的ファイルを公開する基準ディレクトリです。たとえば要求パスが/images/logo.webpなら、設定された文書ルートの下にある対応ファイルを探します。

URLの..や符号化をそのままOSのパスへつなげると、公開範囲の外を読まれる恐れがあります。Webサーバーはパスを正規化し、symlink、権限、索引、ディレクトリーlistingを方針に従って扱います。

静的内容と動的内容を分ける

HTML、CSS、JavaScript、画像など保存済みファイルをそのまま返すのが静的配信です。更新されるまで、同じURLへ基本的に同じバイト列を返せます。Content-Type、Last-Modified、ETag、Cache-Controlなども設定します。

利用者や時刻で内容を変える場合は、PHP、アプリサーバー、FastCGI、リバースプロキシなどへ要求を渡します。アプリの出力も最終的にはWebサーバーからHTTP応答として返ります。

HTMLを直接開くこととサーバー経由は違う

PC上の索引.HTMLをダブルクリックすると、アドレスはfile:になり、ブラウザーがローカルファイルを直接読みます。WebサーバーへHTTP要求を送っていないため、PHPなどのサーバー側処理、URL書き換え、認証、データベース接続は動きません。

ルート相対URL/assets/site.cssは、HTTPならサイトのオリジンを基準にしますが、ファイルでは同じ意味で解決できません。静的サイトでもローカル確認には簡易HTTPサーバーを使うと、本番に近いURL解決、MIME種類、JavaScriptの取得制約で確認できます。

ステータスコードは処理結果、画面文は表現

200は要求が成功したこと、301・302は別URLへの案内、403は拒否、404は対象を見つけられないこと、500系はサーバー側の失敗を示します。同じエラーページの見た目でも、ステータスコードは異なり得ます。

エラー時に内部パス、SQL、スタックトレース、秘密を利用者へ返しません。利用者には追跡用IDと一般的な案内を示し、詳細はアクセス制限されたログへ記録します。

TLS終端とリバースプロキシ

WebサーバーはHTTPSのTLSを終端し、証明書を提示できます。また、受けた要求を背後のアプリサーバーへ転送するreverse proxy(リバース・プロキシ)として、認証、圧縮、キャッシュ、負荷分散をまとめることがあります。

背後へHTTPで渡すかHTTPSで再暗号化するか、元のスキーム・ホスト・クライアントIPをどのヘッダーで伝えるかを設計します。転送ヘッダーを無条件に信頼すると、アクセス制御やURL生成を偽られるため、信頼するプロキシを限定します。

ログは公開せず、保持目的を決める

アクセスログにはIPアドレス、URL、時刻、user-agent、参照元、状態、転送量などが含まれ、個人や秘密を推測できる場合があります。問い合わせ文字列やヘッダーへ認証情報を置かず、ログの閲覧権限、マスキング、保持期間、ローテーションを決めます。

Webサーバーの切り分けでは、接続できるか、TLSが成立するか、HTTP状態は何か、静的ファイルかアプリか、どのログに失敗理由があるかを順に確認します。

HTTPサーバーの確認資料:RFC 9110(HTTP Semantics)Apache HTTP Server Getting Startednginx Beginner’s Guide

関連用語