いにしえのネットワーク入門

• 形 ── 1行目、ヘッダー、空行、本文。申請は見出し 149 バイト＋本文 54 バイト（実測）
• メソッドとステータス ── 何をしてほしいかと、どうなったか。この回で10種類のコードを返させた（実測）
• 速くする工夫 ── 304 で本文 0 バイト、gzip で 2 MB が 6 KB、HTTP/2 で1本の接続に同時に（実測）
• 開発者の落とし穴 ── クッキーの3つの印、CORS のエラーはだれが直すか

HTTP は、TCP/IP の層で言えば第7層、アプリの層のいちばん上の取り決めです。練習用ネットワークは第9回と同じで、PC と、片道 20 ミリ秒のいたずら線の向こうの申請サーバー（Node.js）です。サーバーは、HTTP（3000 番）、HTTPS（3443 番。HTTP/1.1 と HTTP/2 の両方）、暗号なしの HTTP/2（3080 番。観察用）で待ち受けます。

中身を見るため、いったん鍵なしの HTTP で申請を送り、curl -v と Wireshark で記録しました（Wireshark の画面は表紙の写真）。

# リクエスト：1行目（メソッド・パス・版）、ヘッダー、空行、本文
    POST /api/expenses HTTP/1.1
    Host: expenses.example:3000
    User-Agent: curl/8.5.0
    Accept: */*
    Content-Type: application/json
    Content-Length: 54
    
    {"date":"2026-10-25","item":"交通費","amount":1280}
# レスポンス：1行目（版・ステータスコード）、ヘッダー、空行、本文
    HTTP/1.1 201 Created
    Location: /api/expenses/EXP-2026-0012
    Content-Type: application/json
    Content-Length: 43
    Date: Sun, 25 Oct 2026 00:28:31 GMT
    Connection: keep-alive
    Keep-Alive: timeout=5
    
    {"id":"EXP-2026-0012","status":"submitted"}

リクエストの1行目は「何を（POST）・どこに（/api/expenses）・どの版で（HTTP/1.1）」。続くヘッダーは「名前: 値」の行で、Host は宛先の名前（1台のサーバーがいくつもの名前を受け持つので必須です）、Content-Type は本文の種類、Content-Length は本文の長さです。空行でヘッダーが終わり、そのあと 54 バイトの JSON が続きます。

第6回で、TCP は区切りのない「流れ」だと書きました。どこまでが1つの申請なのかは、上の層が決めるしかない。その答えがこれです。空行までがヘッダー、そこから Content-Length バイトが本文。サーバーはこの決まりで流れを切り分けます。

レスポンスの1行目は「版・ステータスコード・説明」。201 Created は「作りました」で、Location に新しい申請の場所が書いてあります。最後の Connection: keep-alive と Keep-Alive: timeout=5 は、「この接続は5秒間つないだままにしておくので、次の頼みごとにも使ってよい」という意味です。第6回と第8回で見た、TCP と TLS のあいさつを省く「接続の使い回し」は、ここで約束されます。

1行目の最初の語がメソッドです。同じ /api/expenses でも、GET なら「一覧を見せて」、POST なら「新しく申請して」になります。

大事なのは右から2列目、冪等（べきとう）です。「同じ頼みごとを何度送っても、結果は1回のときと同じ」という性質で、HTTP の仕様（RFC 9110）は GET・HEAD・OPTIONS などの安全なメソッドと、PUT・DELETE を冪等としています。冪等なら、返事が来ないまま時間切れになっても、安心して送り直せます。

練習用のサーバーに、わざといろいろな頼み方をして、返事の1行目を並べました。

# 同じ API に、いろいろなリクエストを送ったときの返事（1行目と、関係するヘッダー）
    GET /api/expenses                  → 200 OK
    POST /api/expenses（JSON）         → 201 Created Location: /api/expenses/EXP-2026-0013
    POST（JSON が壊れている）          → 400 Bad Request
    POST（Content-Type: text/plain）   → 415 Unsupported Media Type
    POST（amount が文字列）            → 422 Unprocessable Entity
    PUT /api/expenses                  → 405 Method Not Allowed Allow: GET, POST
    GET /expenses（古い URL）          → 301 Moved Permanently Location: /api/expenses
    GET /api/expenses/EXP-2026-9999    → 404 Not Found
    DELETE（鍵なし）                   → 401 Unauthorized WWW-Authenticate: Bearer
    DELETE（鍵あり）                   → 204 No Content

3桁の数の最初の数字が組を表します。2xx は成功、3xx は「別の場所へ」、4xx は「頼み方が悪い」、5xx は「サーバーが悪い」。4xx なら直すのは送った側（フロントエンド）、5xx ならサーバー側。障害のときにまず見るのは、この1桁です。

4xx の中にも使い分けがあります。400 は JSON が壊れていて読めない、415 は「JSON しか受け付けないのに text/plain が来た」、422 は「読めたが、金額が文字列で中身がおかしい」。401 は「だれだかわからない（鍵を見せて）」で、WWW-Authenticate に鍵の種類を添えます。だれだかわかったうえで「あなたには許さない」は 403 です。

経費の一覧は、開くたびに同じ中身が返ることがほとんどです。毎回全部を運ぶのはもったいない。そこでサーバーは、一覧と一緒に中身の印、ETag を渡します。

# 1回目：一覧と一緒に、中身の印（ETag）が返る
pc$ curl -D - http://expenses.example:3000/api/expenses
    HTTP/1.1 200 OK
    ETag: "41dc1e7dc5a9"
    Cache-Control: no-cache
    （本文 153 bytes）
# 2回目：「この印のものなら持っている」と添えて聞く
pc$ curl -D - -H 'If-None-Match: "41dc1e7dc5a9"' http://expenses.example:3000/api/expenses
    HTTP/1.1 304 Not Modified
    ETag: "41dc1e7dc5a9"
    （本文 0 bytes）

2回目は If-None-Match で「この印のものなら持っている」と添えて聞き、サーバーは中身が変わっていないので 304 Not Modified、本文 0 バイトで答えました。往復の回数は同じですが、一覧が大きいほど効きます。ブラウザは、これを何も言わなくても自動でやっています。

Cache-Control: no-cache は名前に反して「しまうな」ではなく、「しまってよいが、使う前に毎回サーバーに確かめよ」という意味です（RFC 9111）。本当にしまってほしくないときは no-store。max-age=600 なら「10分間は聞かずに使ってよい」で、その間は往復もなくなります。

HTTP は、1つの頼みごとが終わるとすべて忘れます（ステートレス）。では「ログインしている」は、どうやって覚えているのか。ここからは HTTPS（3443 番）で試しました。

# ログイン前に「わたしは誰？」と聞く
pc$ curl https://expenses.example:3443/api/me
    {"error":"login required"}
# ログインすると、サーバーがクッキーを渡す
pc$ curl -c jar.txt -X POST … https://expenses.example:3443/login
    HTTP/2 200 
    set-cookie: sid=480df7…; Path=/; HttpOnly; Secure; SameSite=Lax
# 次のリクエストにクッキーを付けて聞く
pc$ curl -b jar.txt https://expenses.example:3443/api/me
    {"user":"arai"}

ログインすると、サーバーは Set-Cookie で番号札（sid）を渡します。PC はそれをしまい、以後同じサーバーへの頼みごとに毎回 Cookie として付けます。サーバーは番号から「新井さんだ」と引く。HTTP 自身は忘れっぽいままで、覚えている「ふり」をさせているのがクッキーです。第8回で見た、OSI の第5層「会話の管理」の役は、実際にはここで果たされています。

札の後ろに付いた3つの印は、開発者がいちばん気にするところです。HttpOnly は JavaScript から読めなくする、Secure は HTTPS のときだけ送る、SameSite=Lax はよそのサイトから飛んできたときの多くの頼みごとに付けない。番号札は鍵そのものなので、盗まれにくく、勝手に使われにくくしておくわけです。

画面を https://app.expenses.example に、API を https://expenses.example:3443 に置いたとします。名前が違うので、2つは別の Origin（http/https・名前・番号の組）です。ブラウザは、あるページの JavaScript が別の Origin の返事を読むことを、ふつうは許しません。許すかどうかを API 側が答える取り決めが CORS です。

JSON を POST するとき、ブラウザは本番の前に OPTIONS で「下見」（preflight）をします。その下見を curl で再現しました。

# 下見（preflight）：https://app.expenses.example の画面から POST してよいか
    OPTIONS /api/expenses
    Origin: https://app.expenses.example
    Access-Control-Request-Method: POST
    Access-Control-Request-Headers: content-type
  →
    HTTP/2 204 
    access-control-allow-origin: https://app.expenses.example
    access-control-allow-methods: GET, POST, DELETE
    access-control-allow-headers: Content-Type, Authorization
    access-control-max-age: 600
# 知らない Origin（https://other.example）からだと、許可のヘッダーが付かない
  →
    HTTP/2 204 

許可した Origin には Access-Control-Allow-Origin などが付き、知らない Origin には何も付きません。どちらも 204 で、サーバーは「断る」とは言っていない点に注意してください。止めるのはブラウザです。許可のヘッダーがなければ、ブラウザは本番を送らず、開発者ツールの Console に CORS のエラーを出します。

経費の CSV（2 MB）の書き出しを、10 Mbit/s に絞った線で取りました。

# CSV 2 MB を、そのまま／gzip で（10 Mbit/s・片道 20 ms の線）
pc$ curl https://expenses.example:3443/api/export.csv
    2,097,152 bytes   1.934 s
pc$ curl --compressed …   (Accept-Encoding: deflate, gzip, br, zstd → Content-Encoding: gzip)
        6,179 bytes   0.142 s

PC が Accept-Encoding で「この縮め方なら読める」と伝え、サーバーが Content-Encoding: gzip で縮めて返す。2,097,152 バイトが 6,179 バイトになり、1.934 秒が 0.142 秒になりました。ブラウザも同じことを自動でやっています。

ただし、この CSV は同じ行のくり返しなので、極端に縮みました。番号・日付・金額がばらばらの 2 MB の CSV を作って同じく gzip にかけると、428,597 バイト、約5分の1です。文字のデータ（HTML、JSON、CSV）はよく縮み、もともと縮めてある JPEG や動画はほとんど縮みません。

1つの画面は、たいてい何十もの頼みごとでできています。100 ミリ秒かかる報告を6本、HTTPS で取って比べました。

# 100 ms かかる報告を 6 本（HTTPS・片道 20 ms）
    HTTP/1.1 で順番に      0.953 s   1本の接続
    HTTP/1.1 で同時に      0.246 s   6本の接続
    HTTP/2 で同時に        0.245 s   1本の接続

HTTP/1.1 は、1本の接続で一度に1つしか頼めません。順番にやると、使い回しの接続でも 0.953 秒。速くするには接続を何本も張るしかなく、6本で 0.246 秒になりました。ブラウザも同じ理由で、1つの相手に6本ほどの接続を張ります。その分、TCP と TLS のあいさつも6回です。

HTTP/2 は、1本の接続の上で頼みごとに番号（ストリーム）を振り、同時に進めます（多重化）。1本のまま 0.245 秒でした。中身は文字の行ではなく二進の枠（フレーム）になりましたが、メソッドもステータスもヘッダーも意味は同じです。

HTTPS では、どの版で話すかを TLS の握手のついでに決めます（ALPN。第8回で見た Client Hello に「h2 も話せます」と書いて送ります）。ブラウザが HTTP/2 を使うのは HTTPS のときだけで、写真の暗号なしの HTTP/2 は、観察のための特別な設定です。

HTTP/2 にも弱点が残りました。下の TCP は1本の流れなので、パケットが1つ落ちると、関係ないストリームまで送り直しを待たされます（第7回の「先頭のつかえ」）。そこで HTTP/3 は、UDP の上の QUIC に引っ越しました。QUIC はストリームごとに順番を守り、TLS 1.3 も組み込みです。ブラウザは、返事の Alt-Svc ヘッダーや DNS の HTTPS レコード（第9回）で「この相手は HTTP/3 も話せる」と知り、次から切りかえます。

まずは、ふだん使っている Web サイトを開いて Network タブを眺めてみましょう。1枚の画面に、どれだけの頼みごとが、どの版で、どれだけ縮められて流れているかが見えます。