ネットワークプログラミングとサーバの実体

学習目標

本講を終えると、以下を達成できるようになります。

• 「サーバ」も「クライアント」もプロセスであり、ポートを open / listen することで識別される、と説明できる
• ps -ef、ss -tlnp、lsof -i :80 で実行中のサーバプロセスを確認できる
• socket での生 HTTP と python -m http.server で、「クライアント / サーバはポートを掴む 1 つのプロセス」という事実を実感できる
• Apache / nginx / BIND / Postfix / Dovecot / vsftpd の役割を 1 行で言える
• 「ポート 80 を listen するプロセスが Web サーバ」という対応関係を、複数のサーバ実装で説明できる
• 本講のあとに 第29回 HTTP プログラミング で扱う curl / requests / aiohttp / Node.js / 認証実装などとの役割分担を意識できる

このレッスンの目次

なぜ「プロセス」を強調するのか

Web サーバとは「TCP 80 を listen して HTTP メッセージを処理するプロセス」のことです。実装は Apache HTTP Server でも nginx でも、Python の http.server でも、Go の net/http でもかまいません。HTTP というプロトコルに従って要求を読み、応答を書き返せば、ネットワーク上の相手からは Web サーバとして見えます。

1 台のサーバマシンの中に複数のプロセスがいる

図の見方:左のブラウザもプロセス、右の httpd / smtpd / named もプロセスです。サーバマシンが偉いのではなく、どの PID のプロセスがどのポートを listen しているか が実体です。

つながる知識: 標準編で telnet が接続していた相手は「HTTP という概念」ではなく、その瞬間に 80 番ポートを掴んでいた実行中プロセスです。だから nginx を止めれば 80 番の応答は消え、Python サーバを 8000 番で起動すれば 8000 番に新しい応答が現れます。

プロセスとポートを実際に見る

常駐プロセスを探す

# Linux / macOS
ps -ef | grep -E 'httpd|nginx|named|postfix|dovecot|vsftpd' | grep -v grep

# BSD/macOS 風の表示が好みなら
ps aux | grep -E 'httpd|nginx|named|postfix|dovecot|vsftpd' | grep -v grep

listen しているポートを探す

# Linux: TCP の listen 中ソケットとプロセス
sudo ss -tlnp

# Linux: UDP も含めて見る
sudo ss -tulnp

# macOS: listen 中のプロセスを一覧
sudo lsof -i -P -n | grep LISTEN

# 特定ポートだけ見る
sudo lsof -i :80 -P -n

walkthrough: nginx を起動して止める

1. nginx を起動する

sudo systemctl start nginx
ps aux | grep nginx | grep -v grep

2. :80 を nginx が掴んでいることを確認する

sudo ss -tlnp | grep ':80'

# 出力例
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

3. HTTP で応答を確認する

curl -I http://localhost/

# 出力例
HTTP/1.1 200 OK
Server: nginx

4. nginx を止めると :80 が消える

sudo systemctl stop nginx
sudo ss -tlnp | grep ':80'   # 何も出なければ listen していない

クライアントは「ポートへ connect するプロセス」

最小例:socket で生 HTTP リクエストを送る

抽象度を最も下げた例として、TCP ソケットを自分で作り、HTTP/1.1 のリクエスト行とヘッダを文字列で送ります。「接続=ソケット、応答=バイト列」という事実をまず体感する目的のコードです。

# raw_http_client.py
import socket

host = "example.com"
request = (
    "GET / HTTP/1.1\r\n"
    f"Host: {host}\r\n"
    "Connection: close\r\n"
    "\r\n"
)

with socket.create_connection((host, 80), timeout=5) as s:
    s.sendall(request.encode("ascii"))
    chunks = []
    while True:
        data = s.recv(4096)
        if not data:
            break
        chunks.append(data)

print(b"".join(chunks).decode("utf-8", errors="replace")[:1000])

サーバは「ポートを bind / listen するプロセス」

1 行でディレクトリを公開する

# カレントディレクトリを http://localhost:8000/ で公開
python3 -m http.server 8000

# 別ターミナルから確認 ─ 「PID + listen ポート」が見える
curl -I http://localhost:8000/
lsof -i :8000 -P -n

ポイントは lsof -i :8000 の出力に 「python3 (PID) ─ TCP *:8000 (LISTEN)」 が現れること。これだけで 「Python プロセスが Web サーバになっている」 という事実が直接見えます。

telnet で自作サーバを叩く

標準編 第16回 telnet の手法で、自作サーバの応答も観察できます。

python3 -m http.server 8000 &

# 別ターミナル
telnet 127.0.0.1 8000
GET / HTTP/1.1
Host: localhost
Connection: close

# 空行まで送ると、HTTP/1.0 200 OK などの応答が返る

図の見方:Python プログラムも Apache も、ネットワークから見ると「HTTP を話すプロセス」です。違いは実装・性能・機能の厚みであって、ポートで待ち受けてリクエストに応答する という骨格は同じです。

代表的なサーバプログラム

最短で動かすレシピ(Linux)

プロセス・ポート・プロトコルの三角関係

図の見方:PID は OS の管理番号、ポートはネットワーク上の入口、プロトコルは会話の文法、実装プログラムは具体的なコードです。同じ HTTP でも実装プロセスは様々で、同じプロセスが複数ポートを listen することもあります。

プロセスは「停止」「再起動」「複数同時」がある

systemctl で状態を見る

# 稼働状態を見る
systemctl status apache2

# 設定を再読み込みする。接続中の処理をできるだけ保つ
sudo systemctl reload apache2

# プロセスを止めて起動し直す
sudo systemctl restart apache2

# ログを見る
journalctl -u apache2 -f

複数プロセスとリバースプロキシ

図の見方:クライアントから見える入口は nginx の 80 / 443 番だけでも、その裏で複数の Apache プロセスやアプリサーバが動く構成があります。ロードバランサやリバースプロキシも、結局は 別のポートへ接続するプロセス です。

まとめと用語チェック

重要語句

代表 daemon の主役プロトコル

確認問題