TL
ネットワーク

HTTP / HTTPS（Webの通信プロトコル）

ブラウザとサーバが会話するための“共通言語”。リクエストとレスポンスを往復し、HTTPS はそれを暗号化したもの。

基礎HTTPHTTPSWebプロトコル最終更新: 2026-06-04
TL;DR要点だけ先に
  • 1.HTTP は ブラウザ↔サーバ の会話ルール。クライアントが「リクエスト」を送り、サーバが「レスポンス」を返す。
  • 2.メソッド（GET/POST…）で“何をしたいか”、ステータスコード（200/404/500…）で“どうなったか”を表す。
  • 3.HTTPS は HTTP を TLS で暗号化したもの。盗聴・改ざん・なりすましを防ぐ、いまの標準。

リクエストとレスポンス

1回のやり取りは、ざっくりこの形です。

  • リクエスト: メソッド（GET）＋ パス（/index.html）＋ ヘッダ（付帯情報）＋ ボディ（送るデータ）
  • レスポンス: ステータスコード（200）＋ ヘッダ ＋ ボディ（HTMLやJSONなど中身）

メソッド（何をしたいか）

メソッド意味副作用
GET取得する（読み取り）なし（安全・べき等）
POST新規作成・送信あり
PUT丸ごと置き換えあり（べき等）
PATCH部分更新あり
DELETE削除あり（べき等）
べき等（idempotent）とは

「同じリクエストを何回送っても結果が同じ」性質。GET/PUT/DELETE はべき等、POST は非べき等（送るたびに増える）。リトライ設計でよく効きます。

ステータスコード（どうなったか）

先頭の数字でカテゴリが分かります。

  • 2xx 成功: 200 OK / 201 Created / 204 No Content
  • 3xx リダイレクト: 301 恒久的 / 302・307 一時的 / 304 Not Modified（キャッシュ有効）
  • 4xx クライアント側のミス: 400 不正 / 401 未認証 / 403 禁止 / 404 なし / 429 レート超過
  • 5xx サーバ側の障害: 500 内部エラー / 502 Bad Gateway / 503 利用不可
401 と 403 の違い

401 は「誰だか分からない（ログインして）」、403 は「誰だか分かるが権限がない」。認証(authn)と認可(authz)の違いに対応します。頻出のひっかけ。

ヘッダとステートレス

HTTP は ステートレス（各リクエストは独立し、前回を覚えていない）。そこで状態を持たせるために ヘッダ を使います。

  • Cookie / Set-Cookie: セッションの維持
  • Authorization: 認証トークン（Bearer ...）
  • Content-Type: ボディの種類（application/json 等）
  • Cache-Control / ETag: キャッシュ制御

HTTPS = HTTP + TLS

HTTPS は HTTP のやり取りを TLS で暗号化 したもの。これにより、

  • 盗聴防止（中身が暗号化される）
  • 改ざん検知（途中で書き換えられたら分かる）
  • なりすまし防止（証明書でサーバの正当性を確認）

いまや HTTPS が標準で、ブラウザは HTTP を「保護されていない通信」と警告します。詳しくは TLS/SSL の解説へ。

HTTP/1.1・2・3 の違い

版特徴ひとこと
HTTP/1.11接続で順番に処理（先頭詰まり=HOLブロッキング）長く使われた基本形
HTTP/2多重化で並行リクエスト、ヘッダ圧縮TCP上で高速化
HTTP/3QUIC（UDPベース）で接続確立が速いモバイル/不安定回線に強い

ハンズオン

# ヘッダ込みで取得（-i）。ステータスとヘッダが見える
curl -i https://example.com/

# ヘッダだけ確認（-I = HEAD 相当）
curl -I https://example.com/

# JSON を POST する
curl -X POST https://api.example.com/items \
  -H "Content-Type: application/json" \
  -d '{"name":"demo"}'

ネットワーク Article

HTTP / HTTPS（Webの通信プロトコル）を実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

HTTP

比較で見る軸

難易度: basic / カテゴリ: ネットワーク / タグ数: 4

導入後に効く点

メソッド（GET/POST…）で“何をしたいか”、ステータスコード（200/404/500…）で“どうなったか”を表す。

先に潰すリスク

用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。

数字・仕様の読み方
難易度
basic
カテゴリ
ネットワーク
タグ数
4

判断チェックリスト

  • 自社の用途が「HTTP / HTTPS」に近いか確認する。
  • 強みである「HTTP は ブラウザ↔サーバ の会話ルール。クライアントが「リクエスト」を送り、サーバが「レスポンス」を返す。」が本当に評価軸になるか確認する。
  • 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

HTTPHTTPSWebプロトコルHTTPHTTPSWebプロトコル
参考: 公式情報