ネットワーク基礎：TCP/IP・HTTP・DNS・CDN
HTTP の基本
「画面が真っ白です」と言われて、どこから見るか
不具合の報告が来たとき、最初に知りたいのは「ブラウザが何を送って、サーバーが何を返したか」です。ここが読めないと、直すのが自分なのか相手なのかも決められません。ブラウザとサーバーの間を流れているのは、実はただのテキストです。
送るほうは 1 行目で用件が決まる
ブラウザが送るリクエストは、用件を書いた 1 行目、付帯情報を並べたヘッダー、そして本文の 3 つでできています。
プレーンテキスト
GET /articles/network HTTP/1.1
Host: example.com
Accept: text/html1 行目の GET /articles/network が「この住所のものをください」という用件です。ヘッダーはそこに付ける但し書きで、Host はどのドメイン宛てかを示します。ページを取りに行くだけなら本文は空のままです。
返すほうも 1 行目で結果が決まる
サーバーの返事も同じ形です。1 行目に結果、続いてヘッダー、そして本文が入ります。
プレーンテキスト
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
<!DOCTYPE html>
<html>...</html>200 が結果を表す 3 桁の数字です。この数字は暗記するものではなく、桁で読みます。200 番台は成功、300 番台は場所が移ったという知らせ、400 番台は依頼した側の間違い、500 番台は受けた側の故障です。
つまり 404 が返っているなら、押しているリンクや叩いている URL のほうを疑います。500 が返っているなら、こちらの送り方は届いていて、サーバーの中で処理が転んでいます。1 桁目を見るだけで、調べる場所が半分に絞れます。
この 2 つのかたまりは、ブラウザの開発者ツールの Network パネルでそのまま読めます。手元から直接見たいときは、レスポンスのヘッダーまで表示する指定を付けて取得します。
プレーンテキスト
$ curl -i https://example.com不具合の報告を受けたら、まずここを見ます。何を送って何が返ったかが分かれば、話は「誰の担当か」から「どこを直すか」に変わります。
サーバーは前回の話を覚えていない
HTTP はリクエストを 1 つずつ独立に扱います。さっきログインした人からの 2 回目でも、サーバーは何も覚えていません。
覚えていないのに、ログイン状態が続くのはなぜか。クライアント側に保存した Cookie やトークンを、毎回のリクエストにくっつけて送り直しているからです。状態はサーバーではなく、送られてくる紙のほうに書いてあります。
裏を返すと、そこに入れたものは全部、画像 1 枚を取るリクエストにまで付いてきます。Cookie を安易に増やすと、以降のすべての通信が少しずつ重くなります。
現場の話
覚えないのは不便に見えて、実は台数を増やせる理由になっています。どのサーバーが受け取っても判断材料が全部リクエストに入っているので、前段で好きに振り分けられます。アクセスが増えたらサーバーを足すだけで捌ける設計は、この性質の上に成り立っています。
復習ミニクイズ
HTTP ステータスコード 403 の意味として正しいものはどれですか