見出し画像

HTTPの解説

Ken @ インフラエンジニア

HTTP（HyperText Transfer Protocol）

ウェブブラウザとサーバーが通信するためのプロトコル。クライアントとサーバーの間でリクエストとレスポンスの形式でデータをやり取りする。クライアント（通常はウェブブラウザ）はサーバーにリクエストを送信し、サーバーはそのリクエストに対するレスポンスを返す。

URL（Uniform Resource Locator）

特定のリソースを指定するためのアドレス。例えば、http://example.com/index.htmlなど。

リクエストメソッド

クライアントがサーバーに対してどのような操作を要求するかを指定するための手段。

GET

GETメソッドは指定されたリソースを取得するために使用され、データの取得専用でサーバーの状態を変更しない。ウェブページの表示や画像などの静的リソースの取得に利用され、キャッシュされることが多い。安全かつ冪等なメソッドである。

POST

POSTメソッドは指定されたリソースにデータを送信するためのもので、通常はリソースの作成やデータの送信に使われる。フォームの送信やファイルのアップロード、APIのリクエストに利用され、通常キャッシュされない。サーバーの状態を変更し、非冪等である。

PUT

PUTメソッドは指定されたリソースを更新するためのもので、リソースが存在しない場合は新規に作成されることもある。データの更新やファイルの置き換えに利用され、通常キャッシュされない。サーバーの状態を変更し、冪等である。

DELETE

DELETEメソッドは指定されたリソースを削除するためのもので、データやリソースの削除に利用される。通常キャッシュされない。サーバーの状態を変更し、冪等である。

HEAD

HEADメソッドはGETリクエストと同様だが、レスポンスボディを返さない。リソースの存在確認やヘッダー情報の確認に利用され、GETリクエストと同じキャッシュポリシーが適用される。安全かつ冪等である。

OPTIONS

OPTIONSメソッドはサーバーがサポートしているHTTPメソッドや通信オプションを取得するためのもので、CORSのプリフライトリクエストに利用される。通常キャッシュされない。安全かつ冪等である。

PATCH

PATCHメソッドは部分的にリソースを更新するためのもので、PUTと異なりリソース全体を置き換えるのではなく部分的な変更を行う。部分的なデータの更新に利用され、通常キャッシュされない。サーバーの状態を変更し、非冪等である。

※冪等（べきとう、英: Idempotent）とは、計算機科学における用語で、操作を1回行っても複数回行っても同じ結果が得られる性質を指す。HTTPリクエストメソッドにおいては、同じリクエストを複数回送信してもサーバーの状態が変わらないことを意味する。


HTTPステータスコード

サーバーがクライアントからのリクエストに対して返す3桁の数値で、リクエストの結果を示す。これらのステータスコードの最初の桁は、そのカテゴリを示し、後に続く2桁の番号は具体的な状態やエラーを示す。

  • 1xx（情報）: リクエストを受け取り、処理を継続していることを示す。

    • 100 Continue: リクエストの初期部分が受け取られ、クライアントはリクエストを続けて送信できる。

    • 101 Switching Protocols: サーバーがクライアントのプロトコル変更要求を受け入れた。

  • 2xx（成功）: リクエストが正常に受け取られ、理解され、処理されたことを示す。

    • 200 OK: リクエストが成功し、リソースが返された。

    • 201 Created: リクエストが成功し、新しいリソースが作成された。

    • 204 No Content: リクエストが成功したが、返すコンテンツがない。

  • 3xx（リダイレクション）: リクエストは別のリソースにリダイレクトされる必要があることを示す。

    • 301 Moved Permanently: リクエストされたリソースが恒久的に新しいURLに移動した。

    • 302 Found: 一時的に別のURLにリソースがある。

    • 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: サーバーが一時的に過負荷またはメンテナンス中で利用できない。

まとめ

1xxのステータスコードは情報を表しており、リクエストを受け取って処理が進行中であることを示している。
2xxのステータスコードは成功を意味しており、リクエストが正常に受け取られ、理解され、処理されたことを示している。
3xxのステータスコードはリダイレクトを示しており、リクエストされたリソースが別の場所に移動しているため、クライアントが新しい場所にリクエストを送る必要があることを示している。
4xxのステータスコードはクライアントエラーを表しており、リクエストに問題があり、サーバーがそれを処理できないことを示している。
5xxのステータスコードはサーバーエラーを示しており、サーバー内部で問題が発生し、リクエストの処理に失敗したことを意味する。
このように、HTTPステータスコードの最初の数字を見るだけで、リクエストがどういう状態にあるのかを大まかに理解することができる。


HTTPヘッダー

リクエストやレスポンスに関する追加情報を提供するためのメタデータである。ヘッダーは「名前: 値」の形式で表され、リクエストやレスポンスの先頭部分に位置する。

General Headers（一般ヘッダー）

