Webサーバー

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

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

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

訪問者一人、四つの歩み

シェルスクリプト一枚で作る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

一行ずつ読む

自分で動かす

スクリプトを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
}

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

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

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

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

よく使うコマンド