HTTP プロトコルの謎を解く: インターネットの背後にあるパスワードを調査し、データ送信の謎を探ります

HTTP (Hypertext Transfer Protocol: ハイパーテキスト転送プロトコル) は、Web 上でデータを送信するためのプロトコルであり、インターネット上で最も重要なアプリケーション層プロトコルの 1 つです。HTTP はその誕生以来、常に世界をつなぐ通信の架け橋としての役割を果たし、インターネットの発展と普及に重要な役割を果たしてきました。この記事では、HTTP プロトコルの起源、仕組み、共通の機能、現代の Web への影響について詳しく説明します。

1. 起源と発展

HTTP プロトコルは、World Wide Web 上のドキュメントを接続するための通信プロトコルとして、1989 年に Tim Berners-Lee によって初めて作成されました。元々、HTTP の目的は、クライアントとサーバー間でハイパーテキストドキュメント (HTML) とハイパーリンク (Hyperlink) を送信することでした。インターネットの活発な発展に伴い、HTTP も常に進化し、改善されています。

1991 年に HTTP の最初の正式バージョンである HTTP/0.9 が登場しましたが、その機能は非常に単純で、プレーンテキストの HTML ドキュメントのみを送信できます。その後 1996 年に HTTP/1.0 がリリースされ、画像、スタイルシート、スクリプトファイルなどの複数の形式でのリソースの送信をサポートする機能が追加されました。しかし、Web アプリケーションとインターネットの継続的な拡大に伴い、HTTP/1.0 のパフォーマンスがボトルネックになっています。HTTP/1.0 のパフォーマンスの問題を解決するために、HTTP/1.1 が 1997 年にリリースされました。HTTP/1.1 では、永続接続、パイプライン要求、ホストヘッダーフィールドなどの機能が導入され、Web ページの読み込み速度とユーザーエクスペリエンスが大幅に向上しました。

現在、HTTP プロトコルは発展を続けており、最新バージョンは HTTP/2 (2015 年リリース) と HTTP/3 (2022 年リリース) で、パフォーマンス、セキュリティ、並列処理機能がさらに最適化され、徐々に主流の HTTP プロトコルになりつつあります。 . バージョン。

2. 動作原理

HTTP はステートレスプロトコルであり、各リクエストは独立しており、サーバーは以前のリクエストに関連する状態情報を保持しません。HTTP はクライアント/サーバーモデルを使用し、クライアントがリクエストを送信し、サーバーがリクエストを処理して応答を返します。

HTTP 通信プロセスは次の手順に従います。

接続の確立: クライアント (通常は Web ブラウザ) はサーバーへの TCP 接続を開始し、双方向通信チャネルを確立します。
リクエストの送信: クライアントはサーバーに HTTP リクエストを送信します。リクエストには、リクエスト行 (リクエストメソッド、URL、HTTP バージョン)、リクエストヘッダー、およびリクエスト本文 (POST などのコンテンツを含むリクエストの場合) が含まれます。
リクエストの処理: サーバーはリクエストを受信して解析し、リクエストの内容に従って対応する操作を実行します。これには、データベースの読み取り、ビジネスロジックの処理などが含まれる場合があります。
応答の送信: サーバーは処理結果を HTTP 応答としてカプセル化し、応答には応答行 (ステータスコード、ステータステキスト、HTTP バージョン)、応答ヘッダー、および応答本文が含まれます。
接続を閉じる: サーバーが応答を送信した後、TCP 接続を閉じると、要求と応答のプロセスが完了します。

3. 特徴と影響

HTTP プロトコルには次のような特徴があり、最新の Web アプリケーションとインターネットに大きな影響を与えています。

コネクションレスおよびステートレス: HTTP はコネクションレスであり、各リクエストと応答は独立しています。また、ステートレスであり、サーバーはクライアントの状態情報を保存せず、各リクエストは無関係であるため、スケーラビリティと柔軟性に役立ちます。
柔軟性: HTTP の柔軟性により、テキスト、画像、ビデオなどのさまざまなタイプのリソースを送信できるため、Web アプリケーションがリッチで多様なコンテンツを表示できるようになります。
要求-応答モデルに基づく: HTTP の要求-応答モデルを使用すると、クライアントはサーバーにデータまたは操作を要求し、サーバーの応答を取得できます。このモデルは、クライアントとサーバー間の対話と通信を容易にします。
階層化アーキテクチャ: HTTP の階層化アーキテクチャにより、プロキシサーバーとキャッシュを介したネットワーク送信が最適化され、パフォーマンスと応答速度が向上します。
ステータスコード: HTTP のステータスコードは、200 は成功を意味し、404 は見つからないことを意味し、500 はサーバーエラーを意味するなど、リクエストの処理結果の説明を提供します。これらのステータスコードは、Web アプリケーションの診断とデバッグに役立ちます。