一般ヘッダーは、リクエストとレスポンスの両方で使用され、メッセージの全体的な属性に関する情報を提供する。これらのヘッダーは、エンティティ本体には関係せず、メッセージ全体の制御に関連する。

  • Cache-Control: キャッシュの指示を設定する。例：Cache-Control: no-cache（キャッシュを使用せず、毎回サーバーから取得）

  • Connection: 接続の管理を制御する。例：Connection: keep-alive（接続を維持する）

  • Date: メッセージが送信された日時を示す。例：Date: Tue, 15 Nov 1994 08:12:31 GMT

Request Headers（リクエストヘッダー）

リクエストヘッダーは、クライアントからサーバーへのリクエストに関する情報を提供する。これらのヘッダーは、クライアントがサーバーに対して何を望んでいるか、またはクライアント自体の情報を伝える。

  • Accept: クライアントが受け入れることができるメディアタイプを指定する。例：Accept: text/html（HTML文書を受け入れる）

  • Host: リクエストが送信されるサーバーのホスト名を指定する。例：Host: www.example.com

  • User-Agent: リクエストを送信しているクライアントのソフトウェア情報を示す。例：User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Response Headers（レスポンスヘッダー）

レスポンスヘッダーは、サーバーからクライアントへのレスポンスに関する情報を提供する。これらのヘッダーは、サーバーやリソースに関する情報、認証の要求などを伝える。

  • Server: レスポンスを生成したサーバーのソフトウェア情報を示す。例：Server: Apache/2.4.1 (Unix)

  • Set-Cookie: クライアントに設定するクッキーを送信する。例：Set-Cookie: sessionId=abc123; Path=/; HttpOnly

  • WWW-Authenticate: クライアントに認証を要求する。例：WWW-Authenticate: Basic realm="Access to the site"

Entity Headers（エンティティヘッダー）

エンティティヘッダーは、リクエストやレスポンスのボディに関する情報を提供する。これらのヘッダーは、コンテンツの長さ、タイプ、エンコード方法などを示す。

  • Content-Length: ボディのバイト数を示す。例：Content-Length: 348

  • Content-Type: ボディのメディアタイプを示す。例：Content-Type: text/html

  • Content-Encoding: ボディのエンコーディング方法を示す。例：Content-Encoding: gzip


HTTPヘッダーの例

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cache-Control: no-cache
Connection: keep-alive
Date: Tue, 15 Nov 1994 08:12:31 GMT
Upgrade-Insecure-Requests: 1

  • Host: リクエストが送信されるサーバーのホスト名を指定する。例：Host: www.example.com

  • User-Agent: リクエストを送信しているクライアントのソフトウェア情報を示す。例：User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36

  • Accept: クライアントが受け入れることができるメディアタイプを指定する。例：Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

  • Accept-Language: クライアントが優先する言語を指定する。例：Accept-Language: en-US,en;q=0.5

  • Accept-Encoding: クライアントが受け入れることができるエンコーディング方法を指定する。例：Accept-Encoding: gzip, deflate, br

  • Cache-Control: キャッシュの指示を設定する。例：Cache-Control: no-cache（キャッシュを使用せず、毎回サーバーから取得）

  • Connection: 接続の管理を制御する。例：Connection: keep-alive（接続を維持する）

  • Date: メッセージが送信された日時を示す。例：Date: Tue, 15 Nov 1994 08:12:31 GMT

  • Upgrade-Insecure-Requests: クライアントがセキュアな接続を求めることを示す。例：Upgrade-Insecure-Requests: 1


HTTPボディ

HTTPリクエストやレスポンスにおいて実際のデータやコンテンツを含む部分。リクエストやレスポンスのヘッダーで指定された形式やエンコーディングに従って、さまざまなデータが含まれる。

リクエストボディとレスポンスボディがあり、それぞれに使用されるデータ形式が異なる。リクエストボディはフォームデータ、マルチパートデータ、JSONデータ、XMLデータなどがあり、レスポンスボディはHTMLコンテンツ、JSONデータ、画像データ、XMLデータなどがある。

<!-- XMLデータの例（リクエストボディ） -->
<person>
  <name>John</name>
  <age>30</age>
</person>

<!-- XMLデータの例（レスポンスボディ） -->
<response>
  <status>success</status>
  <data>
    <id>123</id>
    <name>John</name>
  </data>
</response>

# マルチパートデータの例
Content-Type: multipart/form-data; boundary=---123456
--123456
Content-Disposition: form-data; name="file"; filename="example.png"
Content-Type: image/png

(binary data)
--123456--


HTTPのバージョン

クライアント（例：ウェブブラウザ）とサーバー間でデータを送受信するためのプロトコル。

HTTP/1.0

  • 概要: HTTP/0.9の拡張版で、GET以外のメソッド（POST、HEAD）やヘッダーの概念を導入。

  • 特徴: 各リクエストごとに新しいTCP接続を開くため、効率が悪い。

