ブラウザに URL を打つと、ページが出る。当たり前すぎて、その間に何があるかを考えたことがないかもしれません。ところが AWS を触りはじめると、「ロードバランサーで HTTPS を受ける」「証明書を発行する」「ヘルスチェックは 200 を期待する」「404 が返る」と、あの当たり前の中身を知っている前提の言葉が並びます。この記事は、URL を打ってから表示までを6つの段階に分け、HTTP を「頼み方の書式」、HTTPS を「封をした版」として説明します。
この記事の結論
- ブラウザが1ページを開くまでには、名前を引く（DNS）→ 相手とつなぐ（TCP）→ 封をする（TLS）→ 頼む（HTTP）→ 返ってくる → 描く、の6つの段階があります。
- HTTP は「頼み方の書式」です。何を（パス）どうしたいか（メソッド）を送ると、状態コード（200・404・500 など）つきの返事が返ります。
- HTTPS は HTTP をそのまま封筒に入れて封をしたもので、封の仕組みが TLS です。途中で読まれない・書き換えられない・相手が本物である、の3つを守ります。
- 証明書はサーバーの身分証で、認証局が署名しています。ブラウザは自分が信頼する認証局の署名があるかで、相手を信じるかを決めます。
- HTTP は 80 番、HTTPS は 443 番のポートで待ち受けるのが規格の既定です。クラウドでは、ロードバランサーや CloudFront が 443 番で HTTPS を受ける形がよく使われます。
URL を打ってから表示までに、何が起きているか
たとえば https://www.example.com/about を打ったとします。ブラウザは、この1行を6つの仕事に分けて順番にこなします。郵便でいえば、宛先を調べ、相手と話を通し、封筒に入れ、手紙を出し、返事を受け取り、読む、という旅です。
- 名前を引く（DNS）。
www.example.comという名前を、IP アドレスという住所に変えます。ping と DNS で分かる「つながる」の仕組みで扱った段階です。 - 相手とつなぐ（TCP）。 住所の 443 番のポートに向かって、「話していいですか」「いいですよ」「では始めます」の3往復で接続を作ります。
- 封をする（TLS）。 これから送るものを途中で読まれないように、暗号の鍵を相手と取り決めます。相手が本物かも、ここで確かめます。
- 頼む（HTTP）。 「/about をください」という頼みを、決まった書式で送ります。
- 返ってくる。 サーバーから「200 OK、これが中身です」と返事が返ります。
- 描く。 返ってきた HTML を読み、画像や CSS が要ればまた 4〜5 を繰り返して、画面に描きます。
FROM URL TO PAGE1ページが開くまでの旅
名前を引き、つなぎ、封をし、頼み、返ってきて描く
-
DNS
名前 → 住所
-
TCP
443 番につなぐ
-
TLS
封をする
-
HTTP
/about をください
-
返事
200 OK と中身
-
描く
画面に出す
なぜこんなに分かれているのか。それぞれの段階が、別々の約束事（プロトコル）として作られているからです。DNS は名前の係、TCP は届ける係、TLS は封をする係、HTTP は頼み方の係。役割が分かれているので、たとえば封の仕組みだけを新しくしても、頼み方の書式は変えずに済みます。この記事は、このうち HTTP と TLS を扱います。
CHECK 1ここまでの確認
ブラウザに URL を打ってからページが出るまでの6つの段階のうち、「名前を住所に変える」のはどれ?
答えと解説
答え: 1. DNS で名前を引く
最初の段階が DNS です。www.example.com のような名前を IP アドレス（住所）に変えてからでないと、相手とつなぐことができません。「URL を打ってから表示までに、何が起きているか」を読み直してください。
HTTP とは「頼み方の書式」
HTTP（HyperText Transfer Protocol）は、ブラウザとサーバーが「頼む」「返す」をやり取りするときの書式です。人が窓口で「これをください」と言い、係が「はい、これです」か「それはありません」と返す、その言い方を決めたものだと考えてください。現在の仕様は RFC 9110 にまとまっています。
頼み（リクエスト）に書くこと
頼みには、3つの要素があります。
| 要素 | 意味 | 例 |
|---|---|---|
| メソッド | どうしたいか | GET（ください）、POST（これを受け取って）、PUT（これで置き換えて）、DELETE（消して） |
| パス | 何を | /about、/api/users/42 |
| ヘッダー | 頼みに添える情報 | どのホスト宛か、どんな形式で返してほしいか、ログイン済みかを示す札 |
ブラウザでページを開く操作のほとんどは GET です。フォームを送ると POST になります。AWS の API も、裏側ではこの書式で動いています。
返事（レスポンス）の状態コード
返事の先頭には、3桁のステータスコードが付きます。百の位を見れば、何が起きたかの大まかな分類が分かります。
| コード | 意味 | 読み方 |
|---|---|---|
| 200 | OK | 頼みどおりに返した |
| 301 / 302 | 別の場所へ | そのものは別の URL にある。ブラウザは自動でそちらへ行く |
| 403 | 禁止 | サーバーには届いたが、見せてもらえない |
| 404 | 無い | サーバーには届いたが、そのパスのものが無い |
| 500 | サーバー側の故障 | サーバーの中で処理が壊れた |
| 503 | 一時的に使えない | サーバーが混んでいる・止まっている・後ろのサーバーが1台もいない |
4xx は「頼み方の側」の問題、5xx は「サーバーの側」の問題と覚えておくと、切り分けが速くなります。404 はサーバーが動いている証拠でもあります。届いていなければ、返事そのものが返りません。ロードバランサーのヘルスチェックが「200 が返れば元気」と判断するのも、この状態コードを見ているからです。
CHECK 2ここまでの確認
ブラウザに 404 が返ってきた。何が起きている?
答えと解説
答え: 2. サーバーには届いたが、頼んだ場所（パス）のものが無かった
4xx は「頼み方の側の問題」で、404 は「そのパスのものが無い」です。サーバーに届いていないなら返事そのものが来ませんし、サーバー側の故障は 5xx です。「HTTP とは」の返事の表を読み直してください。
HTTPS は「封筒に入れて封をした版」
HTTP の頼みと返事は、そのままだと途中の誰にでも読めます。はがきと同じで、配達の途中にいる人が中身を読めるし、書き換えることもできます。そこで、HTTP のやり取りを封筒に入れて封をしたものが HTTPS です。封の仕組みが TLS（Transport Layer Security）で、現在の版は TLS 1.3（RFC 8446）です。
POSTCARD TO SEALED LETTERはがきと封書
HTTPS は、HTTP の手紙を封筒に入れて封をしたもの
HTTP（はがき）80 番で待つ
HTTPS（封書）443 番で待つ
HTTP（はがき）: 途中の誰でも読める
HTTPS（封書）: 途中では読めない（暗号化）
HTTP（はがき）: 途中で書き換えられる
HTTPS（封書）: 書き換えられたら分かる
HTTP（はがき）: 相手が誰でも届く
HTTPS（封書）: 相手が本物か証明書で確かめる
TLS が守るものは3つです。
- 途中で読まれない（機密性）。 内容は暗号化されるので、経路の途中にいる人には意味の無い文字列に見えます。
- 書き換えられない（完全性）。 途中で1文字でも変えられると、受け取った側で分かります。
- 相手が本物（認証）。 話しかけている相手が、本当に
www.example.comの持ち主かを、証明書で確かめます。
大事なのは、封筒の中に入っている手紙は、HTTP そのものだということです。HTTPS になっても、メソッド・パス・状態コードの書式は変わりません。変わるのは、封をするかどうかと、待ち受けるポートの番号です。規格の既定では、HTTP は 80 番、HTTPS は 443 番のポートで待ち受けます。ネットワークとは何かで見た「窓口」の番号が、ここで効いてきます。
証明書は「身分証」— ブラウザはなぜ相手を信じるか
TLS の3つ目、「相手が本物か」は、暗号だけでは確かめられません。暗号は「いま話している相手としか読めない」ことは保証しますが、その相手が偽物だったら、偽物とだけ読める封筒を作っているにすぎません。そこで証明書を使います。
証明書は、サーバーの身分証です。「この鍵は www.example.com のものである」という内容に、認証局（CA）という第三者が署名しています。免許証に都道府県の公安委員会の印があるのと同じ構図です。
ブラウザが相手を信じるまでの流れは、こうなります。
- サーバーが、接続の最初に証明書を差し出す。
- ブラウザは、証明書の名前が、いま開こうとしている名前と一致するかを見る。
- ブラウザは、署名した認証局が、自分（ブラウザや OS）にあらかじめ入っている「信頼する認証局の一覧」にあるかを見る。
- 有効期限が切れていないかを見る。
- 全部通れば、鍵を取り決めて封をする。どれか1つでも通らなければ、「この接続は安全ではありません」と警告を出す。
サーバーは元気でも、証明書の期限が切れれば利用者はページを開けません。運用の事故としては、サーバーの故障より「期限切れ」の方が起きやすいくらいです。AWS では ACM（AWS Certificate Manager）が証明書の発行と更新を担い、ロードバランサーや CloudFront に置いて使います。使い方は上の段の記事に譲りますが、「証明書はどこかで誰かが管理しているもの」だと覚えておいてください。
CHECK 3ここまでの確認
HTTPS で「相手が本物か」を確かめる材料になるのはどれ?
答えと解説
答え: 2. 認証局が署名した証明書
相手が本物かどうかは、サーバーが出す証明書に、ブラウザが信頼している認証局の署名があるかで判断します。ポート番号や状態コードは、相手の身元とは関係ありません。「証明書は身分証」を読み直してください。
クラウドではどこで HTTPS を受けるか
ここまでの流れが、AWS の構成図を読むときにそのまま効きます。1台のサーバーが 443 番で HTTPS を受ける構成もありますが、よく使われるのは、利用者の頼みを最初に受ける場所を分けた形です。
- ロードバランサー（ALB）が受ける。 証明書はロードバランサーに置き、利用者との間の TLS はそこで終わります。後ろの EC2 や コンテナへは、VPC の内側で HTTP または HTTPS でつなぎ直します。ヘルスチェックが「200 が返るか」を見て、元気なサーバーにだけ頼みを回します。
- CloudFront が受ける。 世界各地の拠点で HTTPS を受け、近い場所から返します。証明書はここにも置きます。
REQUEST AND RESPONSE頼みと返事の往復
頼みは 443 番で受け、返事は状態コードつきで戻る
-
ブラウザが頼む
GET /about
-
ロードバランサーが受ける
443 番。証明書はここ
-
後ろのサーバーが処理
内側のネットワークで
-
返事が戻る
200 OK ／ 404 ／ 503
だから、セキュリティグループには「TCP の 443 番を通す」と書き、監視では「5xx の割合」を見ます。「なぜ 443 なのか」「なぜ 200 を期待するのか」は、この記事の6つの段階と状態コードの表で説明できます。VPC の内側・外側の話は VPC とは何か、TCP と UDP の違いは次の TCP と UDP の違いで扱います。
READ ALSO — 学習中向け・段1 入口
VPC とは何か｜サブネット・ルートテーブル・ゲートウェイ・セキュリティグループと NACL の関係を1枚で
まとめ
ブラウザが1ページを開くまでには、名前を引く・つなぐ・封をする・頼む・返る・描く、の6つの段階があります。HTTP は頼み方の書式で、メソッドとパスで頼み、状態コードつきで返事が返ります。HTTPS はその HTTP を封筒に入れて封をしたもので、封の仕組みが TLS、相手が本物かを示すのが証明書です。クラウドでは、ロードバランサーや CloudFront が 443 番で HTTPS を受け、その先はネットワークの内側で処理します。
参照ソース
- RFC 9110 “HTTP Semantics” — HTTP のメソッド・ヘッダー・状態コード（200・301・403・404・500・503）の意味の根拠（2022年）
- RFC 8446 “The Transport Layer Security (TLS) Protocol Version 1.3” — TLS が機密性・完全性・認証を提供すること、接続の最初に証明書を確かめることの根拠（2018年）
- HTTP の概要（MDN Web Docs） — HTTP がリクエストとレスポンスの書式であること、ブラウザがページを開くまでの流れの根拠（2026年9月時点）
- Service Name and Transport Protocol Port Number Registry（IANA） — HTTP が 80 番、HTTPS が 443 番を既定とすることの根拠（2026年9月時点）
- Application Load Balancer の HTTPS リスナーを作成する（Elastic Load Balancing ユーザーガイド） — ロードバランサーに証明書を置いて HTTPS を受け、後ろのターゲットにつなぎ直す構成の根拠（2026年9月時点）
- CloudFront で HTTPS を使用する（Amazon CloudFront 開発者ガイド） — CloudFront が利用者との間で HTTPS を受け、証明書を置けることの根拠（2026年9月時点）
