HTTPプロトコルの進化：1.0から2.0へ

HTTP（HyperText Transfer Protocol）は、インターネット上で最も広く使用されているネットワークプロトコルであり、すべてのWWWファイルはこの標準に従う必要があります。その元々の設計目標は、HTMLページを公開および受信するための方法を提供することでした。これは、WWWサーバーからローカルブラウザーにハイパーテキストを転送するために使用され、デフォルトでポート80を使用します。HTTPクライアントがリクエストを開始すると、サーバーの指定されたポート（デフォルトではポート80）へのTCP接続を確立します。

HTTPプロトコルはTCPプロトコルと競合しないことに注意することが重要です。HTTPは7層プロトコルのアプリケーション層にあり、TCPはトランスポート層の論理的な問題を解決する役割を果たします。HTTPがUDPではなくTCPを選択するのは、Webページを開くときに大量のデータを送信する必要があり、TCPプロトコルが伝送制御を提供して、データの順序正しい編成とエラー訂正を実現できるためです。さらに、HTTPプロトコルのボトルネックと最適化手法も、TCPプロトコルの特性に基づいています。たとえば、TCP接続を確立するときのスリーウェイハンドシェイクは、1.5 RTT（ラウンドトリップタイム）の遅延を引き起こします。各リクエストのハンドシェイク遅延を回避するために、アプリケーション層はさまざまな戦略を持つHTTP持続的接続スキームを採用します。また、TCPは接続の初期段階でスロースタート特性を持っているため、通常、接続の再利用のパフォーマンスは、新しい接続のパフォーマンスよりも優れています。

HTTP接続は「リクエスト-レスポンス」モードを採用しています。リクエストを行うときに最初に接続を確立する必要があるだけでなく、クライアントがサーバーにリクエストを送信した後でのみ、サーバーはデータで応答できます。インターネットの発展に伴い、HTTPプロトコルも継続的にアップグレードされ、HTTP/1.0、HTTP/1.1、HTTP/2.0などのバージョンが次々と登場し、各バージョンはパフォーマンスと機能の点で最適化および改善されています。

HTTPプロトコルバージョンの比較表

HTTP/1.0

HTTP/1.0は、通信でバージョン番号を指定するHTTPプロトコルの最初のバージョンであり、プロキシサーバーなどのシナリオで今でも広く使用されています。このバージョンでは、ブラウザーとサーバーは短期間の接続のみを維持することを規定しています。ブラウザーはリクエストごとにサーバーとのTCP接続を確立する必要があり、サーバーはリクエスト処理を完了するとすぐにTCP接続を切断します。各クライアントを追跡したり、過去のリクエストを記録したりしません。

このメカニズムは、いくつかのパフォーマンス上の欠陥につながります。多数の画像を含むWebページを例にとると、Webページファイル自体には画像データは含まれておらず、画像のURLアドレスのみを指定しています。ブラウザーがこのWebページにアクセスすると、最初にWebページファイルのリクエストを送信します。HTMLコンテンツを解析するときに、画像タグが見つかった場合は、src属性で指定されたURLに従って、画像データをダウンロードするためにサーバーに再度リクエストを送信します。つまり、多数の画像を含むWebページにアクセスするには、複数のリクエストとレスポンスが必要であり、単一のドキュメントまたは画像を送信するために毎回個別の接続を確立する必要があります。画像ファイルが小さい場合でも、頻繁に接続を確立および閉じるプロセスは時間がかかり、クライアントとサーバーの両方のパフォーマンスに深刻な影響を与えます。同様に、WebページにJavaScriptファイルやCSSファイルなどのコンテンツが含まれている場合、同様の問題が発生します。

同時に、帯域幅と遅延もネットワークリクエストに影響を与える重要な要素です。現在のネットワークインフラストラクチャでの帯域幅が大幅に向上したため、応答速度の遅延の問題がより顕著になっています。HTTP/1.0の最も批判された2つの問題は、接続を再利用できないこととヘッドオブラインブロッキングです。

これら2つの問題を理解するには、クライアントがドメイン名に従ってサーバーへの接続を確立することを明確にする必要があります。通常、PCブラウザーは、同じドメイン名のサーバーへの6〜8個の接続を同時に確立しますが、モバイルブラウザーは4〜6個に制御します。接続の数は多ければ多いほど良いというわけではなく、多すぎるとリソースのオーバーヘッドと全体的な遅延が増加します。接続を再利用できないと、各リクエストに対してスリーウェイハンドシェイクとスロースタートが発生します。スリーウェイハンドシェイクは遅延が高いシナリオで大きな影響を与え、スロースタートは大きなファイルのリクエストに大きな影響を与えます。ヘッドオブラインブロッキングは、帯域幅を十分に活用できなくなり、後続の健全なリクエストがブロックされます。

