1. HTTPの基本的な最適化

HTTP ネットワークリクエストに影響を与える主な要因は、帯域幅と遅延の 2 つです。

帯域幅
まだダイヤルアップインターネットアクセスの段階にある場合、帯域幅はリクエストに深刻な影響を与える問題になる可能性がありますが、ネットワークインフラストラクチャの帯域幅が大幅に改善された今では、帯域幅がネットワーク速度に影響を与えることを心配する必要はなくなりました。遅延左。
遅れ

ブラウザのブロック (HOL ブロック): ブラウザは何らかの理由でリクエストをブロックします。ブラウザは同じドメイン名に対して同時に 4 つの接続しか持てません (これはブラウザのカーネルによって異なる場合があります)。ブラウザの最大接続数を超えると、後続のリクエストはブロックされます。
DNS ルックアップ: ブラウザは、接続を確立するためにターゲットサーバーの IP を知る必要があります。ドメイン名を IP に解決するシステムは DNS です。これは通常、DNS キャッシュの結果を使用して時間を短縮することで実現できます。
接続の確立 (初期接続): HTTP は TCP プロトコルに基づいています。ブラウザは、実際の接続を確立するために、最も早い 3 回目のハンドシェイクで HTTP 要求メッセージをピギーバックすることしかできません。ただし、これらの接続は再利用できません。各リクエストはどちらも 3 ウェイハンドシェイクとスロースタートを経ます。スリーウェイハンドシェイクの影響は、待ち時間が長いシナリオでより顕著になり、スロースタートは大きなファイルリクエストに大きな影響を与えます。

2. HTTP1.0 と HTTP1.1 のいくつかの違い

2.1. レスポンスステータスコード

HTTP/1.0 では 16 個のステータスコードのみが定義されています。

HTTP/1.1では新たに多数のステータスコードが追加され、エラー応答のステータスコードが24種類追加されました。

例えば：

100（続き）……………………………………………………・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
206（部分内容）・・・範囲要求の識別コード
409（紛争）…………………………………………………………・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
410（ゴーン）………………………………………………………………・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・。

2.2、キャッシュ処理

キャッシュテクノロジは、ユーザーとソースサーバー間の頻繁なやり取りを回避することで、ネットワーク帯域幅を大幅に節約し、ユーザーによる情報受信の遅延を軽減します。

2.2.1、HTTP/1.0

HTTP/1.0 が提供するキャッシュメカニズムは非常にシンプルです。サーバー側は Expires タグを使用して応答本文をマーク (時間を計測) し、Expires マーク時間内のリクエストは応答本文のキャッシュを取得します。サーバーがクライアントに初めて返す応答本文には、サーバー側で要求されたリソースの最後の変更をマークする Last-Modified タグがあります。リクエストヘッダーで、時間をマークする If-Modified-Since タグを使用します。これは、クライアントがサーバーに「この時間以降、リクエストしたいリソースは変更されましたか?」と尋ねることを意味します。通常、If の値はリクエストヘッダーの-Modified-Sinceは、前回リソースを取得したときのレスポンスボディのLast-Modifiedの値です。

サーバーがリクエストヘッダーを受信し、If-Modified-Since 時間が経過してもリソースが変更されていないと判断した場合、サーバーはクライアントに 304 not Modified レスポンスヘッダーを返し、「バッファーは利用可能です。バッファーは次から取得できます」ことを示します。ブラウザー！」

If-Modified-Since 時間後にリソースが変更されたとサーバーが判断した場合、サーバーは新しいリソースの内容を含む 200 OK 応答本文をクライアントに返します。これは、「要求された内容を変更しました。あなたは新しいものです。」

2.2.2、HTTP/1.1

HTTP/1.1 のキャッシュメカニズムは、HTTP/1.0 に基づいて柔軟性とスケーラビリティを大幅に向上させます。基本的な動作原理は HTTP/1.0 と同じですが、より微妙な機能が追加されています。その中で、リクエストヘッダーの最も一般的な機能は Cache-Control です。詳細については、MDN Web ドキュメントの Cache-Controlを参照してください。