4. 契約の構成

HTTP プロトコルは仕様であり、そのサンプルは通常、リクエストとレスポンスの形式で表示されます。以下は HTTP プロトコルのサンプルで、HTTP リクエストと HTTP レスポンスの形式をそれぞれ示しています。

HTTP リクエストのサンプル:

GET /hanko HTTP/1.1
Host: www.hanko.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.5
Connection: keep-alive

最初の行はリクエスト行で、リクエストメソッド (GET)、リクエストされたリソースパス (/hanko)、HTTP プロトコルバージョン (HTTP/1.1) が含まれます。
次にリクエストヘッダーです。これには、Host (リクエストされたターゲットホスト)、User-Agent (クライアントブラウザ情報)、Accept (クライアントによって受け入れられた応答コンテンツタイプ) など、リクエストに関する追加情報が含まれています。

Ali は当時インタビューし、http ヘッダー接続がキープアライブであるとはどういう意味ですか? と尋ねました。
HTTP 要求ヘッダーの Connection フィールドがキープアライブに設定されている場合、クライアントがサーバーとの永続的な接続を確立したいことを示します。永続的な接続を使用すると、要求ごとに新しい TCP 接続を確立するのではなく、複数の HTTP 要求と応答を同じ TCP 接続で送信できるため、接続の確立と終了のオーバーヘッドが削減され、パフォーマンスと効率が向上します。
キープアライブに加えて、HTTP リクエストヘッダーの Connection フィールドには、次の目的で他の値を含めることもできます。

close: Connection が close に設定されている場合、クライアントまたはサーバーが現在の要求と応答を送信した後に TCP 接続を閉じる必要があることを意味します。つまり、永続的な接続は使用されません。
アップグレード: HTTP アップグレードに使用されます。[接続] が [アップグレード] に設定されている場合は、クライアントが WebSocket などの他のプロトコルにアップグレードすることを望んでいることを意味します。
接続トークン: 追加情報を渡したり、特定の処理方法を指定したりするために使用できるカスタム接続トークン。

「キープアライブ」という名前が付いていますが、HTTP の永続接続 (キープアライブ) は実際には常時接続ではありません。実際、HTTP の永続接続は、単一の TCP 接続で複数の HTTP 要求と応答を送信できるメカニズムであり、これにより、要求ごとに新しい TCP 接続を再確立する必要がなくなり、接続の確立と終了のオーバーヘッドが削減されます。

HTTP 応答のサンプル:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
Server: Apache/2.4.41 (Ubuntu)
Date: Wed, 20 Jul 2023 12:34:56 GMT

<!DOCTYPE html>
<html>
<head>
    <title>Example Page</title>
</head>
<body>
    <h1>Hello, World!</h1>
    <p>This is an example page.</p>
</body>
</html>

最初の行は応答行で、HTTP プロトコルのバージョン (HTTP/1.1)、ステータスコード (200)、およびステータステキスト (OK) が含まれます。
次に応答ヘッダーです。これには、Content-Type (応答コンテンツタイプ)、Content-Length (応答コンテンツの長さ)、Server (サーバー情報) など、応答に関する追加情報が含まれます。
応答ヘッダーと応答本文の間には、応答ヘッダーの終わりを示す空行があり、その後に実際にクライアントに返されるコンテンツである応答本文が続きます。この例では、応答本文は単純な HTML ページです。

1. リクエストヘッダー

一般的なリクエストヘッダー:

ホスト: リクエストのターゲットのホスト名とポート番号を指定します。
User-Agent: リクエストを送信するユーザーエージェント (通常はブラウザ ID) を指定します。
受け入れる: クライアントが受け入れることができる応答コンテンツタイプ (テキスト、画像、JSON など) を指定します。
Accept-Language: 国際化のためにクライアントが受け入れられる自然言語を指定します。
認可: 認証情報を含む身元確認に使用されます。
Cookie: クライアントとサーバー間でセッション情報を渡すために使用されます。

2. レスポンスヘッダー

一般的な応答ヘッダー:

