プロトコル

HTTPとは?

HTTP（HyperText Transfer Protocol）は、World Wide Web上でテキスト、画像、ビデオなどのメディアを転送するための、クライアント・サーバー型のアプリケーション層プロトコルです。インターネットの基礎となるプロトコルで、Webブラウザとサーバー間の通信を実現しています。HTTPはステートレスで要求応答型の設計により、シンプルで効率的な通信を可能にします。

HTTPの読み方

エイチティーティーピー

エイチティーティーピー（H・T・T・P）

定義と基本概念

HTTPはHyperText Transfer Protocolの略で、1991年にCERN（欧州原子核研究機構）でTim Berners-Leeによって開発されました。初版のHTTP/0.9は非常にシンプルなプロトコルでしたが、その後の改善を経て、今日のWebの標準的な通信方式として広く使用されています。

HTTPの主な特徴：

  • ステートレス：各要求は独立しており、サーバーはクライアントの状態を保持しません
  • 要求応答型：クライアントからの要求に対してサーバーが応答する一方向的な通信
  • アプリケーション層プロトコル：OSI参照モデルの第7層で動作
  • テキストベース：リクエストとレスポンスがテキスト形式で送受信される（HTTP/2以降は一部バイナリ化）
  • ポート80：デフォルトではTCPのポート80を使用

歴史と進化

HTTP/0.9（1991年）

最初のバージョン。GET メソッドのみをサポートし、非常にシンプルな実装でした。レスポンスヘッダが存在せず、HTMLテキストのみが返されていました。

HTTP/1.0（RFC 1945、1996年）

ヘッダの概念が導入され、複数のメディアタイプ対応やステータスコードが追加されました。メソッドもGET、POST、HEADに拡張されました。

HTTP/1.1（RFC 2616、1999年；RFC 7230-7235に更新、2014年）

パフォーマンス向上のための機能が多数追加されました：

  • Keep-Alive接続（コネクション再利用）
  • パイプライニング（複数要求の連続送信）
  • キャッシング制御機構の強化
  • Content-Encodingによる圧縮
  • キープアライブによる接続効率化

HTTP/2（RFC 7540、2015年）

バイナリフレーミングが導入され、大幅なパフォーマンス向上が実現：

  • バイナリプロトコル化
  • マルチプレックス処理（複数のリクエストを同時処理）
  • ヘッダ圧縮（HPACK）
  • サーバープッシュ機能
  • ストリーム優先度付け

HTTP/3（RFC 9114、2022年）

QUIC（ユーザーデータグラムプロトコル上のプロトコル）をベースに：

  • UDP上の実装によるレイテンシ低減
  • 0-RTT（ゼロラウンドトリップタイム）接続確立
  • Head-of-Line Blockingの排除
  • 接続マイグレーション対応

HTTPの仕組み

HTTPは単純な要求応答プロトコルです：

  1. TCP接続確立：クライアントはサーバーのポート80（またはHTTPSの443）に接続
  2. リクエスト送信：HTTPメソッドを含むリクエストラインとヘッダを送信
  3. 処理：サーバーはリクエストを処理
  4. レスポンス送信：ステータスコード、ヘッダ、ボディを含むレスポンスを返す
  5. 接続終了：HTTP/1.0では接続を閉じるか、HTTP/1.1以降はKeep-Aliveで再利用可能

HTTPメソッド

HTTPメソッドは、サーバー上のリソースに対して実行したい操作を指定します：

メソッド 説明 安全性 べき等性
GET リソースを取得 ○ ○
POST リソースを作成またはデータを送信 × ×
PUT リソース全体を更新または作成 × ○
DELETE リソースを削除 × ○
PATCH リソースを部分的に更新 × ×
HEAD GETと同じだがボディなし ○ ○
OPTIONS 利用可能なメソッドを取得 ○ ○
TRACE リクエストのエコーバック ○ ○

HTTPステータスコード