2.3. 接続方法

HTTP/1.0 はデフォルトで短い接続を使用します 。つまり、クライアントとサーバーが HTTP 操作を実行するたびに接続が確立され、タスクが完了すると接続が終了します。クライアントブラウザによってアクセスされる HTML またはその他の種類の Web ページに他の Web リソース (JavaScript ファイル、画像ファイル、CSS ファイルなど) が含まれている場合、そのような Web リソースに遭遇するたびに、ブラウザは A TCP を再作成します。接続すると、多数の「ハンドシェイクメッセージ」と「ウェーブメッセージ」が帯域幅を占有することになります。

HTTP/1.0 のリソースの浪費の問題を解決するために、HTTP/1.1 はデフォルトの永続接続モードとして最適化されています。 長時間接続モードを使用したリクエストメッセージは、サーバーに「あなたからの接続をリクエストします。接続が正常に確立された後は、閉じないでください。」と通知します。したがって、TCP 接続は、後続のクライアントとサーバーのデータ対話に対応するために開いたままになります。つまり、長い接続を使用する場合、Web ページを開いたときに、クライアントとサーバーの間で HTTP データを送信するために使用される TCP 接続が閉じられず、クライアントがサーバーに再度アクセスすると、TCP 接続が閉じられません。確立されたこの 1 つの接続を引き続き使用します。

TCP 接続を常に維持することはリソースの無駄でもあるため、一部のサーバーソフトウェア (Apache など) はタイムアウト時間をサポートしています。タイムアウト期間内に新しいリクエストが到着しない場合、TCP 接続は閉じられます。

HTTP/1.0 では依然として長い接続オプションが提供されており、これはリクエストヘッダーに追加されることに注意してくださいConnection: Keep-alive。同様に、HTTP/1.1 では、長時間接続オプションを使用したくない場合は、それをリクエストヘッダーに追加することもできます。Connection: closeこれにより、サーバーに次のように通知されます。「長時間接続は必要ありません。接続が成功すると閉じられます。」

HTTP プロトコルの長い接続と短い接続は、本質的には TCP プロトコルの長い接続と短い接続です。

永続的な接続を実装するには、クライアントとサーバーの両方が永続的な接続をサポートする必要があります。

2.4、ホストヘッダー処理

HTTP1.0 では、各サーバーは一意の IP アドレスにバインドされているとみなされるため、リクエストメッセージ内の URL にはホスト名 (ホスト名) が渡されません。しかし、仮想ホスト技術の発展により、複数の仮想ホスト (マルチホーム Web サーバー) が 1 台の物理サーバー上に存在し、1 つの IP アドレスを共有できるようになりました。HTTP1.1 リクエストメッセージとレスポンスメッセージは両方とも Host ヘッダーフィールドをサポートする必要があり、リクエストメッセージに Host ヘッダーフィールドがない場合、エラー (400 Bad Request) が報告されます。

リソース URL http://example1.org/home.html があるとします。HTTP/1.0 リクエストメッセージでは、リクエストは GET /home.html HTTP/1.0 になります。つまり、ホスト名は追加されません。このようなメッセージはサーバーに送信されますが、サーバーはクライアントが要求する実際の URL を理解できません。

したがって、HTTP/1.1 では、リクエストヘッダーに Host フィールドが追加されました。Host フィールドに追加されるメッセージヘッダーは次のようになります。

GET /home.html HTTP/1.1
Host: example1.org

このようにして、サーバー側はクライアントが要求する実際の URL を決定できます。

2.5. 帯域幅の最適化

2.5.1. 範囲リクエスト

HTTP/1.1 では、帯域幅の無駄を避けるために範囲リクエストメカニズムが導入されました。クライアントがファイルの一部をリクエストしたい場合、またはダウンロードされたが終了したファイルのダウンロードを続行する必要がある場合、HTTP/1.1 はリクエストにヘッダーを追加して、データ部分をリクエストする (バイトデータのみをリクエストする) ことができますRange。サーバー側はRangeヘッダーを無視することも、複数のRange応答を返すこともできます。