Content-Type: text/html、application/json など、応答コンテンツのタイプを指定します。
Content-Length: 応答コンテンツの長さをバイト単位で指定します。
場所: リダイレクトの場合、新しい URL アドレスを指定します。
Set-Cookie: セッション状態を維持するためにクライアント側で Cookie を設定するために使用されます。
キャッシュ制御: キャッシュなし、最大保存期間など、応答のキャッシュポリシーを指定します。

3. ステータスコード

HTTPステータスコードとは、HTTPプロトコルにおいて、リクエストに対するサーバーの処理結果を示す数値コードです。ステータスコードは3桁の数字で構成されており、ステータスコードごとに異なる処理結果を表します。HTTP ステータスコードは主に 5 つのカテゴリに分類され、それぞれ異なる番号で始まり、ステータスコードの種類ごとに特定の意味があります。一般的な HTTP ステータスコードとその意味は次のとおりです。

1xx (情報): リクエストが受信され、処理が継続されていることを示します。

100 続行: サーバーはリクエストのヘッダーを受信しました。クライアントはリクエストの残りの送信を続行する必要があります。

2xx (成功): リクエストがサーバーによって正常に受信され、理解され、処理されたことを示します。

200 OK: リクエストは成功し、サーバーはリクエストを正常に処理しました。
201 Created: リクエストは成功し、サーバー上に新しいリソースが作成されました。
204 コンテンツなし: リクエストは成功しましたが、応答には、成功した DELETE リクエストなどに使用されるエンティティ本文のコンテンツが含まれていません。

3xx (リダイレクト): リクエストを完了するにはさらにアクションが必要であることを示します。

301 Moved Permanently: 要求されたリソースは新しい URL に永久に移動されたため、クライアントは新しい URL を使用して再要求する必要があります。
302 Found: 要求されたリソースは一時的に新しい URL に移動されたため、クライアントは元の URL を引き続き使用する必要があります。
304 Not Modified: 条件を通じてクライアントによって要求されたリソースは変更されていないため、キャッシュされたバージョンを直接使用できます。

4xx (クライアントエラー): クライアント側でエラーが発生し、リクエストを完了できなかったことを示します。

400 Bad Request: リクエストが間違っているため、サーバーはリクエストを理解できません。
401 Unauthorized: リクエストには認証が必要であり、クライアントは有効な認証情報を提供する必要があります。
403 禁止: サーバーはリクエストを理解しましたが、実行を拒否しました。
404 Not Found: 要求されたリソースが存在せず、サーバーは要求された URL を見つけられませんでした。

5xx (サーバーエラー): サーバーでエラーが発生し、リクエストを完了できなかったことを示します。

500 内部サーバーエラー: サーバーに内部エラーが発生したため、リクエストを完了できません。
502 Bad Gateway: ゲートウェイまたはプロキシとして機能するサーバーが、上流サーバーから無効な応答を受け取りました。
503 サービスを利用できません: 通常、過負荷またはメンテナンスが原因で、サーバーが一時的に利用できません。

4. リクエスト方法

GET: 指定されたリソースの取得を要求するために使用されます。
POST: フォームデータの送信など、サーバーにデータを送信するために使用されます。
PUT: 指定されたリソースのコンテンツを更新するために使用されます。
DELETE: 指定されたリソースを削除するために使用されます。
HEAD: GET リクエストに似ていますが、応答ヘッダー情報のみを取得し、応答本文は取得しません。
OPTIONS: ターゲットリソースのサポートを取得するために使用される通信オプション。
PATCH: リソースのローカル更新を実行するために使用されます。

5.HTTPバージョン

HTTP (Hypertext Transfer Protocol) プロトコルはいくつかのバージョンの進化と改良を経て、現在主に次のメジャーバージョンがあります。

