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はパイプからこちらのレスポンスを読み、ブラウザーのリクエストをそのパイプへ書き戻します。両側が互いに餌を与え合う形です。
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です。本物のドメイン名を与えるだけで証明書を取り、入れ、期限が来る前に更新し、httpの訪問者をhttpsへ回します。ほかのサーバーでは数か月ごとに繰り返す雑用です。

インストール

# macOS
brew install caddy

# Ubuntu / Debian
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
sudo apt update && sudo apt install caddy

# Docker alone is enough
docker run -p 8080:80 -v "$PWD":/usr/share/caddy caddy

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

設定ファイルは要りません。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と書けばローカル作業用にふつうのhttpを出します。
2. root * /var/www/html ファイルがディスクのどこにあるかです。星印はこのサイトのすべてのパスに当てはめるという意味です。
3. file_server そのファイルを実際に差し出せ、という行です。この行がないとCaddyはリクエストに何も返しません。
4. encode gzip zstd 送る前にレスポンスを圧縮します。一語ですが、遅い回線ではページが目に見えて速く届きます。

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

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

getpes.com {
	reverse_proxy pes-web:3000
}

dl.getpes.com {
	root * /srv/files
	file_server browse
}

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

必要なコマンド