応答に部分的なデータが含まれる場合、206 (Partial Content)ステータスコードが含まれます。このステータスコードの重要性は、HTTP/1.0 プロキシキャッシュが応答を完全なデータ応答と誤ってみなし、それによって要求の応答キャッシュとして扱われないようにすることです。

範囲応答では、Content-Rangeヘッダーフラグはデータブロックのオフセットとデータブロックの長さを示します。

2.5.2、ステータスコード 100

ステータスコードはHTTP/1.1で新たに追加されました100。100このステータスコードの使用シナリオは、いくつかの大きなファイルリクエストがあり、サーバーがそのようなリクエストに応答できない可能性がある場合です。このとき、ステータスコードは、リクエストが正常に応答されるかどうかの指標として使用できます。. プロセスは次のとおりです。

ただし、HTTP/1.0 にはステータスコードがないため、100 (Continue)このメカニズムをトリガーするには、値をExpect含むヘッダーを送信できます100-continue。

2.5.3. 圧縮

多くの形式のデータは送信中に事前圧縮されます。データ圧縮により、帯域幅の使用率を大幅に最適化できます。ただし、HTTP/1.0 はデータ圧縮のオプションをあまり提供せず、圧縮詳細の選択をサポートせず、エンドツーエンド (エンドツーエンド) 圧縮とホップバイホップ (ホップバイ) を区別できません。 -ホップ) 圧縮。

HTTP/1.1 では、コンテンツコーディングと転送コーディングが区別されます。コンテンツのエンコードは常にエンドツーエンドであり、転送のエンコードは常にホップバイホップです。

HTTP/1.0 には、メッセージをエンドツーエンドでエンコードする Content-Encoding ヘッダーが含まれています。

HTTP/1.1 では、メッセージに対してホップバイホップの転送エンコーディングを実行できる Transfer-Encoding ヘッダーが追加されています。

HTTP/1.1 では、Accept-Encoding ヘッダーも追加されました。これは、クライアントが処理できるコンテンツエンコーディングを示すために使用されます。

2.6. 概要

接続方法 : HTTP 1.0 は短い接続ですが、HTTP 1.1 は長い接続をサポートします。
ステータス応答コード : HTTP/1.1 では、エラー応答用の 24 の新しいステータスコードを含む、多数のステータスコードが追加されました。
例:
100 (Continue)大規模なリソースを要求する前にリクエストをウォームアップする...
206 (Partial Content)範囲リクエストの識別子
409 (Conflict)...................................................................................................................・・・・・・・・・・・・・・・・・・・・・・・・・・・・
410 (Gone)。
キャッシュ処理 ：HTTP1.0では主にヘッダー内のIf-Modified-SinceとExpiresをキャッシュ判定の基準として使用していましたが、HTTP1.1ではEntityタグ、If-Unmodified-Since、If-などのキャッシュ制御戦略がさらに導入されています。 Match、If-None-Match、およびその他のオプションのキャッシュヘッダーを使用して、キャッシュ戦略を制御します。
帯域幅の最適化とネットワーク接続の利用 : HTTP1.0では、クライアントはオブジェクトの一部のみを必要としますが、サーバーはオブジェクト全体を送信し、再開機能をサポートしていないなど、帯域幅を無駄に消費する現象がいくつかあります。 HTTP1.1 では、リクエストヘッダーに範囲ヘッダーフィールドが導入されており、リソースの特定の部分のみをリクエストすることができます。つまり、リターンコードは 206 (部分コンテンツ) であり、開発者がアップロードする内容を自由に選択できるため便利です。帯域幅と接続を最大限に活用します。
ホストヘッダー処理 : HTTP/1.1 では、Hostリクエストヘッダーにフィールドが追加されます。

3. SPDY: HTTP1.x の最適化

2012 年、Google は、HTTP1.X のリクエスト遅延を最適化し、HTTP1.X のセキュリティを解決する、雷のような SPDY ソリューションを次のように提案しました。