HTTP/0.9: 1991 年にリリースされた HTTP の最初のバージョン。これは、HTML テキストの送信のみをサポートする非常に単純なプロトコルであり、要求ヘッダーと応答ヘッダー、およびステータスコードはサポートしません。主にハイパーテキストドキュメント (HTML) とハイパーリンク (Hyperlink) を送信するために使用されます。
HTTP/1.0: 1996 年にリリースされました。HTTP/0.9 と比較して、HTTP/1.0 ではリクエストヘッダーとレスポンスヘッダーの概念が導入され、画像、スタイルシート、スクリプトファイルなどのさまざまな種類のリソースの送信が可能になりました。HTTP/1.0 の特徴は、リクエストごとに個別に接続を確立する必要があるため、効率が低いことです。
HTTP/1.1: 1997 年にリリースされた、HTTP プロトコルの重要なバージョンです。HTTP/1.1 では、永続的な接続、パイプライン化されたリクエスト、Host ヘッダーフィールドなどの機能が導入され、Web ページの読み込み速度とユーザーエクスペリエンスが大幅に向上しました。永続的な接続では、複数の要求と応答を同じ接続で送信できるため、要求ごとに接続を再確立するオーバーヘッドが回避されます。
HTTP/2: 2015 年にリリースされた、HTTP プロトコルの最新メジャーバージョンです。HTTP/2 は、パフォーマンス、セキュリティ、並列処理機能をさらに最適化します。これにより、複数のリクエストとレスポンスを同じ接続上で同時に送信できるバイナリプロトコルが導入され、リクエストのブロックの問題が解消されます。HTTP/2 はヘッダー圧縮やサーバープッシュなどの機能もサポートしており、データ送信のオーバーヘッドをさらに削減します。
HTTP/3: 2022 年 6 月 6 日に RFC9114 として標準化された最新バージョン。TCP の使用を放棄し、UDP 上の QUIC を使用してアプリケーション層データを伝送します。

6、クッキー

HTTP Cookie (略して Cookie) は、クライアント (通常は Web ブラウザ) とサーバーの間でセッション情報と状態データを転送するために使用される HTTP プロトコルのメカニズムです。Cookie は主に、サーバーがユーザーを識別したり、後続のリクエストでユーザーのセッション状態を維持したりできるように、ユーザーの何らかの状態情報を記録するために使用されます。

動作原理:

1. サーバーは Cookie を設定します。サーバーは HTTP 応答の Set-Cookie ヘッダーに Cookie 情報を設定し、Cookie をクライアントに送信します。例えば：

Set-Cookie: session_id=1234567890; path=/; domain=example.com; expires=Sun, 20-Jul-2025 12:00:00 GMT; secure; HttpOnly

2. クライアントは Cookie を保存します。クライアント (Web ブラウザ) は、サーバーによって設定された Cookie を受信した後、その Cookie をローカルに保存します。後続のリクエストでは、クライアントはリクエストヘッダーの Cookie フィールドに Cookie 情報を入れます。

3. クライアントは Cookie を送信します。クライアントは HTTP リクエストを送信するときに、保存されている Cookie 情報をリクエストヘッダーの Cookie フィールドに含めてサーバーに送信します。

4. サーバーは Cookie を読み取ります。サーバーはリクエストを受信すると、クライアントによって送信された Cookie 情報をリクエストヘッダーの Cookie フィールドから読み取り、そのデータに従ってユーザーを識別したり、セッション状態を維持したりできます。

クッキーのプロパティ:

Cookie には、その動作と有効期限を指定する複数の属性を含めることができます。一般的な Cookie 属性には次のものがあります。

名前と値: Cookie の名前と対応する値を示します。
ドメイン: Cookie の範囲を指定し、Cookie にアクセスできるドメイン名を指定します。
パス: Cookie のロールパスを指定し、Cookie にアクセスできる URL パスを指定します。
Expires と Max-Age: Cookie の有効期間を指定します。Expires は特定の有効期限を指定し、Max-Age は現在時刻からの秒数を指定します。
安全: Cookie のセキュリティを確保するために使用される HTTPS 接続を通じてのみ Cookie を送信できることを示します。
HttpOnly: Cookie が HTTP または HTTPS の送信に限定されており、XSS 攻撃を防ぐために使用される JavaScript などのスクリプトからはアクセスできないことを示します。

使用：

Cookie は Web アプリケーションでさまざまな目的に使用されます。一般的なものには次のようなものがあります。

ユーザーのログイン状態を記録し、ユーザー認証とセッション管理を実現します。
ユーザーの個人設定と基本設定を保存します。
ユーザーの閲覧行動を追跡してユーザー行動を分析し、関連するコンテンツを推奨します。
ショッピングサイトにおいて、ショッピングカートの情報や取引状況を保存するために使用されます。

7. URLの長さ

URL の長さの制限は、HTTP プロトコルではなくブラウザによって設定されます。以下は、http の URL の長さに関するブラウザーの制限です。

もちろん開発をやっていると皆さん言われると思いますが、ブラウザの長さ制限は必要ないのでしょうか？たとえば、apache-httpclient で httpclient を試してみましたが、これにも長さ制限があり、長すぎると 400 エラーが返されます。

記事が役に立った場合は、ぜひ注目して「いいね！」してください。閉じるには戻ってください。