導入 — ブラウザとサーバの HTTP の会話を読む
URL を入力してから起きること（DNS → TCP → TLS → HTTP）の中での HTTP の位置を確認し、リクエストとレスポンスの生テキストの骨格、そしてステートレスの意味をつかむ。
Network タブを開いたが、どこを見ればいいのか分からない
ページが表示されない、API が期待どおり動かない — 先輩に相談すると「開発者ツールの Network タブを見て」と言われます。開いてみると、行と数字がずらりと並んでいて、どこから読めばいいのか分からない。作り始めたばかりの頃、誰もが一度は通る場面です。
実は、あの画面に映っているものの正体はとても素朴です。ブラウザとサーバは、テキストで書かれた手紙を 1 往復ずつ交わしているだけです。ブラウザが「これをください」という手紙（リクエスト）を送り、サーバが「はい、結果はこうでした」という手紙（レスポンス）を返す。この往復書簡の書式さえ知れば、Network タブも curl の出力も、同じ骨格で読めるようになります。
この講座では、どんな出力を見るときも同じ 3 点を確認します。
HTTP が始まる前に — URL 入力から起きること
ブラウザに https://example.com/ と入力して Enter を押すと、HTTP の手紙が送られる前に、いくつかの準備が積み重なります。
example.com という名前から、サーバの IP アドレスを引きます。宛先の住所が分からなければ手紙は出せませんhttp:// ならこの段は省かれ、手紙は平文のまま流れます大事なのは層の分担です。DNS は住所係、TCP は輸送係、TLS は封筒係で、HTTP は手紙の本文そのものです。HTTPS になっても手紙の書式（この講座で学ぶすべて）は変わりません — 封筒に入るかどうかが違うだけです。
リクエストとレスポンスは向きが逆なだけで、骨格は同じ「1 行目 + ヘッダ + 空行 + ボディ」です。1 行目だけが役割によって形を変えます — 頼む側はリクエスト行、答える側はステータス行。
生のテキストを読んでみる
実際の 1 往復を、加工せずそのまま見てみます。まず、ブラウザが送るリクエストです。
GET /docs/index.html HTTP/1.1
Host: example.com
Accept: text/html
1 行目がリクエスト行です。GET（何をしたいか = メソッド）、/docs/index.html（どれに対してか = パス）、HTTP/1.1（どの版で話すか = バージョン）の 3 つを空白で区切って並べます。2 行目からは 名前: 値 の形のヘッダが続き、空行が「ここまでが頭書き」の合図になります。GET のリクエストは頼みごとだけなので、空行の後のボディは空です。
サーバからのレスポンスも、同じ骨格で返ってきます。
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256
<!DOCTYPE html>
<html>...
1 行目はステータス行です。200 が機械向けの 3 桁の結果コード、OK は人間向けの補足フレーズ。続くヘッダが「HTML です・1256 バイトです」という補足を添え、空行の後に頼まれたもの（HTML 本文）がボディとして届きます。
ここが講座全体の土台です: リクエストもレスポンスも「1 行目 + ヘッダ + 空行 + ボディ」。1 行目を読めば「何を頼んだか」「結果はどうだったか」が分かり、ヘッダを読めば「条件と補足」が分かります。
小問 1-1 — URL 入力から HTTP までの道のり
HTTP が始まる前に何が起きているか、そしてリクエストの 1 行目の読み方を確認します。
Q1. ブラウザに https://example.com/ と入力してから、HTTP リクエストが送信されるまでに起きることの順序として正しいものはどれですか。
手紙を送るにはまず住所（DNS で IP アドレスを引く）、次に道（TCP 接続）、HTTPS なら封筒の封（TLS）が必要で、HTTP の会話はその上で始まります。HTTP リクエストを最初に送ることはできませんし（送り先がまだ分からない）、TLS は TCP の上に作られるので TCP より先には来ません。この講座で読むのは、この積み重ねのいちばん上の層です。
Q2. リクエストの 1 行目 GET /docs/index.html HTTP/1.1 の読み方として正しいものはどれですか。
リクエスト行は「動詞 + 目的語 + 使用言語の版」です。GET が何をしたいか（取得したい）、/docs/index.html がどれに対してか、HTTP/1.1 がどの版の HTTP で話すか。ステータスコードはレスポンス側の 1 行目に現れるもので、リクエスト行には含まれません。この 3 つ組を読めれば「何を頼んだか」は必ず分かります。
Q3. HTTP のリクエストやレスポンスで、ヘッダの終わりとボディの始まりを区切っているものはどれですか。
ヘッダを 1 行ずつ書き並べたあと、空行を 1 つ置くと「ここからはボディです」という合図になります。手紙でいえば、頭書きの後の 1 行空けと同じ役割です。END のような終端記号や特別なバイナリはありません — HTTP/1.1 のメッセージは最後までテキストの約束事で読めます。
ステートレス — サーバは「さっきの続き」を覚えていない
この往復書簡には、初学者が最初に驚く性質があります。サーバは原則として、前のリクエストのことを覚えていません。1 通目で商品ページを見て、2 通目でカートに入れても、サーバにとって 2 通目は「知らない人からの新しい手紙」です。これをステートレス（状態を持たない）と呼びます。
不便に見えますが、これは設計上の選択です。リクエストごとに完結しているから、サーバは 1 通ずつ独立に処理でき、何台にでも分担させられます。世界規模のサービスが成立するのは、この割り切りのおかげです。
では、ログイン状態のような「続きもの」はどう実現するのか。答えは毎回の手紙に名札を添えることです — サーバが発行した目印（Cookie）を、ブラウザが以後のリクエストに毎回書き添えます。仕組みは第 4 章で読みますが、「ステートレスな往復書簡の上に、添え書きで状態を作る」という構図だけ先に持っておいてください。
小問 1-2 — レスポンスの読み方とステートレス
返ってきた側の 1 行目と、HTTP の大切な性質「ステートレス」を確認します。
Q4. レスポンスの 1 行目 HTTP/1.1 200 OK に含まれる 200 と OK の説明として正しいものはどれですか。
ステータス行は「バージョン + 3 桁のステータスコード + 人間向けフレーズ」です。プログラムが判定に使うのは 200 という数字のほうで、OK は読み手への添え書きにすぎません。結果の判定はこの 3 桁で行う — これが 3 点セットの 2 つ目「結果はどうだったか」の読み方で、第 3 章で桁ごとに深掘りします。
Q5. HTTP は「ステートレス」だと言われます。この説明として正しいものはどれですか。
ステートレス（state-less）は「状態を持たない」— リクエストごとに完結し、サーバは「さっきの続き」を自動的には覚えません。だからこそ各リクエストには必要な情報を毎回添える必要があり、ログイン状態のような「続きもの」を実現するには第 4 章で扱う Cookie という添え書きの仕組みを使います。暗号化や同時接続数の話ではありません。
この章で持ち帰ること
- HTTP は DNS → TCP → TLS の準備の上で交わされる、テキストの往復書簡である
- リクエストもレスポンスも骨格は同じ「1 行目 + ヘッダ + 空行 + ボディ」。1 行目はリクエスト行（メソッド・パス・バージョン）またはステータス行（バージョン・3 桁コード・フレーズ）
- HTTP はステートレス — 各リクエストは独立した 1 通。「続きもの」は Cookie などの添え書きで作る
- 読み方はいつも 3 点セット — 何を頼んだか・結果はどうだったか・条件と補足は何か
次章では 3 点セットの 1 つ目、「何を頼んだか」を深掘りします。GET と POST はどう違うのか、そして「もう一度送っていい頼みごと」はどれなのか — メソッドの約束を読みます。