ヘッドオブラインブロッキングにより、健全なリクエストが不健全なリクエストの影響を受け、この損失はネットワーク環境の影響を受け、ランダムで監視が困難です。ヘッドオブラインブロッキングによって引き起こされる遅延を解決するために、プロトコル設計者はパイプラインメカニズムを導入しましたが、このメカニズムはHTTP/1.1にのみ適用され、厳密な使用条件があり、多くのブラウザベンダーはそれをサポートしていません。

HTTP/1.0では、リクエストヘッダーは比較的単純です。たとえば、Webページリソースを取得する場合：

GET /index.html HTTP/1.0
User - Agent: Mozilla/5.0

HTTP/1.1

HTTP/1.0の欠点を克服するために、HTTP/1.1は持続的接続をサポートしています（デフォルトモードは、パイプライン処理を備えた持続的接続です）。複数のHTTPリクエストとレスポンスを単一のTCP接続で送信できるため、接続の確立とクローズの消費と遅延を削減できます。多数の画像を含むWebページを例にとると、1つの接続で複数のリクエストとレスポンスを送信できますが、個々のWebページファイルのリクエストとレスポンスでは、独自の接続を使用する必要があります。さらに、HTTP/1.1を使用すると、クライアントは前のリクエストの結果が返されるのを待たずに次のリクエストを送信でき、サーバーはクライアントが各リクエストのレスポンスコンテンツを区別できるように、リクエストを受信した順序でレスポンス結果を返す必要があります。これにより、ダウンロードプロセス全体に必要な時間が大幅に短縮されます。

HTTP/1.1では、connectionヘッダーがリクエストヘッダーとレスポンスヘッダーに表示される場合があります。これは、クライアントとサーバーが持続的接続をどのように処理するかを示すために使用されます。デフォルトでは、クライアントとサーバーは、相手が持続的接続をサポートしていると想定します。クライアントがHTTP/1.1プロトコルを使用しているが、持続的接続を使用したくない場合は、ヘッダーでconnectionの値をcloseとして指定する必要があります。サーバーが持続的接続をサポートしたくない場合は、レスポンスでconnectionの値をcloseとして明確に設定する必要もあります。closeの値がリクエストまたはレスポンスのヘッダーに含まれているかどうかに関係なく、これは、リクエスト処理が完了すると現在のTCP接続が切断され、クライアントからの後続の新しいリクエストは新しいTCP接続を作成する必要があることを示しています。例：

# リクエストヘッダー
GET /index.html HTTP/1.1
User - Agent: Mozilla/5.0
Connection: close

# レスポンスヘッダー
HTTP/1.1 200 OK
Content - Type: text/html
Connection: close

さらに、HTTP/1.1は、より多くのリクエストヘッダーとレスポンスヘッダーを追加することにより、HTTP/1.0の機能を改善および拡張しました。

• Hostヘッダーのサポート：HTTP/1.0はHostリクエストヘッダーフィールドをサポートしていません。ブラウザーは、アクセスするサーバー上の特定のWebサイトをホストヘッダー名を介して指定できないため、同じIPアドレスとポート番号に対して複数の仮想Webサイトを構成することが制限されます。HTTP/1.1がHostリクエストヘッダーフィールドを追加すると、ブラウザーはホストヘッダー名を介してアクセスするサイトを明確に指定できるようになり、同じIPアドレスとポート番号で異なるホスト名を持つ複数の仮想Webサイトを作成できます。例：

GET /index.html HTTP/1.1
Host: example.com

• 持続的接続の制御：HTTP/1.1の持続的接続は、新しいリクエストヘッダーを介して実装されます。Connectionリクエストヘッダーの値がKeep - Aliveの場合、クライアントはこのリクエストの結果を返した後、接続を維持するようにサーバーに通知します。値がcloseの場合、結果を返した後、接続を閉じるようにサーバーに通知します。
• キャッシュと中断されたダウンロードの再開：HTTP/1.0は、ファイルの中断されたダウンロードの再開をサポートしていません。各ファイル転送は、0バイトの位置から開始されます。HTTP/1.1は新しいRANGE:bytesフィールドを追加し、RANGE:bytes=XXXXは、サーバーにファイルのXXXXバイトの位置から転送を開始するように要求することを意味し、中断されたダウンロードの再開を可能にします。例：