3.1.レイテンシーの短縮

HTTP 遅延が長いという問題を解決するために、SPDY は多重化を巧みに採用しています。多重化は、1 つの TCP 接続を複数の要求ストリームと共有することで HOL ブロッキングの問題を解決し、遅延を削減し、帯域幅の使用率を向上させます。

3.2、リクエストの優先順位（リクエストの優先順位付け）

多重化によってもたらされる新たな問題は、接続共有に基づいてキー要求がブロックされる可能性があることです。SPDY では、各リクエストに優先順位を設定できるため、重要なリクエストが最初に応答されます。たとえば、ブラウザがホームページを読み込むとき、最初にホームページの HTML コンテンツが表示され、その後、さまざまな静的リソースファイルやスクリプトファイルなどが読み込まれ、ユーザーが初めて Web ページのコンテンツを見ることができるようになります。

3.3、ヘッダー圧縮

前述したように、HTTP1.x のヘッダーは冗長であることがよくあります。適切な圧縮アルゴリズムを選択すると、パケットのサイズと数を削減できます。

3.4. HTTPSベースの暗号化プロトコル送信

データ伝送の信頼性が大幅に向上します。

3.5、サーバープッシュ（サーバープッシュ）

SPDY を使用する Web ページ。たとえば、私の Web ページには sytle.css のリクエストがあります。クライアントが sytle.css データを受信すると、サーバーは sytle.js ファイルをクライアントにプッシュします。クライアントが再度ファイルを取得しようとすると、sytle .js はキャッシュから直接取得できるため、リクエストを送信する必要はありません。SPDY構成図：

SPDY は HTTP の下、TCP および SSL の上に位置するため、古いバージョンの HTTP プロトコル (HTTP1.x のコンテンツを新しいフレーム形式にカプセル化) と簡単に互換性があり、既存の SSL 機能を使用できます。同時。

4. HTTP2.0: SPDY のアップグレード版

HTTP2.0 は SPDY のアップグレード版と言えます (実際、もともと SPDY をベースに設計されています) が、HTTP2.0 と SPDY の間には次のような違いがあります。

HTTP2.0 と SPDY の違い:

HTTP2.0 はプレーンテキストの HTTP 送信をサポートしますが、SPDY は HTTPS の使用を強制します。
HTTP2.0 メッセージヘッダーの圧縮アルゴリズムは、SPDY で使用される DEFLATE ではなく HPACK を使用します。

5. HTTP1.Xと比較したHTTP2.0の新機能

新しいバイナリ形式 (Binary Format) は、HTTP1.x の解析をテキストに基づいて行います。テキストプロトコルに基づくフォーマット解析には当然の欠陥があります。テキストの表現は多様であり、堅牢性を考慮するには多くのシナリオが必要です。バイナリは異なり、0 と 1 の組み合わせしか認識されません。この考慮に基づいて、HTTP2.0 のプロトコル分析では、実装に便利で堅牢なバイナリ形式を使用することが決定されました。
多重化（MultiPlexing）、つまり接続共有、つまり各リクエストは接続共有メカニズムとして使用されます。1 つのリクエストは 1 つの ID に対応するため、1 つの接続上に複数のリクエストが存在する可能性があり、各接続のリクエストをランダムに混在させることができ、受信側はリクエスト ID に応じてリクエストを異なるサーバーリクエストに割り当てることができます。
ヘッダー圧縮は、前述したHTTP1.xのヘッダーには多くの情報が含まれており、毎回繰り返し送信する必要がありますが、HTTP2.0ではエンコーダーを使用して、送信する必要があるヘッダーのサイズを削減します。、通信の各当事者はコピーをキャッシュします。ヘッダーフィールドテーブルは、ヘッダーの繰り返しの送信を回避するだけでなく、送信する必要があるサイズも削減します。
サーバープッシュ（サーバープッシュ） SPDYと同様に、HTTP2.0にもサーバープッシュ機能があります。

