HTTP 1.0 HTTP 1.1 HTTP 2.0の違いを振り返る.

HTTP 1.0とHTTP 1.1のいくつかの違い
キャッシュ処理
HTTP 1.0では、主にheader内のIf-Modified-Since(リソースの最後の更新時間が一致しているかどうかを比較する)が使用され、Expires(リソースの期限切れ時間(クライアントローカル時間に依存する)がキャッシュ判定の基準とされる.
HTTP 1.1はより多くのキャッシュ制御戦略を導入している.

Entity tag:リソースのマッチング情報

If-Unmodified-Since:リソースの最後の更新時間が一致していないかを比較する

If-Match:ETagが一致しているかどうかを比較する

If-None-Match:ETagが一致していないかを比較する

など、バッファポリシーを制御するために選択可能なより多くのキャッシュヘッダを使用します.
帯域幅最適化
HTTP 1.0には、クライアントがあるオブジェクトの一部だけを必要とするような帯域幅を浪費する現象がありますが、サーバはオブジェクト全体を送ってきました.ブレークポイントの継続機能はサポートされていません.
HTTP 1.1デフォルトはブレークポイントの継続をサポートしています.
ホットヘッド処理
HTTP 1.0では、サーバごとに一意のIPアドレスがバインドされていると考えられているので、要求メッセージのURLはホスト名を転送していない.しかし、仮想ホスト技術が発達すると、物理サーバ上に複数の仮想ホストが存在し、IPアドレスを共有することができる.HTTP 1.1の要求メッセージと応答メッセージは、いずれもHostヘッダドメインをサポートし、要求メッセージにHostヘッダドメインがない場合にはエラーを報告する(400 Bad Request).
長い接続
HTTP 1.0は、keep-aliveパラメータを使用して、サーバー側に長い接続を確立することを知らせる必要がありますが、HTTP 1.1はデフォルトでは長い接続をサポートしています.HTTP 1.0は要求毎に接続の欠点を作成しなければならないことをある程度補っています.
HTTPはTCP/IPプロトコルに基づいており、TCP接続を作るには3回の握手が必要であり、一定のオーバーヘッドがあり、通信ごとに接続を再確立すると、性能に影響があります.長い接続を維持したほうがいいです.長い接続で複数の要求を送ることができます.
HTTP 1.1は、長い接続(PersistentConnection)と要求されたライン(Pipelining)処理をサポートし、1つのTCP接続上で複数のHTTP要求と応答を転送し、接続の確立とクローズの遅延を低減する.
エラー通知の管理
HTTP 1.1には、409(Conflickt)のように要求されたリソースとリソースの現在の状態が衝突する24個のエラー状態応答コードが追加されている.410(Gone)は、サーバ上のあるリソースが恒久的に削除されることを示す.
新規要求方式

PUT:サーバにリソースの保存を要求する

DELETE:サーバに識別されたリソースの削除を要求する

OPTTIONS:サーバの性能の照会を要求するか、またはリソースに関するオプションと需要を問い合わせる

CONNET:将来の

を使用するために要求を保留する.

TRACE:要求サーバは、主にテストまたは診断のために受信された要求情報を返送する.
HTTP 2.0とHTTP 1.Xの違い
HTTP 1.Xバージョンの欠陥要約としては、スレッドがブロックされ、同じ時間に同じドメイン名の要求が一定の数量制限され、制限数を超える要求がブロックされます.
バイナリフレーム
HTTP 1.xの解析はテキストに基づいています.テキストプロトコルによる形式解析には天然的な欠陥があり、テキストの表現形式には多様性があり、健やかに考える場面が必然的に多く、バイナリは違って0と1の組み合わせしか認められない.この考えに基づいてHTTP 2.0のプロトコル解析決定はバイナリ形式を採用し、便利でロバストな実現を実現します.
HTTP 2.0は、アプリケーション層(HTTP 2.0)とトランスポート層(TCP／UDP)との間に2進数サブフレーム層を追加する.HTTP 1.Xの意味、方法、状態コード、URI及びヘッダフィールドを変えない場合、HTTP 1.1の性能制限を解決し、伝送性能を向上させ、低遅延と高スループットを実現する.バイナリフレーム層では、HTTP 2.0は伝送されたすべての情報をより小さなメッセージとフレームに分割し、それらに対してバイナリフォーマットの符号化を採用しており、HTTP 1.Xのヘッダ情報はHEADER frameにカプセル化され、対応するRequest BodyはDATA frameにカプセル化される.

フレーム:HTTP 2.0データ通信の最小単位メッセージ:HTTP 2.0における論理的なHTTPメッセージを指す.例えば、要求および応答など、メッセージは1つまたは複数のフレームで構成される.

ストリーム:接続中の仮想チャネルが存在する.ストリームは、双方向メッセージを運ぶことができ、各ストリームは、一意の整数IDを有する.

多重化(Multi Plexing)
多重化は、複数の要求−応答メッセージを単一のHTTP 2.0接続によって同時に開始することを可能にする.接続共有であり、接続の利用率を向上させ、遅延を低減させる.すなわち、各requestは、接続共有機構として機能している.一つのrequestは一つのidに対応していて、このような接続には複数のrequestがあってもよく、各接続のrequestはランダムに混ざってもよく、受信者はrequestのidに従ってrequestをそれぞれの異なるサービスエンド要求に再帰属させてもよい.
HTTP 1.1プロトコルでは、ブラウザクライアントは同じ時間に、同じドメイン名の要求に対して一定の数量制限があります.制限数を超える要求はブロックされます.これはなぜいくつかのサイトが複数の静的リソースCDNドメインを有するかの原因の一つである.
もちろんHTTP 1.1は複数のTCP接続を確立して、より多くの同時処理の要求をサポートすることもできるが、TCP接続を作成すること自体にもオーバーヘッドがある.
TCP接続には予熱と保護の過程があります.データの転送が成功したかどうかを確認します.成功したら、徐々に伝送速度を上げます.そのため、瞬時に同時接続に対応するとサーバの応答が遅くなります.この接続は、確立された接続を使用した方がよく、瞬時の同時性の要求をサポートすることができます.
HTTP 2.0は、複数のTCP接続を確立することに依存せずに、複数のストリームを並列に実現することができ、同じドメイン名はTCP接続を占有するだけで、複数のTCP接続による遅延とメモリ消費をなくすことができる.HTTPプロトコル通信の基本単位を1つのフレームに縮小するHTTP 2.0は、これらのフレームは論理ストリーム中のメッセージに対応している.同時に同じTCP接続上で双方向にメッセージを交換する.
header圧縮
HTTP 1.xのheaderは大量の情報を持っていて、しかも毎回繰り返し送信します.HTTP 2.0はHPACKアルゴリズムを使ってheaderのデータを圧縮して、伝送が必要なheaderサイズを減らして、通信双方はcacheにheader fieldsテーブルを一つずつ持っています.
headerがとった圧縮戦略:

HTTP 2.0は、クライアントとサーバ端で「ヘッダテーブル」を使用して、以前に送信されたキー−値ペアを追跡して記憶し、同じデータについては、各要求と応答によって送信しない.

ヘッダテーブルはHTTP 2.0の接続存続期間内に常に存在し、クライアントとサーバと共に漸進的に更新される.

それぞれの新しいヘッダキー−値ペアは、現在のテーブルの最後に追加されるか、または、テーブルの前の値を置換する.

サービスエンドプッシュ
サービスエンドプッシュは、クライアント要求の前にデータを送信するメカニズムである.
サービス端末は、ブラウザが対応する位置に解析されるまではなく、HTMLを送信する時に他のリソースを自動的に押して送ることができ、要求を開始してから応答する.例えば、サービス端末は、クライアントがHTMLを解析する必要がない時に、JSとCSSファイルをクライアントに自動的にプッシュして送信することができる.
サーバーから送ったこれらの資源は実はクライアントのどこかにあります.クライアントは直接に現地からこれらの資源をロードすればいいです.ネットを使わないでください.スピードはもちろん速いです.
参考記事:

HTTP 1.0、HTTP 1.1、HTTPSとHTTP 2.0の違い

文章を読んでHTTP/2の特性を読みます。

ps:個人技術ブログGithub倉庫、いいと思ったら、スターを歓迎してください.書いてください.