こんにちは、かつコーチです。
「ブラウザにURLを入力すると、なぜかWebページが表示される。この裏側でブラウザとサーバーはどんな会話をしているんだろう」。
そんな疑問に答えるのがHTTPです。
この記事では、HTTPの役割やリクエスト・レスポンスの構造を初心者向けに解説します。
仕組みを理解すると、ブラウザの開発者ツールに表示される情報の意味もわかるようになります。
HTTPとは？
手紙のやり取りのような共通ルール
HTTP（HyperText Transfer Protocol）とは、Webブラウザ（クライアント）とWebサーバーが情報をやり取りするための共通ルール（プロトコル）です。
イメージしやすいように、手紙のやり取りに例えてみましょう。
私たちが誰かに手紙で依頼をするとき、「宛先」「依頼の内容」を書いて送り、相手は「依頼内容を確認した結果」を返信します。
HTTPも同じように、ブラウザが「このページをください」という依頼（リクエスト）をサーバーに送り、サーバーが「はい、どうぞ」または「見つかりませんでした」といった返信（レスポンス）を返す、という往復のやり取りで成り立っています。
なぜ共通ルールが必要なのか
世の中には無数の種類のブラウザやサーバーソフトが存在します。
もしそれぞれが独自の形式で通信していたら、どのブラウザがどのサーバーと通信できるかわからず、混乱してしまいます。
HTTPという共通の手紙の書き方（フォーマット）をあらかじめ決めておくことで、どのブラウザからでも、どのサーバーに対しても、同じルールで依頼と返信をやり取りできるようになっています。
HTTPリクエストとレスポンスの構造
リクエスト：依頼状の中身
ブラウザがサーバーに送るリクエストには、主に次のような情報が含まれます。
| 要素 | 役割 | 手紙で例えると |
|---|---|---|
| メソッド | 依頼の種類（GET、POSTなど） | 「見せてほしい」「送りたい」といった依頼の種類 |
| URL | 依頼する対象 | 宛先住所 |
| ヘッダー | 依頼に関する付加情報 | 便箋の余白に書く補足事項 |
| ボディ | 送信するデータ本体（POSTなどで使用） | 手紙に同封する書類 |
レスポンス：返信の中身
サーバーからブラウザに返ってくるレスポンスには、次のような情報が含まれます。
| 要素 | 役割 | 手紙で例えると |
|---|---|---|
| ステータスコード | 依頼の処理結果を表す3桁の数字 | 「了解しました」「見つかりません」等の結果通知 |
| ヘッダー | レスポンスに関する付加情報 | 返信の便箋の補足事項 |
| ボディ | 実際のページの中身（HTMLなど） | 返信の本文 |
代表的なステータスコード
ステータスコードは、返信の結果を一目で伝えるための番号です。
| コード | 意味 |
|---|---|
| 200 | 成功（依頼どおり処理できました） |
| 301 / 302 | リダイレクト（別の宛先に転送します） |
| 404 | Not Found（依頼された内容が見つかりません） |
| 500 | サーバーエラー（サーバー側で問題が起きました） |
「404」は特に見慣れたコードだと思いますが、これは「返信するはずの相手（ページ）が引っ越して見つからなかった」という状態を表しています。
curlコマンドでHTTP通信を確認する
-vオプションでリクエストとレスポンスの中身を見る
curlコマンドに-v（verbose）オプションを付けると、実際にやり取りされているリクエストとレスポンスの中身を確認できます。
# example.comへのHTTP通信の詳細を表示する
curl -v http://example.com
実行すると、次のような出力が確認できます。
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Content-Length: 1256
>で始まる行がブラウザ（この場合はcurl）からの依頼状の中身、<で始まる行がサーバーからの返信の中身です。
1行目のGET / HTTP/1.1が「トップページをください」という依頼、HTTP/1.1 200 OKが「了解しました」という返信にあたります。
よくあるつまずきポイント・エラー対処
ステータスコードを見ずにエラー原因を見誤る
❌Before（つまずいた実例）
開発中にAPIから期待通りのデータが返らず、レスポンスのボディの中身ばかりを見て原因を探していたことがあります。
実はステータスコードが404だったのに気づかず、しばらく無駄な調査をしてしまいました。
✅After（解決方法）
curl -vやcurl -iでステータスコードを最初に確認する習慣をつけたところ、原因の切り分けが格段に早くなりました。
# レスポンスヘッダー（ステータスコード含む）だけを確認する
curl -i http://example.com/not-exist-page
# HTTP/1.1 404 Not Found
「返信の中身（本文）を読む前に、まず結果通知（ステータスコード）を確認する」という手紙の読み方の順番を意識すると、無駄な調査を減らせます。
応用・一歩先の使い方
ステートレスという性質
HTTPにはステートレスという重要な性質があります。
これは、1回1回のリクエストが独立していて、サーバーが「前回のやり取りの内容」を基本的には覚えていない、という意味です。
手紙のやり取りに例えるなら、毎回のやり取りごとに相手の記憶がリセットされ、以前の手紙の内容を覚えていない状態に近いイメージです。
そのため、ログイン状態などを維持したい場合は、Cookieやセッションといった別の仕組みで補う必要があります。
まとめ
この記事のポイント
- HTTPは、ブラウザとサーバーが情報をやり取りするための共通ルール
- 「依頼状（リクエスト）と返信（レスポンス）の往復」とイメージすると理解しやすい
- ステータスコードは返信の結果を一目で伝える3桁の数字（200・404・500など）
curl -vでリクエストとレスポンスの中身を実際に確認できる
次に読むべき記事
HTTPの基本がわかったら、次は「HTTPメソッド（GET・POST・PUT・DELETE）の使い分け」で、依頼の種類ごとの使い分けを確認してみてください。
タグ: ネットワーク, 初心者向け, HTTP