Webサーバー

Webサーバーは答えるプログラムです

ラックとクラウドのロゴを取り払えば、Webサーバーは一つのことを繰り返すプログラム一つです。誰かがつなぐのを待ち、何が欲しいかを読み、文章を返し、また待ちます。

「サーバー」という語は二つのものを指し、人はいつも混ぜて使います。データセンターに置かれた機械もサーバー、ポートで耳を澄ませるプログラムもサーバーです。ここで言うのはプログラムのほうで、それは目の前のノートパソコンでも同じように動きます。

訪問者一人、四つの歩み

1. 耳を澄ますプログラムがポートを一つ占めて待ちます — 例では8084です。ポートは機械に付いた番号付きの扉なので、二つのプログラムが同じ扉を握ることはできません。
2. リクエストを読むブラウザーがつないで数行の文章を送ります。一行目に、どの方法でどのパスが欲しいかが入ります。たとえばパス / をGETしてくれ、という具合です。
3. 判断する何を送るかを決めます。ディスクからファイルを読む、コードを走らせる、データベースに問う。例はいつも同じファイルを送るだけなので20行に収まります。
4. 答えて切るステータス行といくつかのヘッダー、空行を一つ、そして中身を書いて送り、接続を切って次の訪問者のために最初へ戻ります。

シェルスクリプト一枚で作るWebサーバー

下がbashで書いた完全なWebサーバーです。ポートを開き、リクエスト行を読み、記録を残し、index.htmlをきちんとしたHTTPレスポンスとして返します。二十行、ライブラリなし、そしてブラウザーは違いに気付きません。

重い仕事は二つのコマンドが担います。netcat(nc)がネットワークを話し、mkfifoが名前付きパイプを作って、書いた答えをncが握っている接続へ戻します。

#!/bin/bash

PORT=8084
PIPE=simple-web-server-pipe

rm -f "$PIPE"
mkfifo "$PIPE"

response() {
    read -r method path _
    echo "[$(date)] $method $path" >&2
    index=$(cat index.html)
    printf 'HTTP/1.1 200 OK\r\nContent-Type: text/html; charset=utf-8\r\nConnection: close\r\n\r\n%s' \
      "$index"
}

while true; do
    response < "$PIPE" | nc -l "$PORT" > "$PIPE"
done

一行ずつ読む

1. PORT=8084耳を澄ますポートです。1024より大きい番号は管理者権限なしで使え、8084なら既に動かしているものとぶつかりにくいでしょう。
2. PIPE=simple-web-server-pipeパイプファイルの名前です。フォルダーにはふつうのファイルのように現れますが、中に保存されるものはありません — 二つのコマンドの間をデータが通り抜けるだけです。
3. mkfifo "$PIPE"名前付きパイプ(FIFO)を作ります。すぐ上の行が前回の残りを消しているのは、mkfifoが既にあるファイルへの上書きを拒むからです。
4. read -r method path _リクエストの一行目を読んで、メソッド・パス・残りに分けます。その後に続くブラウザーのヘッダーは、このサーバーは読み飛ばします。
5. echo "[$(date)] $method $path" >&2記録を一行残します。標準エラーへ向きを変えているおかげで、この文がブラウザーへ行かずターミナルにだけ現れます。
6. index=$(cat index.html)今いるフォルダーのindex.htmlを読んで変数に入れます。サーバーをそのファイルのあるフォルダーで起動しなければならない理由がこれです。
7. printf 'HTTP/1.1 200 OK\r\n…'レスポンスを書きます。ステータス行、中身の種類、ここで接続を終えるというヘッダー、そして空行とページ。ヘッダーと中身を分けるのがその空行で、HTTPはすべての行末にキャリッジリターンと改行を求めます。
8. response < "$PIPE" | nc -l "$PORT" > "$PIPE"これが動く仕掛けです。ncは|の前のresponseが書いたレスポンスを受け取ってブラウザーへ送り、ブラウザーのリクエストはFIFOファイル（$PIPE）に書き込みます。responseはそのFIFOからリクエストを読みます。両側が互いに餌を与え合う形です。
9. while true; do … done繰り返しです。ncは接続を一つ処理すると終わってしまうので、この行がなければサーバーは訪問者を一人受けて止まります。

自分で動かす

スクリプトをserver.shとして保存し、隣にindex.htmlを置いて起動します。そのターミナルは開いたままにして、二つ目のターミナルからリクエストを送ってみてください。

# 1. create an index.html in the same folder
echo '<h1>Hello</h1>' > index.html

# 2. save the script above as server.sh and start it
bash server.sh

# 3. open it in a browser (or check from a second terminal)
open http://localhost:8084
curl http://localhost:8084

