HTTP / 2へのパス

翻訳者から：ここに、HTTPプロトコルとその履歴の概要があります-バージョン0.9からバージョン2まで。

HTTPはWebピアシングプロトコルです。 すべてのWeb開発者はそれを知る必要があります。 HTTPの仕組みを理解すると、Webアプリケーションを改善できます。

この記事では、HTTPとは何か、どのようにHTTPが今日のようになったかについて説明します。

HTTPとは何ですか？

それでは、HTTPとは何かを見てみましょう。 HTTPは、TCP / IPを介して実装されるアプリケーション層プロトコルです。 HTTPは、クライアントとサーバーが相互にやり取りする方法、コンテンツがインターネット上で要求および送信される方法を決定します。 アプリケーションレベルのプロトコルでは、これは単なる抽象化であり、ネットワークノード（クライアントとサーバー）が相互に対話する方法を標準化することを理解しています。 HTTP自体はTCP / IPプロトコルに依存しているため、クライアントとサーバー間でリクエストを送受信できます。 デフォルトでは、TCPポート80が使用されますが、他のポートも使用できます。 たとえば、HTTPSはポート443を使用します。

HTTP / 0.9-最初の標準（1991）

文書化された最初のHTTPバージョンは、1991年にリリースされたHTTP / 0.9でした。 これは、GETという1つの方法で、世界で最も単純なプロトコルでした。 クライアントがサーバー上のページを取得する必要がある場合、彼はリクエストを行いました。

GET /index.html 

そして、サーバーから次のようなものが来ました：

 (response body) (connection closed) 

以上です。 サーバーは要求を受信し、応答としてHTMLを送信し、すべてのコンテンツが送信されるとすぐに接続を閉じます。 HTTP / 0.9にはヘッダーがありません。唯一の方法はGETであり、答えはHTMLで提供されます。

そのため、HTTP / 0.9は残りの歴史の最初のステップでした。

HTTP / 1.0-1996

HTML応答専用に設計されたHTTP / 0.9とは異なり、HTTP / 1.0は他の形式（画像、ビデオ、テキスト、その他の種類のコンテンツ）も処理します。 新しいメソッドが追加されました（POSTやHEADなど）。 要求/応答の形式が変更されました。 要求と応答に追加されたHTTPヘッダー。 さまざまなサーバー応答を区別するために、ステータスコードが追加されました。 エンコードのサポートが導入されました。 マルチパートタイプ、認証、キャッシュ、コンテンツのさまざまなエンコーディングなどが追加されました。