HTTP/1.1

  • 概要: HTTP/1.0の改善版で、持続的接続（Keep-Alive）、チャンク転送コーディング、追加のリクエストメソッド（PUT、DELETE）などが導入された。

  • 特徴: 持続的接続により、複数のリクエストを同じTCP接続で行うことができ、効率が向上。

HTTP/2

  • 概要: HTTP/1.1のパフォーマンスをさらに向上させるために設計された。バイナリプロトコルに変更され、データの多重化、ヘッダー圧縮、サーバープッシュなどの機能が追加された。

  • 特徴: 同時に複数のリクエストを一つのTCP接続で処理できるため、ウェブページの読み込みが高速化。

HTTP/3

  • 概要: QUICプロトコルを基盤とした最新バージョン。TCPの代わりにUDPを使用し、接続の確立が迅速で、パケットの再送や順序の制御をより効率的に行う。

  • 特徴: 接続確立の迅速さと低遅延により、通信の遅延が大幅に減少。

HTTP/1.1は依然として多くのウェブサイトやサービスで使用されており、幅広い互換性がある。
だが、現在の主流はHTTP/2である。HTTP/2は、HTTP/1.1よりも効率が良く、多くのモダンブラウザとサーバーがサポートしているため、広く採用されている。このプロトコルはデータの多重化とヘッダー圧縮を利用して、ウェブページの読み込み速度を向上させる特徴がある。

一方、HTTP/3は新しいプロトコルで、普及が進んでいる段階にある。HTTP/3は接続確立の迅速さと低遅延の利点があり、将来的には主流になると期待されている。

現在、HTTP/2が主流となっている理由は、まず第一にパフォーマンスの向上である。データの多重化により、同時に複数のリクエストを一つのTCP接続で処理できるため、ページの読み込み速度が向上する。第二に、ヘッダー圧縮によってヘッダーのデータ量が減り、通信の効率が高まる。最後に、ほとんどのモダンブラウザと多くのウェブサーバーがHTTP/2をサポートしているため、移行が容易であることが挙げられる。これらの理由から、現在のウェブトラフィックの大部分がHTTP/2を利用している。


HTTPS（HyperText Transfer Protocol Secure）

HTTPにSSL/TLSによる暗号化を加えたプロトコルで、データの送受信を暗号化することで通信の機密性とデータの整合性を保つ。これにより、通信内容が暗号化されているため、第三者による盗聴や改ざんを防止できる。また、SSL/TLS証明書を使用してサーバーの正当性を確認することが可能であるため、セキュアな通信が行われる。このため、パスワードやクレジットカード情報などの機密データの送信に適している。

関係性

  • 基本プロトコルは同じ: HTTPSはHTTPのセキュアバージョンであり、基本的なプロトコルはHTTPと同じ。ただし、通信内容を暗号化するためのSSL/TLSが追加されている。

  • ポート番号: HTTPは通常ポート80を使用し、HTTPSはポート443を使用する。

  • セキュリティ: HTTPは平文でデータを送信するため、セキュリティリスクが高い。対して、HTTPSはデータを暗号化するため、通信の機密性とデータの整合性が確保される。

  • 使用例: HTTPはセキュリティが求められない一般的なウェブページで使用されることが多かったが、近年はほとんどのウェブサイトがセキュリティのためにHTTPSを使用している。特に、ログインページや支払い情報を扱うページではHTTPSが必須となっている。


HTTPSの暗号化による通信速度の違い

HTTPは暗号化を行わないため、リクエストとレスポンスが直接送信される。これに対し、HTTPSは通信の前に暗号化プロセスが追加されるため、若干のオーバーヘッドが発生する。このオーバーヘッドには、SSL/TLSハンドシェイク（認証と暗号化の設定）が含まれる。

  1. SSL/TLSハンドシェイク： 初回接続時に行われるこのプロセスでは、公開鍵暗号方式を用いてセッション鍵を交換する。これにより、暗号化通信の準備が整い、若干の遅延が生じる。

  2. データ暗号化と復号化： データが送信されるたびに暗号化と復号化が行われるため、CPU使用率が若干増加し、わずかな遅延が発生する。

実際の影響

多くの場合、HTTPSによる遅延はユーザーが感じるほどのものではない。現代のコンピュータとネットワークの性能向上により、暗号化と復号化に要する時間は非常に短くなっている。例えば、ある調査によると、HTTPSの追加オーバーヘッドは数ミリ秒程度であり、多くのウェブサイトで実質的なパフォーマンスへの影響はほとんど感じられない。

大容量データ転送での影響

大容量データ転送においては、HTTPSのオーバーヘッドがより顕著に現れることがある。特に、数百メガバイトから数ギガバイトのデータを転送する場合、暗号化と復号化のオーバーヘッドが積み重なり、転送時間が長くなることがある。しかし、この遅延は一般的に数秒から数十秒程度であり、非常に大規模なデータ転送を行う場合でも、大きな問題になることは少ない。












よろしければサポートお願いします！よりいい情報を発信します。