ブラウザーを再読み込みしながら一つ目のターミナルを見てください。リクエスト一件ごとに記録が一行増えます。Control-Cで止め、パイプファイルが残っていたら消します。LinuxのncはポートのまえにさらにPオプションが要ることがあり、macOSに標準で入っている版は書いたとおりに動きます。

線の上を実際に流れるもの

接続を開いてみると、自分でも打てたはずのふつうの文字が流れています。シェルWebサーバーが成り立つ理由がこれであり、Webの不具合を当て推量ではなく読んで直せる理由もこれです。

ブラウザーが送るリクエスト

GET / HTTP/1.1
Host: localhost:8084
User-Agent: Mozilla/5.0
Accept: text/html

• 一行目が、このサーバーが読む唯一の部分です。メソッド(GETは取ってくる、POSTは送る)、パス、そしてプロトコルの版。
• Hostはどのサイトが欲しいかを伝えます。一つのサーバーが一つの住所で何百ものドメインを抱えられ、それを見分けるのがこのヘッダーです。
• 残りはブラウザーの自己紹介です。自分がどんなソフトか、どんな形式を読めるか、どの言語が好みか。サーバーは使ってもよいし、無視してもかまいません。

サーバーが送るレスポンス

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Connection: close

<h1>Hello</h1>

• ステータス行です。プロトコルの版と、どうなったかを告げる数字。200は成功という意味です。
• Content-Typeは、続くものをどう読むべきかをブラウザーに教えます。HTMLを間違った種類で送ると、ブラウザーはタグをページではなく文字のまま見せます。
• charsetの部分は実際には省けません。これがないと日本語は文字化けして届きがちです。
• そして空行が一つ。その後ろはすべて中身です。ヘッダーとページを分ける境目は、その空行だけです。

覚えておきたいステータスコード

このサーバーにできないこと

この例は正直な教材であり、ひどいサービスです。どこが足りないかを正確に知ることが、本物のサーバーが代わりに解いてくれる問題を知ることです。

• 一度に一人だけ。ncは接続を一つしか扱わないので、それがふさがっている間ほかの全員が待ちます。
• パスを無視します。何を求めてもindex.htmlが返るだけ — 道案内もなく、二枚目のページもありません。
• すべてHTMLとして送ります。画像もスタイルシートもダウンロードもそれぞれの種類が要るのに、このサーバーは一種類しか知りません。
• HTTPSがありません。すべてが裸で流れるので、途中のどのネットワークでも読めますし書き換えられます。
• 安全装置が一切ありません。リクエストの大きさを測らず、時間切れもなく、うかつに広げれば他人が決めたファイルパスをそのまま読んでしまいます。

Caddy — 読めるまま残った本物のWebサーバー

Caddyは実行ファイル一つでできた現代的なWebサーバーです。シェルの例のすぐあとに学ぶ価値があるのは、読める数行で動くという感覚をそのままに、シェル版にできなかったこと（大勢の同時接続・HTTPS・住所ごとの道分け）を片づけるからです。

いちばんの売りは自動HTTPSです。本物のドメイン名を与えるだけで証明書を取り、入れ、期限が来る前に更新し、httpの訪問者をhttpsへ回します。ほかのサーバーでは数か月ごとに繰り返す雑用です。

インストール

# macOS
brew install caddy

# Ubuntu / Debian — add Caddy's own package list first (official steps)
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install caddy

# with Docker (covered in the Docker tab): serve this folder on port 8080
docker run -p 8080:80 -v "$PWD":/usr/share/caddy caddy:2

コマンド一行でフォルダーを差し出す

設定ファイルは要りません。index.htmlのあるフォルダーへ行って一行打つだけ — 同じネットワークの誰かにページを見せるいちばん速い方法です。

# serve this folder's index.html on port 8080
caddy file-server --listen :8080

# add a directory listing for folders without an index.html
caddy file-server --listen :8080 --browse

Caddyfile

長く置くものならCaddyfileを書きます。ただの文字ファイルで、サイト一つが四行で終わります。

example.com {
	root * /var/www/html
	file_server
	encode gzip zstd
}