これは、HTTP / 1.0の単純なリクエストとレスポンスの外観です。

 GET / HTTP/1.0 Host: kamranahmed.info User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) Accept: */* 

要求に加えて、クライアントは個人情報、必要な応答の種類などを送信しました。 HTTP / 0.9では、ヘッダーが存在しなかったため、クライアントはそのような情報を送信しませんでした。

同様の要求に対する応答の例：

 HTTP/1.0 200 OK Content-Type: text/plain Content-Length: 137582 Expires: Thu, 05 Dec 1997 16:00:00 GMT Last-Modified: Wed, 5 August 1996 15:55:28 GMT Server: Apache 0.84 (response body) (connection closed) 

応答の先頭はHTTP / 1.0（HTTPおよびバージョン番号）であり、ステータスコードは200、ステータスコードの説明です。

新しいバージョンでは、要求および応答ヘッダーはASCIIでエンコードされました（すべてのHTTP / 0.9はASCIIでエンコードされました）が、応答本文は任意のコンテンツタイプ（画像、ビデオ、HTML、プレーンテキストなど）になります。クライアントへのコンテンツの種類。したがって、頭字語HTTPの「ハイパーテキスト」というフレーズは歪みになっています。 HMTP、またはハイパーメディア転送プロトコルは、おそらくより適切な名前になりますが、それまでに誰もがすでにHTTPに慣れていました。

HTTP / 1.0の主な欠点の1つは、同じ接続中に複数の要求を送信できないことです。 クライアントがサーバーから何かを取得する必要がある場合、クライアントは新しいTCP接続を開く必要があり、要求が完了するとすぐにこの接続は閉じられます。 後続のリクエストごとに、新しい接続を作成する必要があります。

なぜこれが悪いのですか？ 10個の画像、5個のスタイルファイル、5個のJavaScriptファイルを含むページを開くと仮定します。 このページを照会する場合、合計で20のリソースを取得する必要があります。つまり、サーバーは20の個別の接続を作成する必要があります。 新しいTCP接続ごとに「トリプルハンドシェイク」とそれに続くスロースタートが必要になるため、この接続数はパフォーマンスに大きく影響します。

トリプルハンドシェイク

「トリプルハンドシェイク」とは、クライアントとサーバー間の一連のパケットの交換であり、TCP接続を確立してデータ転送を開始できます。

• SYN-クライアントはxなどの乱数を生成し、サーバーに送信します。
• SYN ACK-サーバーは、サーバーによって選択された乱数（たとえば、 y ）とx + 1で構成されるACKパケットを送り返すことにより、この要求を確認します。xはクライアントから受信した番号です。
• ACK-クライアントはサーバーから受信した数yを増やし、 y + 1をサーバーに送信します。

翻訳者注 ： SYN-シーケンス番号を同期します。 ACK- 「確認番号」フィールドが有効になります。

トリプルハンドシェイクの完了後にのみ、クライアントとサーバー間のデータ転送が開始されます。 クライアントは最後のACKパケットを送信した直後にデータを送信できますが、サーバーはまだACKパケットが要求を完了することを期待しています。

ただし、一部のHTTP / 1.0実装では、新しいConnection：keep-aliveヘッダーを追加することでこの問題を解決しようとしました。これは、サーバーに「ねえ、バディ、この接続を閉じないでください、まだ有用です」と言います。 ただし、この機能は広く普及していなかったため、問題は引き続き重要でした。

HTTPはコネクションレス型プロトコルであるという事実に加えて、状態サポートも提供しません。 つまり、サーバーはクライアントに関する情報を保存しないため、各リクエストには過去のリクエストを考慮せずに、サーバーが必要とするすべての情報を含める必要があります。 そして、これは火災に燃料を追加するだけです。クライアントが開く膨大な数の接続に加えて、繰り返しデータを送信し、ネットワークを不必要に過負荷にします。

HTTP / 1.1-1999

HTTP / 1.0から3年が経過し、1999年にプロトコルの新しいバージョンがリリースされました-HTTP / 1.1には多くの改良が含まれています：

• 新しいHTTPメソッドは、PUT、PATCH、HEAD、OPTIONS、DELETEです。
• ホスト識別。 HTTP / 1.0では、Hostヘッダーはオプションでしたが、HTTP / 1.1ではオプションになりました。
• 永続的な接続。 前述のように、HTTP / 1.0では、1つの接続が1つの要求のみを処理し、すぐに閉じられたため、深刻なパフォーマンスの問題と遅延の問題が発生しました。 HTTP / 1.1では、持続的な接続が登場しました。 デフォルトでは閉じられず、複数の連続した要求に対して開いたままである接続。 接続を閉じるには、プロンプトが表示されたらConnection：closeヘッダーを追加する必要がありました。 クライアントは通常、サーバーへの最後の要求でこのヘッダーを送信して、接続を安全に閉じます。
• クライアントが応答を待たずに接続の一部としてサーバーに複数の要求を送信できるストリーミングデータ。サーバーは、要求が受信されたのと同じ順序で応答を送信します。 しかし、ある答えが終わり、別の答えがいつ始まるかをクライアントはどのように知るのでしょうか？ このタスクを解決するために、Content-Lengthヘッダーが設定されます。これにより、クライアントは1つの応答が終了し、次の応答が予想される場所を決定します。

持続的な接続またはストリーミングデータの利点を感じるためには、応答でContent-Lengthヘッダーが利用可能でなければならないことに注意してください。 これにより、クライアントは転送がいつ完了するかを理解でき、次の要求を送信する（通常の連続した要求の場合）か、次の応答の待機を開始する（ストリーミングの場合）ことができます。
しかし、このアプローチにはまだ問題がありました。 データが動的で、サーバーが送信前にコンテンツの長さを認識できない場合はどうなりますか？ この場合、永続的な接続を使用できませんか？ この問題を解決するために、HTTP / 1.1は、情報を小さな部分（チャンク）に分割して送信するメカニズムであるハンクエンコーディングを導入しました。

• コンテンツが動的に構築され、転送の開始時にサーバーがContent-Lengthを判別できない場合、 チャンク転送は、 コンテンツを次々に部分的に送信し始め、各送信部分にContent-Lengthを追加します。 すべての部分が送信されると、 Content-Lengthヘッダーが0に設定された空のパケットが送信され、転送が完了したことをクライアントに通知します。 転送が部分的に行われることをクライアントに伝えるために、サーバーはTransfer-Encoding：chunkedヘッダーを追加します。
• HTTP / 1.0の基本認証とは異なり、 ダイジェスト認証とプロキシ認証がHTTP / 1.1に追加されました。
• キャッシング
• バイト範囲
• エンコーディング
• コンテンツ交渉
• クライアントCookie 。
• 圧縮サポートの改善 。
• その他

機能HTTP / 1.1-会話用の別のトピック。この記事では、このトピックについて長々と説明しません。 このトピックに関する膨大な量の資料を見つけることができます。 HTTP / 1.0とHTTP / 1.1の重要な違い、およびスーパーヒーローにはRFCへのリンクを読むことをお勧めします 。

HTTP / 1.1は1999年に登場し、長年にわたって標準のままでした。 そして、それはその前身よりもはるかに優れていましたが、時間とともに時代遅れになり始めました。 Webは絶えず成長および変化しており、Webページの読み込みには毎日より多くのリソースが必要です。 今日、標準のWebページは30以上の接続を開かなければなりません。 あなたは言うでしょう：「しかし...結局... HTTP / 1.1では常に接続があります...」。 ただし、HTTP / 1.1は常に1つの外部接続のみをサポートします。 HTTP / 1.1はデータをストリーミングすることでこれを修正しようとしましたが、これは問題を完全には解決しませんでした。 キューの先頭をブロックする問題（ ヘッドオブラインブロッキング ）-低速または大規模な要求が後続のすべてを要求したとき（キューの順序で実行されたため）。 HTTP / 1.1のこれらの欠点を克服するために、開発者は回避策を考案しました。 この例は、CSSイメージでエンコードされたスプライト、CSSファイルとJSファイルの連結、 ドメインシャーディングなどです。

SPDY-2009

Googleはさらに進んで、Webページの遅延を減らしてWebを高速化し、セキュリティを向上させることを目標に、代替プロトコルの実験を開始しました。 2009年に、彼らはSPDYプロトコルを導入しました。

ネットワーク帯域幅を増やし続けると、パフォーマンスが向上するように見えました。 ただし、特定の時点から、スループットの増加がパフォーマンスに影響を与えなくなることが判明しました。 一方、遅延の大きさで操作する場合、つまり応答時間を短縮する場合、パフォーマンスゲインは一定になります。 これがSPDYの主なアイデアでした。

違いが何であるかを明確にする必要があります：遅延時間は、送信者から受信者にデータを送信するのにかかる時間（ミリ秒単位）を示す値であり、スループットは1秒あたりの送信データ量（1秒あたりのビット数）です。

SPDYには、多重化、圧縮、優先順位付け、セキュリティなどが含まれていました。次のセクションでは典型的なHTTP / 2プロパティを分析し、HTTP / 2はSPDYから多くを取得したため、SPDYの話に飛び込みません。

SPDYは、HTTPをそれ自体に置き換えようとしませんでした。 これは、アプリケーションレベルに存在するHTTP上の遷移層であり、回線を介して送信する前に要求を変更しました。 それは事実上の標準になり始め、ほとんどのブラウザはそれをサポートし始めました。

2015年に、Googleは2つの競合する標準が存在しないことを決定し、SPDYとHTTPを組み合わせてHTTP / 2を生み出しました。

HTTP / 2-2015

HTTPプロトコルの新しいバージョンが必要であることは既におわかりだと思います。 HTTP / 2は、コンテンツを低遅延で転送するように設計されました。 HTTP / 1.1との主な違い：

• テキストの代わりにバイナリ
• 多重化-単一のTCP接続を介して複数の非同期HTTP要求を送信する
• HPACKヘッダー圧縮
• サーバープッシュ-単一の要求に対する複数の応答
• クエリの優先順位付け
• 安全性

1.バイナリプロトコル

HTTP / 2は、バイナリ形式に切り替えることにより、HTTP / 1.xに存在していた遅延の増加の問題を解決しようとしています。 バイナリメッセージは自動的に高速で解析されますが、HTTP / 1.xとは異なり、人間が読むことはできません。 HTTP / 2の主なコンポーネントは、フレーム（フレーム）とストリーム（ストリーム）です。

フレームとストリーム。

HTTPメッセージは1つ以上のフレームで構成されています。 HEADERSフレームはメタデータに使用され、DATAフレームはメインデータに使用され、HTTP / 2仕様で見つかる他のタイプのフレーム（RST_STREAM、SETTINGS、PRIORITYなど）があります 。

各HTTP / 2要求と応答は、一意のストリーム識別子を受け取り、フレームに分割されます。 フレームは単なるバイナリデータです。 フレームのコレクションは、ストリームと呼ばれます。 各フレームには、どのストリームに属するかを示すストリーム識別子が含まれ、各フレームには共通のヘッダーが含まれます。 また、ストリーム識別子が一意であるという事実に加えて、各クライアント要求が奇数のIDを使用し、サーバーからの応答が偶数であることを言及する価値があります。

HEADERSとDATAに加えて、RST_STREAM-ストリームの中断に使用される特別なタイプのフレームも言及する価値があります。 クライアントはこのフレームをサーバーに送信して、このストリームが不要になったことを通知できます。 HTTP / 1.1では、サーバーが応答の送信を停止する唯一の方法は、接続を閉じることでした。これにより、以降の要求に対して新しい接続を開く必要があったため、遅延時間が増加しました。 また、HTTP / 2では、クライアントはRST_STREAMを送信し、特定のストリームの受信を停止できます。 同時に、接続は開いたままになり、残りのスレッドが機能します。

2.多重化

HTTP / 2は、前述のように、要求と応答にフレームとストリームを使用するバイナリプロトコルであるため、追加のストリームを作成せずに、すべてのストリームが単一のTCP接続で送信されます。 サーバーは、同様の非同期方式で応答します。 これは、応答が順序どおりではなく、クライアントがスレッド識別子を使用して、パケットがどのスレッドに属しているかを理解することを意味します。 これにより、キューの先頭をブロックする問題（行頭ブロッキング ）が解決されます。クライアントは、待機中に残りの要求を処理できるため、アイドル状態で長い要求の処理を待つ必要がありません。

3. HPACKヘッダー圧縮

これは、送信ヘッダーの最適化を特に目的とした別のRFCの一部でした。 同じクライアントからサーバーに絶えずアクセスしている場合、大量の繰り返しデータがヘッダーで何度も送信されるという事実に基づいていました。 また、これにCookieが追加され、ヘッダーのサイズが大きくなることがあります。これにより、ネットワーク帯域幅が減少し、遅延時間が長くなります。 この問題を解決するために、HTTP / 2でヘッダー圧縮が導入されました。

要求および応答とは異なり、ヘッダーはgzipまたは同様の形式で圧縮されません。 圧縮には異なるメカニズムが使用されます-リテラル値はHuffmanアルゴリズムを使用して圧縮されますが、クライアントとサーバーは単一のヘッダーテーブルをサポートします。 重複したヘッダー（たとえば、ユーザーエージェント）は、繰り返し要求中に省略され、ヘッダーテーブル内の位置を参照します。

ヘッダーについて説明しているので、それらはHTTP / 1.1と変わらないことを追加します。ただし、メソッド、スキーム、ホスト、パスなど、いくつかの疑似ヘッダーが追加されています。

4.サーバープッシュ

サーバープッシュはHTTP / 2のもう1つのすばらしい機能です。 クライアントが特定のリソースを要求することを知っているサーバーは、要求を待たずに送信できます。 ここで、たとえば、それが有用である場合、ブラウザはWebページをロードし、それを解析し、サーバーからダウンロードする必要がある他のコンテンツを見つけて、対応するリクエストを送信します。

サーバープッシュにより、サーバーは追加のリクエストの数を減らすことができます。 クライアントがデータを要求することを知っている場合、彼はすぐにそれらを送信します。 サーバーは特別なPUSH_PROMISEフレームを送信し、クライアントに次のように伝えます。「ねえ、バディ、このリソースを送信します。 また、もう迷惑をかけないでください。」PUSH_PROMISEフレームは、プッシュを送信したストリームに関連付けられており、サーバーが目的のリソースを送信するストリームの識別子を含んでいます。

5.優先順位付けを要求する

クライアントは、ストリームを開くHEADERSフレームに優先度情報を追加することにより、ストリームに優先順位を付けることができます。 それ以外の場合、クライアントは、ストリームの優先度を変更するPRIORITYフレームを送信できます。

優先度情報が指定されていない場合、サーバーはリクエストを非同期に処理します。 注文なし。 優先度が割り当てられている場合、優先度に関する情報に基づいて、サーバーは特定のストリームの処理に割り当てるリソースの数を決定します。

6.セキュリティ

セキュリティ（TLSプロトコルを介した送信）がHTTP / 2に必須であるかどうかについては、広範な議論が展開されています。 最終的に、これを必須にしないことが決定されました。 ただし、ほとんどのブラウザベンダーは、TLSを介して使用される場合にのみHTTP / 2をサポートすると述べています。 したがって、この仕様ではHTTP / 2の暗号化は必要ありませんが、デフォルトでは引き続き必須になります。 同時に、TLSの上に実装されたHTTP / 2にはいくつかの制限があります：TLSバージョン1.2以降が必要、最小キーサイズに制限、短命キーが必要など。

おわりに

HTTP / 2はすでに存在し、 サポートでSPDYをバイパスしています。これは徐々に成長しています。 詳細を知りたい人のために、 HTTP / 2速度の利点を示す仕様へのリンクとデモへのリンクを以下に示します。

HTTP / 2には、パフォーマンスを向上させるための多くの機能があり、使用を開始するときが来たようです。

オリジナル：Kamran AhmedによるHTTP / 2への旅 。

翻訳： アンドレイ・アレクシーエフ、編集者：アナトリー・トゥトフ、 ジャバー 、イゴール・ペレハン、ナタリア・ヨーキーナ、ティモフェイ・マリニン、チャイカ・チュルシーナ、ヤナ・クリクリヴァヤ。