// シス担のミカタ
プロトコル補足

HTTP（HyperText Transfer Protocol） えいちてぃーてぃーぴー

WebプロトコルHTTPSリクエスト／レスポンスステータスコードRESTTCP/IP
HTTPについて教えて

簡単に言うとこんな感じ！

ブラウザとWebサーバーが会話するときの「共通言語」だよ！「このページちょうだい」「はい、どうぞ」ってやり取りするルールがHTTPなんだ。URLの先頭に書いてある「http://」のあれだよ！

HTTPとは

HTTP（HyperText Transfer Protocol） は、WebブラウザとWebサーバーの間でデータをやり取りするための通信規約（プロトコル）です。私たちが毎日使っているWebサイトの閲覧・フォーム送信・動画再生など、ほぼすべてのWeb通信はHTTPの上に成り立っています。

HTTPは「リクエスト／レスポンス」という非常にシンプルな構造を持っています。ブラウザが「このページのデータをください（リクエスト）」とサーバーに頼み、サーバーが「はい、これがデータです（レスポンス）」と返す——この一往復を繰り返すだけです。手紙のやり取りに例えると、ブラウザが封筒（リクエスト）を送り、サーバーが返信の封筒（レスポンス）を送り返すイメージです。

なお、現在ほとんどのWebサイトでは通信を暗号化した HTTPS（HTTP over TLS）が使われており、URLバーに鍵アイコンが表示されます。HTTPは「素の通信」、HTTPSは「暗号化した通信」と覚えておきましょう。

HTTPの仕組み：リクエストとレスポンス

リクエストの構造

ブラウザがサーバーに送る「お願い文」には、以下の要素が含まれます。

要素役割例
メソッド何をしたいかGET（取得）、POST（送信）、DELETE（削除）
URL（パス）どのリソースを対象とするか/products/123
ヘッダー付加情報（ブラウザ種別・認証トークンなど）Authorization: Bearer xxx
ボディ送信データ本体（POST時など）フォームの入力値・JSONデータ

レスポンスの構造

サーバーがブラウザに返す「返信文」の構造です。

要素役割例
ステータスコード処理結果を3桁の数字で表す200 OK / 404 Not Found
ヘッダー返却データの属性情報Content-Type: text/html
ボディ実際のデータ本体HTMLファイル・画像・JSONなど

よく見るステータスコードの覚え方

「2は成功、3は転送、4はあなたのせい、5はサーバーのせい」

コード意味実務でよく見る場面
200 OK正常に処理できた通常のページ表示
301 Moved Permanently恒久的なリダイレクトドメイン移転・URL変更
400 Bad Requestリクエストの内容が不正フォームの送信ミス
401 Unauthorized認証が必要ログインが必要なページ
403 Forbiddenアクセス権限なし管理者専用ページへの侵入
404 Not Foundページが存在しないURLの打ち間違い
500 Internal Server Errorサーバー内部でエラーバグ・設定ミス
503 Service Unavailableサーバーが応答不能過負荷・メンテナンス中

主なHTTPメソッドと使われ方

操作       メソッド    例え
───────────────────────────────────────────
データ取得  GET        図書館で本を借りる（棚をいじらない）
データ登録  POST       受付に新しい書類を提出する
データ更新  PUT/PATCH  書類の内容を上書き修正する
データ削除  DELETE     書類を廃棄する

歴史と背景

  • 1989年 — ティム・バーナーズ＝リー（WWWの発明者）がHTMLとともにHTTPの概念を提唱。最初のバージョン（HTTP/0.9）は1行のリクエストでHTMLを取得するだけの超シンプルなもの
  • 1996年 — HTTP/1.0 が RFC 1945 として標準化。ヘッダーやステータスコードが導入された
  • 1997年 — HTTP/1.1 が RFC 2068 として登場。持続的接続（Keep-Alive）やバーチャルホストなど現代の基盤機能を追加。20年以上にわたり主流として使われた
  • 2000年代 — スマートフォンの普及と動的Webアプリの増加でHTTPの限界（ヘッダーの冗長さ・複数リクエストの非効率）が問題に
  • 2015年 — HTTP/2 が RFC 7540 として標準化。Googleの「SPDY」をベースに多重化・ヘッダー圧縮・サーバープッシュを実現。表示速度が大幅向上
  • 2022年 — HTTP/3 が RFC 9114 として標準化。TCP の代わりに QUIC（UDP ベース）を採用し、モバイル環境でのパケットロスに強い設計に

HTTP vs HTTPS：何が違うの？

HTTP 暗号化なし・平文通信 ブラウザ リクエスト送信 ⚠️ データが丸見え パスワードも盗聴される可能性あり Webサーバー レスポンス返却 URL例: http://example.com ポート番号: 80 HTTPS TLS暗号化あり・安全な通信 ブラウザ リクエスト送信（暗号化済み） 🔒 データは暗号化される 第三者に傍受されても解読不能 Webサーバー レスポンス返却（暗号化済み） URL例: https://example.com ポート番号: 443（TLS使用）

HTTPバージョン比較

バージョン主な特徴現在の普及状況
HTTP/1.01リクエストごとに接続を切断ほぼ使われていない
HTTP/1.1持続的接続・パイプライン古いシステムで現役
HTTP/2多重化・ヘッダー圧縮・高速現在の主流
HTTP/3QUIC（UDP）ベース・モバイルに強い普及拡大中

REST APIとの関係

システム間連携でよく聞く REST API は、HTTPのメソッド（GET / POST / PUT / DELETE）を使ってデータをやり取りする設計スタイルです。「業務システムAと外部サービスBを連携する」という案件では、ほぼ必ずHTTPを介したREST APIが使われます。発注者として「どのAPIを使うか」「認証はどうするか」を確認する場面でHTTPの知識が役立ちます。

関連する規格・RFC

規格・RFC番号内容
RFC 1945HTTP/1.0 の仕様書
RFC 2616 / 7230〜7235HTTP/1.1 の仕様書（後に分割改訂）
RFC 7540HTTP/2 の仕様書
RFC 9114HTTP/3 の仕様書
RFC 8446TLS 1.3（HTTPSで使う暗号化プロトコル）

関連用語

  • HTTPS — HTTPにTLS暗号化を組み合わせた安全版。現在はこちらが標準
  • TLS — HTTPSで通信を暗号化するプロトコル（旧称SSL）
  • REST API — HTTPメソッドを使ったシステム間連携の設計スタイル
  • URLとURI — HTTPリクエストの宛先を表す書式
  • TCP/IP — HTTPが動く土台となるネットワーク通信の基盤プロトコル
  • ステータスコード — HTTPレスポンスの処理結果を示す3桁の番号体系