GET /largefile.zip HTTP/1.1
Range: bytes=1000 - 

さらに、HTTP/1.1は、キャッシュ処理、帯域幅の最適化、エラー通知の管理などについても改善されています。

• キャッシュ処理：HTTP/1.0は主にIf - Modified - SinceとExpiresをキャッシュ判断基準として使用し、HTTP/1.1はEntity tag、If - Unmodified - Since、If - Match、If - None - Matchなど、より多くのキャッシュ制御戦略を導入しました。
• 帯域幅の最適化：HTTP/1.0では帯域幅の浪費が発生し、中断されたダウンロードの再開をサポートしていません。HTTP/1.1はリクエストヘッダーにrangeヘッダーフィールドを導入し、リソースの一部のみをリクエストできるようにし、戻りコードは206（Partial Content）であり、帯域幅の使用率が向上します。
• エラー通知：HTTP/1.1は、要求されたリソースが現在の状態と競合することを示す409（Conflict）や、サーバー上のリソースが完全に削除されたことを示す410（Gone）など、24個の新しいエラーステータスレスポンスコードを追加します。

SPDY：HTTP/2.0の前身

SPDYは標準プロトコルではありません。その開発チームは、それをインターネットドラフトにすることを推進しましたが、最終的には独自の公式標準になることはできませんでした。ただし、SPDY開発チームのメンバーは、HTTP/2.0の策定プロセス全体に参加しました。HTTP/2.0の主要な機能は主にSPDYテクノロジーから派生しておりSPDYの成果は採用され、HTTP/2.0として進化されたと考えることができます。2015年9月、GoogleはSPDYのサポートを削除し、代わりにChrome 51で有効になったHTTP/2.0を採用することを発表しました。

SPDYはHTTPを置き換えるものではなく、HTTPリクエストとレスポンスがネットワーク経由で送信される方法を変更します。SPDYトランスポート層を追加するだけで、既存のサーバーサイドアプリケーションは変更を加える必要はありません。SPDYを伝送に使用する場合、HTTPリクエストは処理、マーク、簡略化、圧縮されます。

SPDYには次の新機能があります。

• 多重化：複数のリクエストストリームが単一のTCP接続を共有し、HOLブロッキングの問題を解決し、遅延を減らし、帯域幅の使用率を向上させます。
• リクエストの優先度：各リクエストに優先度を設定して、重要なリクエストが最初に応答されるようにすることができます。たとえば、ブラウザーがホームページをロードするときに、HTMLコンテンツの表示を優先し、次に静的リソースとスクリプトファイルをロードすることができます。
• ヘッダー圧縮：HTTP/1.xのヘッダーには、重複した冗長な情報が含まれていることがよくあります。SPDYは、適切な圧縮アルゴリズムを選択して、パケットのサイズと数を減らします。
• HTTPSに基づく暗号化プロトコル伝送：送信されるデータの信頼性を向上させます。
• サーバープッシュ：SPDYを使用するWebページの場合、クライアントがsytle.cssをリクエストすると、サーバーはsytle.jsをクライアントにプッシュします。クライアントが後でsytle.jsを取得すると、別のリクエストを行うことなく、キャッシュから直接取得できます。

HTTP/2.0

HTTP/2.0とSPDYの違い

• トランスポートプロトコル：HTTP/2.0はプレーンテキストHTTP伝送をサポートしていますが、SPDYはHTTPSの使用を強制しています。HTTP/2.0は非HTTPSをサポートしていますが、ChromeやFirefoxなどの主流ブラウザーは、TLSに基づいてデプロイされたHTTP/2.0プロトコルのみをサポートしています。したがって、HTTP/2.0にアップグレードするには、通常、最初にHTTPSをアップグレードする必要があります。
• メッセージヘッダー圧縮アルゴリズム：HTTP/2.0はHPACKアルゴリズムを使用してメッセージヘッダーを圧縮しますが、SPDYはDEFLATEアルゴリズムを使用します。

HTTP/1.xと比較したHTTP/2.0の新機能

• 多重化：HTTP/2.0では、複数のリクエスト-レスポンスメッセージを単一のHTTP/2接続を介して同時に開始できます。HTTP/1.1プロトコルでは、ブラウザークライアントは同じドメイン名の下にあるリクエストの数に制限があり、制限を超えるリクエストはブロックされます。これは、一部のWebサイトが複数の静的リソースCDNドメイン名を使用する理由の1つです。HTTP/2.0の多重化を使用すると、単一の接続でメッセージを並行して交換でき、HTTPプロトコル通信の基本単位をフレームに減らし、これらのフレームは論理ストリームのメッセージに対応し、複数のTCP接続に依存せずに複数のストリームの並列処理を実現します。たとえば、複数のリソースを同時にリクエストする場合：