1. example.com {サイトの住所です。ここに本物のドメインを書けばCaddyがHTTPS証明書を自分で用意します。localhostと書いても、Caddyは自分で作った証明書でHTTPSを使います。ただのhttpだけにしたいなら、http://localhostや:80のように書きます。
2. root * /var/www/htmlファイルがディスクのどこにあるかです。星印はこのサイトのすべてのパスに当てはめるという意味です。
3. file_serverそのファイルを実際に差し出せ、という行です。この行がないとCaddyはリクエストに何も返しません。
4. encode gzip zstd送る前にレスポンスを圧縮します。一語ですが、遅い回線ではページが目に見えて速く届きます。

リバースプロキシ — リクエストを渡す

たいていのサイトはディスク上のファイルではなく、どこかのローカルポートで耳を澄ませているアプリケーションです。リバースプロキシは外からのリクエストを受けてそのアプリへ渡し、答えを返すサーバーです。一行で済みます。

example.com {
	reverse_proxy 127.0.0.1:8080
}

files.example.com {
	root * /srv/files
	file_server browse
}

一台の機械が複数のサイトを抱える方法もこれです。443番ポートは一つのプログラムしか持てないのでCaddyがそれを握り、訪問者がどのドメインを求めたかを読んで、それぞれ別のアプリへ回します。

必要なコマンド

Docker — 箱に入れたCaddyで、本物のサイトをインターネットへ

Dockerは、プログラムと、それが動くのに必要なものすべてを、一つのDockerイメージに詰め込みます。ライブラリ、設定、小さなオペレーティングシステムまで入ります。そして、そのイメージをコンテナとして動かします。コンテナは自分のノートパソコンでも借りたサーバーでも同じように動きます。だから「自分のパソコンでは動くのに」という昔ながらの言い訳がなくなります。

Caddyはもともとファイル一つなのに、なぜわざわざDockerを使うのでしょう。本物のサーバーでは、すぐに複数のものが一緒に動くようになるからです — サイト、アプリ、データベース。Dockerはその一つひとつに専用の箱を与え、同じ数個のコマンドで起動・停止・更新・削除できるようにします。サーバーにほかのものを入れる必要はなく、隣の箱を邪魔することもありません。

最初に知っておきたい四つの言葉

1. イメージプログラムと、それに必要なものすべてを凍らせた包みです。ダウンロードする(caddy:2)か、Dockerfileというレシピのファイルから自分で作ります。動いている間に変わることはありません。
2. コンテナ動いているイメージです。一つのイメージから多くのコンテナを起動でき、コンテナを消してもイメージには手が触れません — 次に起動すると新品の状態から始まります。
3. ポートマッピングコンテナには、外からは見えない自分だけのポートがあります。-p 8080:80は自分のパソコンの8080番ポートをコンテナの中の80番ポートにつなぎ、ブラウザーが届くようにします。
4. ボリュームコンテナが自分の中に書いたファイルは、コンテナを消すと一緒に消えます。ボリューム、またはコンテナにつないだ自分のフォルダーは、残り続ける保存場所です — ページ、設定、そしてCaddyの証明書がそこに住みます。

Dockerのインストール

MacやWindowsのパソコンでは、docker.comからDocker Desktopをインストールして一度起動しておきます。するとターミナルでdockerコマンドが使えるようになります。Linuxサーバーでは、Docker公式のスクリプトが一行ですべてを入れてくれます。先へ進む前に、確認用のコマンドが二つとも答えを返すことを確かめてください。

# macOS · Windows: install Docker Desktop from docker.com and start it once

# Ubuntu / Debian server: Docker's official install script
curl -fsSL https://get.docker.com | sh

# check that both commands answer
docker --version
docker compose version

コマンド一つでCaddy

index.htmlのあるフォルダーへ行き、下の一行を実行します。初回はDockerがCaddyのイメージをダウンロードし、二回目からは一秒ほどで起動します。http://localhost:8080を開けば、自分のページがそこにあります。

# serve this folder at http://localhost:8080 (Control-C stops it)
docker run --rm -p 8080:80 -v "$PWD":/usr/share/caddy caddy:2

1. docker runイメージからコンテナを作り、起動します。
2. --rm止まったらすぐにコンテナを消します。止まったコンテナが溜まっていかないようにするためです。イメージは残るので、次の実行も同じく速く始まります。
3. -p 8080:80自分のパソコンの8080番ポートを、Caddyが耳を澄ませているコンテナの中の80番ポートにつなぎます。左の数字は自由に選べ、右の数字はイメージが決めています。
4. -v "$PWD":/usr/share/caddy今のフォルダー($PWD)を、コンテナの中では/usr/share/caddyとして見せます — 公式イメージが標準で差し出すフォルダーです。ここでファイルを直せば、次の再読み込みで変化が見えます。
5. caddy:2実行するイメージ — 公式のCaddyイメージで、2.xのどれかの版です。:2のタグを付けないとDockerはlatestを取ってくるため、ある日突然、足元で大きな版に切り替わるかもしれません。

Control-Cで止めます。ちょっと見るには最高ですが、コマンドが長く、ターミナルを閉じた瞬間に忘れられてしまいます。長く置くものはファイルに書き残します — それが次のプロジェクトです。

よく使うコマンド