HTTPリクエストの流れ
What — 1回の通信は7段階、HTTP は最後の3つだけ
URL を叩いてからレスポンスが返るまでに、7つの段階が順番に走る。HTTP の注文と返答は最後の3段階だけで、前半4段階はその注文票を相手に届けるための準備。
- URL の分解 — 宛先（ホスト）と頼むこと（パス）に分ける
- DNS 名前解決
- TCP 接続
- TLS ハンドシェイク
- HTTP リクエスト送信 — 注文票を流す（中身は HTTPリクエストの構造）
- サーバー処理
- レスポンス返却 — 返答が戻る（中身は HTTPレスポンスの構造）
How — 準備の3段階は前の結果の上に次を載せる積み重ね
住所がわかって（DNS）初めて回線をつなげ（TCP）、回線があって初めて暗号化できる（TLS）という積み重ね。暗号化された回線の中を、HTTP のテキストが流れる。
| 段階 | 一言の役割 |
|---|---|
| DNS | 名前（ドメイン）→ 住所（IP アドレス）に引き直す電話帳 |
| TCP | データが欠けず・順番どおり届く回線を張る |
| TLS | その回線を暗号化して盗聴・改ざんを防ぐ |
| HTTP | 回線の中を流れる「注文票と返答」の書式 |
Info
電話で言うと、DNS＝店名から番号を調べる、TCP＝電話をかけて相手が出る、TLS＝周りに聞かれない専用回線にする、HTTP＝注文の言葉遣い。
いつ使うか — エラーを「どの段階で死んだか」で切り分ける
7段階が頭にあると、通信エラーはエラーメッセージがどの段階の言葉かで読み分けられる。curl -v で各段階のログが上から順に見える。
| エラーの出方 | 死んだ段階 | まず疑うこと |
|---|---|---|
Could not resolve host |
DNS | ドメイン名の打ち間違い |
Connection refused / タイムアウト |
TCP | サーバーが起動していない・ポート違い |
certificate 系エラー |
TLS | 証明書切れ・http と https の取り違え |
| 4xx / 5xx が返ってくる | HTTP 以降 | リクエストの中身か、サーバー側の処理 |
Success
ステータスコードが返ってきた時点で、段階1〜4は全部成功している。4xx / 5xx は「通信の失敗」ではなく通信が成功した上での相手からの返答。
関連
- HTTPリクエストの構造 — 段階5で流れる注文票の解剖
- HTTPレスポンスの構造 — 段階7で返ってくる返答の解剖
- curl — この流れを手で起こすコマンド
- API — API まわりの地図