HTTPレスポンスは3桁のステータスコードで結果を示します：

  • 1xx（情報）：処理が続行中（例：100 Continue）
  • 2xx（成功）：リクエストが正常に処理されました
    • 200 OK：成功
    • 201 Created：リソース作成成功
    • 204 No Content：成功だが応答ボディなし
  • 3xx（リダイレクション）：さらなる処理が必要
    • 301 Moved Permanently：恒久的な移動
    • 302 Found：一時的な移動
    • 304 Not Modified：キャッシュコンテンツを使用
  • 4xx（クライアントエラー）：クライアント側の問題
    • 400 Bad Request：不正なリクエスト
    • 401 Unauthorized：認証が必要
    • 403 Forbidden：アクセス禁止
    • 404 Not Found：リソースが見つかりません
  • 5xx（サーバーエラー）：サーバー側の問題
    • 500 Internal Server Error：サーバー内部エラー
    • 502 Bad Gateway：不正なゲートウェイ
    • 503 Service Unavailable：サービス利用不可

HTTPリクエストの構成

GET /path/to/resource HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: ja-JP,ja;q=0.9
Connection: keep-alive

リクエストライン：メソッド、URI、HTTPバージョン
ヘッダ：要求に関するメタデータ
ボディ：POSTやPUTメソッドで送信するデータ（オプション）

HTTPレスポンスの構成

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Cache-Control: max-age=3600
Set-Cookie: session_id=abc123; Path=/
Connection: keep-alive

<!DOCTYPE html>
<html>
<head><title>Example</title></head>
<body>Example content</body>
</html>

ステータスライン：HTTPバージョン、ステータスコード、理由フレーズ
ヘッダ：レスポンスに関するメタデータ
ボディ：リソースのコンテンツ（HTMLやJSONなど）

HTTPヘッダ

重要なHTTPヘッダの例：

リクエストヘッダ：

  • Host：リクエスト先のホスト名
  • User-Agent：クライアントの種類とバージョン
  • Accept：クライアントが受け付けるメディアタイプ
  • Authorization：認証情報
  • Cookie：クライアント側で保存されたクッキー

レスポンスヘッダ：

  • Content-Type：レスポンスボディのメディアタイプ
  • Content-Length：レスポンスボディのバイト数
  • Cache-Control：キャッシュの制御
  • Set-Cookie：クライアント側で保存するクッキー
  • Location：リダイレクト先URL
  • ETag：リソースの一意識別子（キャッシュ用）

HTTPクッキーとセッション

HTTPはステートレスプロトコルですが、クッキーを使用してサーバーがクライアント情報を追跡できます：

// レスポンスヘッダ
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Strict

// 次のリクエストで自動送信
Cookie: sessionId=abc123

クッキーの属性：

  • Path：クッキーが有効なパス
  • HttpOnly：JavaScriptからのアクセス禁止
  • Secure：HTTPS接続時のみ送信
  • SameSite：CSRF攻撃対策

キャッシング機構

HTTPはキャッシング機構をサポートし、ネットワーク負荷を軽減：

// キャッシュ制御の例
Cache-Control: max-age=3600          // 1時間キャッシュ
Cache-Control: no-cache              // 検証が必要
Cache-Control: no-store              // キャッシュ禁止
Cache-Control: public                // 共有キャッシュ可能
Cache-Control: private               // プライベートキャッシュのみ

// ETagによる条件付きリクエスト
If-None-Match: "abc123"              // ETagが一致すれば304返す
Last-Modified: Wed, 21 Mar 2025 10:00:00 GMT
If-Modified-Since: Wed, 21 Mar 2025 10:00:00 GMT

HTTPとHTTPSの比較

項目 HTTP HTTPS
プロトコル HyperText Transfer Protocol HTTP + TLS/SSL
ポート 80 443
暗号化 なし あり（TLS）
認証 なし デジタル証明書
セキュリティ 低い（データ盗聴可能） 高い
パフォーマンス やや高速 やや低速
SEO 不利 有利
ブラウザ表示 鍵マークなし 鍵マークあり

HTTPSは、TLS（Transport Layer Security）プロトコルによってHTTPの通信を暗号化します。現在、セキュリティ上の理由からほぼすべてのWebサイトでHTTPSが推奨されています。

実装例

Node.js での基本的なHTTPサーバー：

const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/html; charset=UTF-8' });
  
  if (req.method === 'GET' && req.url === '/') {
    res.end('<h1>Hello, World!</h1>');
  } else if (req.method === 'POST' && req.url === '/api/data') {
    let body = '';
    req.on('data', chunk => body += chunk);
    req.on('end', () => {
      console.log('Received:', body);
      res.end(JSON.stringify({ status: 'received' }));
    });
  } else {
    res.writeHead(404);
    res.end('Not Found');
  }
});