6. HTTP2.0のアップグレードと変換

前述したように、HTTP 2.0 は実際には非 HTTPS をサポートできますが、Chrome や Firefox などの主流ブラウザは依然として TLS 展開に基づく HTTP 2.0 プロトコルのみをサポートしているため、HTTP 2.0 にアップグレードする場合は、まず HTTPS にアップグレードすることをお勧めします。。
Web サイトが HTTPS にアップグレードされた後は、HTTP2.0 へのアップグレードがはるかに簡単になります。NGINX を使用する場合は、構成ファイルで対応するプロトコルを有効にするだけです。NGINX ホワイトペーパー、NGINX 公式ガイドを参照してください。HTTP2.0の構成へ。
HTTP2.0 を使用する場合、元の HTTP1.x はどうすればよいでしょうか? 実際、この問題について心配する必要はありません。HTTP2.0 は HTTP1.x のセマンティクスと完全に互換性があります。 HTTP2.0 をサポートすると、NGINX は自動的に下位互換性を持ちます。

7. 注意事項

7.1 HTTP2.0の多重化とHTTP1.Xの長い接続の多重化の違いは何ですか?

HTTP/1.* リクエストとレスポンス。接続を確立し、使い果たされると閉じます。各リクエストは接続を確立する必要があります。
HTTP/1.1 パイプリングの解決策は、複数のリクエストがキューに入れられ、シングルスレッド処理用にシリアル化され、後続のリクエストは実行の機会を得るために前のリクエストが返されるのを待つことです。リクエストがタイムアウトすると、後続のリクエストはブロックされるだけです。つまり、回線の終端がブロックされているとよく言われます。
HTTP/2 の複数のリクエストは、1 つの接続上で同時に並行して実行できます。特定の要求タスクには時間がかかりますが、他の接続の通常の実行には影響しません。

具体的には図のようになります。

7.2.サーバープッシュとは正確には何ですか?

サーバー側プッシュでは、クライアントが必要とするリソースを Index.html とともにクライアントに送信できるため、クライアントが繰り返しリクエストする必要がなくなります。リクエストの開始や接続の確立などの操作がないため、静的リソースをサーバー経由でプッシュすることにより、静的リソースの速度が大幅に向上します。詳細は次のとおりです。

7.2.1. 通常のクライアントリクエスト処理

7.2.2. サーバープッシュのプロセス

7.3.ヘッダー圧縮が必要なのはなぜですか?

ページにロードするリソースが 100 個あり (この量は今日の Web ではかなり控えめです)、各リクエストには 1kb のメッセージヘッダーがあるとします (Cookie や参照などの理由で、これも珍しいことではありません)。これらのメッセージヘッダーを取得するには、さらに 100 kb が必要です。HTTP 2.0 は辞書を維持し、HTTP ヘッダーを少しずつ更新できるため、ヘッダーの送信によって生成されるトラフィックを大幅に削減できます。具体的な参考資料: HTTP/2 ヘッダー圧縮テクノロジーの概要

7.4 HTTP2.0 多重化はどの程度優れていますか?

HTTP パフォーマンス最適化の鍵は、高帯域幅ではなく、低遅延です。TCP 接続は時間の経過とともに自動的に「調整」され、最初は接続の最大速度が制限されますが、データが正常に送信されると時間の経過とともに速度が増加します。このチューニングは TCP スロースタートと呼ばれます。このため、すでにバースト的で持続時間が短い HTTP 接続は、非常に非効率になります。
HTTP/2 では、すべてのデータストリームが同じ接続を共有できるようにすることで、TCP 接続をより効率的に使用できるようになり、高帯域幅によって HTTP パフォーマンスも真に向上します。

8、参考

1.0 と比較した HTTP/2.0 の主な改善点は何ですか?
徹底した調査: HTTP2 の
 実際のパフォーマンスとは HTTP/2 ヘッダー圧縮テクノロジーの概要

HTTP - HTTP 1.0、HTTP 1.1、HTTP 2.0の違い