:method: GET
:scheme: https
:authority: example.com
:path: /image1.jpg

:method: GET
:scheme: https
:authority: example.com
:path: /image2.jpg

HTTP/1.1の持続的接続の再利用と比較して、HTTP/1.*では、各リクエスト-レスポンスに対して接続が確立され、使用後に閉じられ、各リクエストは接続を確立する必要があります。HTTP/1.1のPipelingモードでは、いくつかのリクエストがシリアルシングルスレッド処理のためにキューに入れられ、後続のリクエストは前のリクエストが返されるのを待ってから実行を開始する必要があります。リクエストがタイムアウトすると、後続のリクエストはブロックされます。HTTP/2.0では、複数のリクエストを1つの接続で並行して実行でき、遅延の大きなリクエストは他の接続の通常の実行に影響を与えません。

HTTP/2.0の多重化により、TCP接続をより効果的に利用でき、HTTPパフォーマンスが向上します。TCP接続は「自己調整」を行い、初期段階で接続速度を制限し、データが正常に送信されるにつれて速度を徐々に上げます。つまり、TCPスロースタートです。HTTP/2.0を使用すると、すべてのデータストリームが同じ接続を共有できるため、HTTP接続の非効率性が軽減され、輻輳とパケット損失の回復時間が短縮され、接続スループットが向上します。

• リクエストの優先度：多重化により、キーリクエストがブロックされる可能性があります。HTTP/2.0では、各リクエストに優先度を設定できます。31ビットの優先度値を使用し、0が最高の優先度、2（31）-1が最低の優先度を表します。サーバーは、優先度に従ってリソース割り当てを制御し、優先度の高いリクエストフレームを優先的に処理してクライアントに返すことができます。
• バイナリフレーミング：HTTP/1.1はテキスト解析に基づいており、テキスト形式の多様性により、解析中に複数のシナリオを考慮する必要があり、結果として堅牢性が低下します。HTTP/2.0はバイナリ形式の解析を採用し、アプリケーション層（HTTP/2.0）とトランスポート層（TCPまたはUDP）の間にバイナリフレーミング層を追加します。この層は、送信されるすべての情報を小さなメッセージとフレーム（frame）に分割し、バイナリ形式でエンコードします。HTTP/1.xのヘッダー情報はHEADERフレームにカプセル化され、RequestBodyはDATAフレームにカプセル化されます。HTTP/2.0でのすべての通信は1つの接続で完了し、この接続は任意の数の双方向データストリームを伝送できます。
• ヘッダー圧縮：HTTP/1.1はHTTPヘッダー圧縮をサポートしておらず、この目的のためにSPDYとHTTP/2.0が登場しました。SPDYはDEFLATEアルゴリズムを使用し、HTTP/2.0はHPACKアルゴリズムを使用します。HTTP/2.0はディクショナリを維持し、HTTPヘッダーを段階的に更新して、ヘッダー伝送によって生成されるトラフィックを削減します。両方の通信当事者は、重複するヘッダーの伝送を回避し、伝送サイズを削減するために、ヘッダーフィールドのテーブルをそれぞれキャッシュします。
• サーバープッシュ：HTTP/2.0では、サーバーはクライアントからの単一のリクエストに対して複数のレスポンスを送信できます。サーバープッシュにより、HTTP/1.x時代の組み込みリソースを使用する最適化方法が不要になります。ホームページからリクエストが開始された場合、サーバーはホームページのコンテンツ、ロゴ、スタイルシート、およびクライアントに必要なその他のリソースで応答する可能性があり、これらのリソースはキャッシュ可能であり、同じオリジン下の異なるページ間でキャッシュリソースの共有を実現します。

参考文献

• MDN Web Docs: HTTP
• IETF HTTP/2 Specification

Leapcell: 最高のサーバーレスウェブホスティング

最後に、サービスのデプロイに最適なプラットフォームをお勧めします。Leapcell

🚀 お気に入りの言語で構築する

JavaScript、Python、Go、またはRustで簡単に開発できます。

🌍 無制限のプロジェクトを無料でデプロイ

使った分だけを支払う—リクエストも料金もありません。

⚡ 従量課金制、隠れたコストなし

アイドル料金なし、シームレスなスケーラビリティのみ。

📖 ドキュメントを見る

🔹 Twitterでフォローしてください：@LeapcellHQ