server.listen(3000, () => console.log('Server running on port 3000'));

Python での HTTPリクエスト：

import requests

# GETリクエスト
response = requests.get('https://api.example.com/users')
print(response.status_code)  # 200
print(response.json())       # JSONボディ

# POSTリクエスト
data = {'name': 'John', 'email': 'john@example.com'}
response = requests.post('https://api.example.com/users', json=data)
print(response.status_code)

# ヘッダとクッキーを指定
headers = {'Authorization': 'Bearer token123'}
cookies = {'session': 'abc123'}
response = requests.get(
    'https://api.example.com/users',
    headers=headers,
    cookies=cookies
)

cURL でのリクエスト：

# シンプルなGETリクエスト
curl https://example.com

# POSTリクエスト
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name":"John","email":"john@example.com"}'

# ヘッダを指定
curl -H "Authorization: Bearer token123" https://api.example.com/users

# クッキーを指定
curl -b "session=abc123" https://api.example.com/users

よくある誤解

誤解1：「HTTPはセキュアである」

HTTPは暗号化されておらず、データ盗聴の対象です。機密情報はHTTPSを使用してください。

誤解2：「HTTP/2を使うと必ず高速化する」

HTTP/2はネットワークの潜在能力を引き出すプロトコルですが、アプリケーション設計やサーバー構成も重要です。TLSのオーバーヘッドも考慮が必要です。

誤解3：「ステートレスなので複数リクエストを関連付けできない」

クッキーやセッションを活用することで、HTTPでも状態を管理できます。

誤解4：「POSTは常に安全である」

POSTはGETと異なりボディでデータを送信しますが、HTTPSで暗号化されない限り盗聴可能です。

誤解5：「HTTP/3は完全にUDP置き換え」

HTTP/3はQUICをベースにしていますが、QUICはUDP上のプロトコルで、UDPの特性を改善したものです。

関連技術

  • HTTPS：HTTPの暗号化版。TLS/SSLで保護
  • HTTP/2、HTTP/3：HTTPの次世代バージョン
  • WebSocket：双方向通信プロトコル
  • REST：HTTPを活用した設計パターン
  • gRPC：HTTP/2上のRPC フレームワーク
  • CORS：クロスオリジンリソース共有
  • TLS/SSL：通信の暗号化プロトコル

よくある質問

Q：HTTPとHTTPSの違いは？

A：HTTPSはHTTPにTLS/SSLプロトコルを組み合わせて通信を暗号化したものです。HTTPは平文で送受信されるため盗聴の危険があります。

Q：なぜHTTP/3はQUICを使うのか？

A：QUICはUDP上で実装されており、TCPの制約（Head-of-Line Blocking）がなく、レイテンシが低く、接続確立が高速です。

Q：クッキーがない場合、状態をどう管理する？

A：セッショントークンをURLパラメータまたはリクエストヘッダで送信する方法があります。ただしセキュリティ上の理由からクッキー推奨です。

Q：HTTPメソッドはいくつありますか？

A：主要なメソッドは7つ（GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS）ですが、TRACE、CONNECTなど拡張メソッドもあります。

Q：2xx以外のステータスコードはエラーか？

A：2xxは成功、3xxはリダイレクト（追加処理必要）、4xxはクライアントエラー、5xxはサーバーエラーです。3xxは正常系です。

Q：Keep-Aliveは何ですか？

A：TCP接続を再利用する機能で、複数のHTTPリクエストを同じ接続で送信できます。パフォーマンス向上につながります。

Q：POSTとPUTの違いは？

A：POSTは新規リソース作成、PUTは既存リソース全体更新です。PUTはべき等で何度実行しても同じ結果ですが、POSTは異なります。

参考資料

まとめ

HTTPはWorld Wide Webの基礎となるプロトコルで、1991年の発表から現在に至るまで進化し続けています。HTTP/1.1は長年標準として使用されていましたが、HTTP/2およびHTTP/3により、より高速で効率的な通信が実現されています。HTTPはステートレス設計により単純で拡張性に優れていますが、セキュリティのためにはHTTPSの使用が必須です。RESTful APIやモダンなWebアプリケーション開発において、HTTPの仕組みを正しく理解することは重要です。

翻訳情報：この記事は英語版もあります。上部のリンクから「English」を選択してご覧ください。
🌐
Read this article in English:
What Is HTTP? →

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA


アーカイブ