バックエンド
パフォーマンスと効率：HTTP / 3での作業
HTTP / 3は、HTTP / 2に続いて注目を集めており、それ自体はまだ非常に若いと言えます。 HTTP /1.1からHTTP / 2に移行するのに16年かかったことを考えると、誰かが本当にHTTP / 3に関心を持つべきでしょうか？
簡単な答え：はい、それは重要です。あなたはそれに慣れる必要があります。これは、HTTP / 2がASCIIからバイナリに切り替えることでHTTP / 1.1から大幅な変更を加えたのと同じです。 HTTP / 3は、基盤となるトランスポートをTCPからUDPに切り替えることにより、大幅な変更を加えます。
HTTP / 3はまだ設計段階にあり、公式仕様はドラフトですが、すでに展開されており、今日ネットワーク上で実行されているバージョンが見つかる可能性があります。
しかし、HTTP / 3がどのように機能するかによってもたらされるいくつかの新しいジレンマがあります。また、どのようなメリットがありますか？そして、ネットワークエンジニア、システム管理者、および開発者は何を知る必要がありますか？
TL; DR
- より速いウェブサイトはより成功します。
- HTTP / 2は、 HTTPヘッドオブラインブロッキング問題（HOL） 。紹介します 要求/応答の多重化、バイナリフレーミング、ヘッダー圧縮、ストリームの優先順位付け、 そして サーバープッシュ 。
- HTTP / 3は、HTTP / 2のすべてを組み込み、 TCP HOLブロッキングの問題もあります。 HTTP / 3はまだドラフトですが、すでにデプロイされています。です もっと効率的な 、 より少ないリソースを使用します （システムとネットワーク）、 暗号化が必要 （SSL証明書は必須です）、および UDPを使用します 。
- Webブラウザはしばらくの間古いバージョンのHTTPをサポートし続ける可能性がありますが、パフォーマンス上の利点と検索エンジンによるHTTP / 3に精通したサイトの優先順位付けにより、新しいプロトコルの採用が促進されるはずです。
- SPDYは廃止されており、SPDYを使用する場合はHTTP / 2に置き換える必要があります。
- 今日のサイトはすでにHTTP / 1.1とHTTP / 2の両方をサポートしているはずです。
- 近い将来、サイトの所有者はおそらくHTTP / 3もサポートしたいと思うでしょう。ただし、HTTP / 2よりも物議を醸しているため、大規模なネットワークの多くは、時間をかけて処理するのではなく、単にブロックしているだけです。
主な問題：パフォーマンスと効率
サイトおよびアプリの開発者は通常、自分の作品が実際に使用されることを意図して構築します。オーディエンスベースが有限である場合もありますが、多くの場合、アイデアはできるだけ多くのユーザーを獲得することです。当然のことながら、ウェブサイトの人気が高まるほど、より多くの収益を上げることができます。
ウェブサイトの読み込み時間が100ミリ秒遅れると、コンバージョン率が7％低下する可能性があります。
Akamai Online Retail Performance Report：Milliseconds Are Critical（2017）
言い換えれば、1日あたり40,000ドルの売り上げがあるeコマースサイトは、そのような遅れのために年間100万ドルを失うことになります。
また、サイトの人気が高まるには、サイトのパフォーマンスが絶対的に重要であることも周知の事実です。オンラインショッピング調査 リンクを探し続けます の間に 直帰率の増加と読み込み時間の延長 、および ショッピング体験中の買い物客の忠誠心とウェブサイトのパフォーマンス 。
研究 また、 ：
- 消費者の47％は、Webページが2秒以内に読み込まれることを期待しています。
- 40％の人が、読み込みに3秒以上かかるWebサイトを放棄しています。
そして、それは現在のオンライン買い物客の忍耐の状態でした 10年以上前 。したがって、パフォーマンスは重要であり、HTTP / 2とHTTP / 3はどちらもWebサイトのパフォーマンスが向上することを意味します。
HTTP / 2？ …あれは何でしょう？
HTTP / 3を理解するには、HTTP / 2プロトコルをよく理解することが重要です。まず第一に、なぜHTTP / 2が必要だったのですか？
HTTP / 2は、SPDYと呼ばれるGoogleプロジェクトとして始まりました。これは、ウェブ上で最大のパフォーマンスの問題が レイテンシー 。著者は、「帯域幅を増やしても（それほど）重要ではない」と結論付けました。
配管とインターネットを類推すると、 帯域幅 水道管の直径のようにインターネットの。パイプが大きいほど大量の水が運ばれるため、2点間でより多くの水を送ることができます。
同時に、パイプの大きさに関係なく、パイプが空で、ある場所から別の場所に水を行きたい場合は、水がパイプを通過するのに時間がかかります。インターネット用語では、水がパイプの一方の端からもう一方の端に移動し、再び戻るのにかかる時間は、 往復時間 、または RTT 。
マイク・ベルシュ
この調査では、ページの読み込み時間を短縮することが目標でした。 1Mbpsから2Mbpsに移行するとページの読み込み時間が半分になるため、最初は帯域幅を増やすことが役立つことが示されました。ただし、メリットはすぐに頭打ちになります。
対照的に、遅延を減らすことには一定の利点があり、最良の結果が得られます。
HTTP HOL：ヘッドオブラインブロッキングの問題
HTTP / 1プロトコル内の遅延の主な原因は、 ヘッドオブラインブロッキング 問題。 Webページ（ほとんどの場合）には、CSS、JavaScript、フォント、画像、AJAX / XMRなどの複数のリソースが必要です。これは、Webブラウザーがサーバーに対して複数の要求を行う必要があることを意味します。ただし、ページが役立つようになるためにすべてのリソースが必要なわけではありません。
HTTP / 1.0では、次のリクエストを開始する前に、ブラウザがレスポンスを完全に受信するなど、リクエストを完全に完了する必要がありました。すべてを順番に行う必要がありました。各リクエストはリクエストの行をブロックするため、名前が付けられます。
HOLブロッキングの問題を補うために、Webブラウザは単一のサーバーに複数の同時接続を行います。ただし、この動作を任意に制限する必要がありました。サーバー、ワークステーション、およびネットワークは、接続が多すぎると過負荷になる可能性があります。
HTTP / 1.1では、この問題への取り組みに役立ついくつかの改善が導入されました。主なものは パイプライン 、以前のリクエストが完了するのを待たずに、Webブラウザが新しいリクエストを開始できるようにします。これにより、低レイテンシ環境での読み込み時間が大幅に改善されました。
ただし、それでもすべての応答が作成された順序で順番に到着する必要があるため、行の先頭はブロックされたままです。驚いたことに、多くのサーバーはまだこの機能を利用していません。
ランディングページデザインのベストプラクティス
興味深いことに、HTTP /1.1も導入されました 生き続ける 、これにより、ブラウザはHTTPリクエストごとに新しいTCP接続を作成するオーバーヘッドを回避できました。これは、TCPから派生したパフォーマンスの問題を解決するための初期の試みでした。それは非常に効果がなかったので、ほとんどのパフォーマンスの専門家は、非アクティブな接続が多すぎるとサーバーをダウンさせるため、実際にはそれを思いとどまらせます。以下のTCPと、この問題がHTTP / 2によってどのように修正されたかを詳しく見ていきます。
HTTP / 2のHTTPHOLブロッキングソリューション
HTTP / 2が導入されました 要求と応答の多重化 単一の接続を介して。ブラウザはいつでも新しいリクエストを開始できるだけでなく、 応答は任意の順序で受信できます -ブロッキングは、アプリケーションレベルで完全に排除されます。
直接的な結果として、これはHTTP / 2に精通したWebサーバーが効率を最大化できることを意味します。これについては後で詳しく説明します。
要求と応答の多重化はHTTP / 2のヘッドライン機能ですが、他にもいくつかの重要な機能が含まれています。読者は、それらがすべていくらか関連していることに気付くかもしれません。
HTTP / 2バイナリフレーミング
HTTP / 2は、HTTPプロトコル標準を非効率的な人間が読めるASCII要求/応答モデルから効率的なものに切り替えます バイナリフレーミング 。もはや単なるリクエストとレスポンスではありません。
HTTP / 2を使用すると、ブラウザは、それぞれが複数のフレームで構成される複数のメッセージを含む双方向ストリームを介してサーバーと通信します。
HTTP / 2 HPACK（ヘッダー圧縮）
HTTP / 2の新しい ヘッダー圧縮 、HPACK形式を使用すると、ほとんどのサイトで大量の帯域幅を節約できます。これは、接続内で送信されるリクエストのヘッダーの大部分が同じであるためです。
Cloudflareは大幅な帯域幅の節約を報告します HPACKだけのおかげで ：
- 入力ヘッダーの76％圧縮
- 総入力トラフィックが53％削減
- 出力ヘッダーの69％圧縮
- 総出力トラフィックが1.4％から15％削減
もちろん、使用する帯域幅が少ないということは、一般的にWebサイトが高速であることを意味します。
HTTP / 2ストリームの優先順位付けとサーバープッシュ
ここで、HTTP / 2の多重化によってサーバーの効率を最大化できます。多重化は、遅いリソース（大きな画像、データベースで生成されたJSONなど）よりも速いリソース（メモリキャッシュされたJavaScriptなど）を提供するのに役立ちます。ただし、HTTP / 2を介してパフォーマンスをさらに向上させることもできます。 ストリームの優先順位付け 。
ストリームの優先順位付けは、他のリソースを大量に消費する要求が終了するのを待たずに、ページのほぼ準備が整った側面を完全に完了するのに役立ちます。これは、加重依存関係ツリーを介して実現されます。このツリーは、サーバーがサービスに最も多くのシステムリソースを割り当てる必要がある応答をサーバーに通知するために使用されます。
これは特に重要です プログレッシブウェブアプリケーション（PWA） 。たとえば、ページに4つのJavaScriptファイルがあるとします。 2つはページ機能用で、2つは広告用です。最悪のシナリオは、残りのJSをロードする前に、機能JSの半分とアドバタイズJSの半分をロードしてから大きな画像をロードすることです。その場合、すべてが最も遅いリソースを待機する必要があるため、ページ上の何も最初は機能しません。
ストリームの優先順位付けを使用すると、Webブラウザーは、広告JavaScriptファイルを送信する前に、両方のページ機能JSファイルを送信するようにサーバーに指示できます。これにより、ユーザーはページの機能を使用する前に、広告が完全に読み込まれるのを待つ必要がなくなります。全体的な読み込み時間は改善されていませんが、知覚されるパフォーマンスは大幅に向上しています。残念ながら、Webブラウザー内でのこの動作は、によって指定されたものではなく、依然としてほとんどの場合アルゴリズムの問題です。 Web開発者 。
メモリリークをチェックする方法
同じ方針に沿って、HTTP / 2は サーバープッシュ この機能を使用すると、サーバーはまだ行っていないリクエストに対してブラウザに応答を送信できます。サーバーは、送信のギャップを利用して、サーバーがすぐに要求することをサーバーが認識しているブラウザーリソースにプリロードすることにより、帯域幅を効率的に使用できます。ここでの希望の一部は、リソースを膨らませてロードに時間がかかるだけのリソースインライン化の慣行を排除することです。
残念ながら、これらの機能は両方とも、実際に成功するためにWeb開発者による多くの注意深い構成を必要とします。それらを有効にするだけです 十分ではありません 。
HTTP / 2は明らかに多くの潜在的な利点をもたらします。それらのいくつかは、他のものよりも活用するのに安価です。彼らは現実の世界でどのように進んでいますか？
HTTPとHTTP / 2の採用
SPDYは2009年に作成されました。HTTP/ 2は2015年に標準化されました。SPDYはコードの不安定な開発ブランチの名前になり、HTTP / 2が最終バージョンになりました。その結果、SPDYは時代遅れになり、HTTP / 2は一般的に誰もが従う標準です。
標準化後、HTTP / 2（または「h2」）の採用は急速に成長し、上位1,000のWebサイトの約40％になりました。これは主に、顧客に代わってサポートを展開している大規模なホスティングおよびクラウドプロバイダーによって推進されました。残念ながら、数年後、HTTP / 2の採用は遅くなり、インターネットの大部分はまだHTTP / 1を使用しています。
HTTP / 2クリアテキストモードのブラウザサポートの欠如
暗号化を標準の必須部分にするために、HTTP / 2に対する多くの要求がありました。代わりに、標準では暗号化（h2）モードとクリアテキスト（h2c）モードの両方が定義されています。そのため、HTTP / 2はHTTP / 1を完全に置き換えることができます。
標準にもかかわらず、現在のすべてのWebブラウザーは、暗号化された接続を介したHTTP / 2のみをサポートしており、意図的にクリアテキストモードを実装していません。代わりに、ブラウザはHTTP / 1下位互換モードに依存して安全でないサーバーにアクセスします。これは、デフォルトでWebを安全にするというイデオロギー的な推進の直接的な結果です。
なぜHTTP / 3なのか？そしてそれはどのように違うのですか？
HTTP / 2によって修正されたHTTPヘッドオブラインブロッキングの問題により、プロトコル開発者は次に大きなレイテンシードライバーに注意を向けました。 TCP ヘッドオブラインブロッキングの問題。
伝送制御プロトコル（TCP）
IP（インターネットプロトコル）ネットワークは、コンピューターが相互にパケットを送信するという考えに基づいています。パケットは、いくつかのアドレス情報が上部に添付された単なるデータです。
しかし、アプリケーションは通常、対処する必要があります ストリーム データの。達成するために この幻想 、伝送制御プロトコル（TCP）は、アプリケーションに パイプ データのストリームが流れることができます。ほとんどのパイプと同様に、データがパイプに入るのと同じ順序でパイプから出ることが保証されています。これは「先入れ先出し」（FIFO）とも呼ばれます。これらの特性により、TCPは非常に便利になり、非常に広く採用されています。
TCPが提供するデータ配信保証の一部として、TCPはさまざまな状況を処理できる必要があります。最も複雑な問題の1つは、ネットワークが過負荷になったときに、すべての人にとって状況を悪化させることなく、すべてのデータを配信する方法です。このためのアルゴリズムはと呼ばれます 輻輳制御 そして、インターネット仕様の絶えず進化している部分です。十分でない 輻輳制御 、インターネットは停止します。
'86年10月、インターネットは一連の「混雑崩壊」となった最初のものを持っていました。この期間中に、LBLからUCバークレー校（400ヤードと3つのIMPホップで分離されたサイト）へのデータスループットは、32Kbpsから40bpsに低下しました。
V.ジェイコブソン（1988）
そこで、TCPヘッドオブラインブロッキングの問題が発生します。
TCPHOLブロッキングの問題
TCP輻輳制御は、 バックオフ そして 再送信 パケットのメカニズム。パケット損失が検出されるたびに使用されます。バックオフは、ネットワークを落ち着かせるのに役立つことを目的としています。再送信により、データが最終的に確実に配信されます。
これは、TCPデータが順不同で宛先に到着する可能性があることを意味し、パケットをストリームに再アセンブルする前に、パケットを再順序付けするのは受信側の責任です。残念ながら、これは、単一の失われたパケットにより、サーバーが再送信を待機している間、TCPストリーム全体が一時停止する可能性があることを意味します。したがって、行の先頭がブロックされます。
この問題を解決することを目的としたGoogleの別のプロジェクト QUICと呼ばれるプロトコルの導入 。
QUICプロトコルはTCPではなくUDPの上に構築されており、QUICはHTTP / 3の基盤を形成しています。
UDPとは何ですか？
ユーザーデータグラムプロトコル（UDP）は、TCPの代替手段です。ストリームのような錯覚や、TCPが提供するのと同じ保証は提供されません。代わりに、データをパケットに入れ、別のコンピューターにアドレス指定して送信する簡単な方法を提供するだけです。です 信頼できない 、 注文なし 、および ない あらゆる形式の輻輳制御が付属しています。
その目的は、軽量であり、通信を可能にするために必要な最小限の機能を提供することです。このようにして、アプリケーションは独自の保証を実装できます。これは、多くの場合、リアルタイムアプリケーションで非常に役立ちます。たとえば、電話では、ユーザーは通常、データの100％を最終的に受け取るのではなく、データの90％をすぐに受け取ることを好みます。
HTTP / 3のTCPHOLソリューション
TCP HOLブロッキングの問題を解決するには、UDPに切り替えるだけでなく、すべてのデータの配信を保証し、ネットワークの輻輳が崩壊しないようにする必要があります。 QUICプロトコルは、最適化されたHTTP over UDPタイプのエクスペリエンスを提供することにより、これらすべてを実行するように設計されています。
QUICがストリーム管理、バイナリフレーミングなどの制御を引き継ぐため、QUIC上で実行するときにHTTP / 2が実行することはあまりありません。これは、HTTP / 3として標準化されているQUIC + HTTPのこの新しい組み合わせに向けた推進要因の一部です。
注：プロトコルは開発中であり、実稼働環境で何年も展開されているため、QUICには多くのバージョンがあります。 GQUICと呼ばれるGoogle固有のバージョンもあります。そのため、古いQUICプロトコルと新しいHTTP / 3標準を区別することが重要です。
常に暗号化
HTTP / 3には、TLSを多用しているが、直接使用していない暗号化が含まれています。 HTTP / 3の主な実装上の課題の1つは、新たに必要な機能を追加するためにTLS / SSLライブラリを変更する必要があることです。
この変更は、HTTP / 3が暗号化の点でHTTPSと異なるためです。古いHTTPSプロトコルでは、データ自体のみがTLSによって保護され、多くのトランスポートメタデータが表示されたままになります。 HTTP / 3では、データとトランスポートプロトコルの両方が保護されます。これはセキュリティ機能のように聞こえるかもしれませんが、そうです。ただし、HTTP / 2に存在する多くのオーバーヘッドを回避するために、この方法で行われます。したがって、トランスポートプロトコルとデータを暗号化すると、実際にはプロトコルのパフォーマンスが向上します。
ネットワークインフラストラクチャに対するHTTP / 3の影響
HTTP / 3には論争がないわけではありません。主な懸念事項は、ネットワークインフラストラクチャに関するものです。
クライアント側のHTTP / 3
クライアント側では、UDPトラフィックが大幅にレート制限されたりブロックされたりすることがよくあります。これらの制限をHTTP / 3に適用すると、プロトコルのポイントが無効になります。
次に、HTTPが監視または傍受されることは非常に一般的です。 HTTPSトラフィックがある場合でも、ネットワークはプロトコルのクリアテキストトランスポート要素を定期的に監視して、特定のネットワークまたは特定の地域内から特定のWebサイトへのアクセスを防止する目的で接続を切断する必要があるかどうかを判断します。一部の国では、これは特定のサービスプロバイダーに対して法律で義務付けられています。 HTTP / 3での必須の暗号化により、これは不可能になります。
不和ボットとは
政府レベルのフィルタリングだけではありません。多くの大学、公立図書館、学校、および親が心配している家庭は、特定のWebサイトへのアクセスをブロックするか、少なくともどのサイトにアクセスしたかをログに記録することを積極的に選択しています。 HTTP / 3での必須の暗号化により、これは不可能になります。
フィルタリングが制限されていることは注目に値します です 現在可能です。これは、サーバー名表示（SNI）フィールド（Webサイトのホスト名は保持されますが、パス、クエリパラメーターなどは保持されない）がまだ暗号化されていないためです。しかし、これは、最近TLS標準に追加されたESNI（暗号化されたSNI）の導入により、近い将来変更される予定です。
サーバー側のHTTP / 3
サーバー側では、トラフィックを予期していないポートとプロトコルをブロックすることをお勧めします。つまり、サーバー管理者は、既存のTCP 443ルールに依存するのではなく、HTTP / 3用のUDP443を開く必要があります。
第二に、ネットワークインフラストラクチャはTCPセッションを作成できます ねばねば 、つまり、ルーティングの優先順位が変更されても、常に同じサーバーにルーティングされます。 HTTP / 3はセッションレスであるUDP上で実行されるため、ネットワークインフラストラクチャを更新してHTTP / 3固有の接続IDを追跡する必要があります。これは、スティッキールーティングを支援するために特に暗号化されていないままです。
第三に、HTTPを検査して不正使用を検出し、監視することは非常に一般的です。 一般的なセキュリティの問題 、マルウェアやウイルスなどの拡散を検出して防止します。これは、暗号化されているため、HTTP / 3では不可能です。それでも、デバイスがHTTP / 3サポートを実装していると仮定すると、傍受するデバイスにセキュリティキーのコピーがあるオプションは引き続き可能です。
最後に、多くの管理者は、さらに多くのSSL証明書を管理する必要があることに反対していますが、次のようなサービスではそれほど問題にはなりません。 暗号化しましょう 利用可能です。
これらの懸念に対処するための広く受け入れられているよく知られたソリューションが存在するまでは、多くの大規模なネットワークが単にHTTP / 3をブロックする可能性が高いと思います。
HTTP / 3のWeb開発への影響
この面で心配することはあまりありません。 HTTP / 2のストリームの優先順位付けとサーバープッシュ機能は引き続きHTTP / 3に存在します。 Web開発者にとってそれは価値があります これらの機能に慣れてください サイトのパフォーマンスを本当に最適化したい場合。
今すぐHTTP / 3を使用する
Google ChromeまたはオープンソースのChromiumブラウザのユーザーは、HTTP / 3を使用するようにすでに設定されています。 HTTP / 3サーバーの本番品質のリリースはまだ少し離れています— 仕様 この記事の執筆時点では、まだ完全には完成していません。しかしその間、遊ぶためのツールはたくさんあり、GoogleとCloudflareの両方がすでに本番環境へのサポートをプッシュしています。
それを試す最も簡単な方法は、 キャディー に Docker 。これにはSSL証明書が必要なので、公的にアクセス可能なIPアドレスを使用すると作業が簡単になります。手順は次のとおりです。
- DNSの設定。 インターネット上で公開されている有効なホスト名を取得します。
yourhostname.example.com IN A 192.0.2.1。 - キャディファイルの作成。 次の行が含まれている必要があります。
yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected] - キャディの実行：
docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic—または Dockerの外部 、caddy --quic。 - QUICを有効にしてクロムを実行する：
chromium --enable-quic - （オプション） インストール プロトコルインジケータ拡張 。
- QUIC対応サーバーへのナビゲート 、ファイルブラウザが表示される場所。
開発者は、次の便利なツールを使用してサーバーをテストすることもできます。
- Keycdnの HTTP / 2テスト
- LiteSpeedの HTTP3Check
- クオリス SSLサーバーテスト
読んでくれてありがとう！
基本を理解する
HTTP / 2はどのように機能しますか？
HTTP / 2は、Webコンテンツの配信に必要な時間を最適化するために、効率的な帯域幅の使用に重点を置いています。要求と応答は単一の接続を介して多重化され、最大のスループットを可能にします。クライアントもサーバーも、お互いを待つために不必要に時間を費やす必要はありません。
HTTPの機能は何ですか？
HTTPは、コンテンツをグローバルに利用できるようにするための一連のルールです。 HTTPによって作成されたシステムは、ワールドワイドウェブまたは単にWebと呼ばれます。 HTTPを使用すると、WebブラウザはWebサーバーからコンテンツを取得できます。現在では、他のサーバーとコンテンツを交換するためにサーバーでも一般的に使用されています。
HTTPとHTTP / 2の違いは何ですか？
HTTP / 2は、より少ない帯域幅を使用し、データ転送を高速化する新機能を導入することにより、古いHTTPバージョンを改善します。機能に関するプロトコル間の主な違いは、パフォーマンスです。技術設計に関しては、プロトコルは互いにほとんど類似しておらず、元の抽象的な概念のみを共有しています。
HTTPプロトコルの目的は何ですか？
ハイパーテキスト転送プロトコル（HTTP）を使用すると、Webを介してグローバル規模でコンテンツを公開できます。他にも多くの重要な用途がありますが、HTTPを多用途で人気のあるツールにしたのは、このグローバルな範囲と一般的な目的です。
HTTPプロトコルとはどのようなスキームですか？
ユニフォームリソースロケーター（URL）では、スキームはコロンの前の部分であり、読者がURLの残りの部分を解釈する方法を知ることができます。 Webアドレスの場合、これはHTTPまたはHTTPSのいずれかです。 HTTPSは、HTTPプロトコル標準の安全な暗号化されたバリアントです。
TCPプロトコルは何に使用されますか？
TCPは、インターネット上の2つのデバイス間で双方向の先入れ先出し（FIFO）ストリームを確立するために使用されます。このストリームを介して、すべてのデータが確実に通過できます。そのため、TCPは、Web（HTTP、HTTPS、およびHTTP / 2）や電子メール（SMTP、POP、およびIMAP）のプロトコルを含む、他の多くのプロトコルの構成要素です。
TCPとは何ですか？どのように機能しますか？
TCP（TCP / IPと呼ばれることもあります）は、インターネットのインフラストラクチャのほとんどが非常に信頼性が低く、ステートレスであるにもかかわらず、インターネット上のデバイスが信頼できる方法で相互に通信できるようにする抽象化メカニズムです。 TCPは、ステートフルセッションと輻輳制御を実装することによって機能します。
HTTP / 2で行頭ブロッキングを引き起こす原因は何ですか？
HTTP / 2はTCPを使用して、信頼できる接続が保証されていることを確認します。 TCPでは、受信者は、受信したデータを並べ替え、前のデータを解放した後にのみ最新のデータを解放することによって、失われたデータの再送信されたコピーを処理します。この待機により、回線の先頭がブロックされ、パフォーマンスが低下します。
HTTPの最新バージョンは何ですか？
HTTP / 3はHTTPの最新バージョンです。まだ正式にはリリースされていませんが、HTTP / 3はすでに広く展開されています。以前のバージョンのHTTPは、2015（HTTP / 2）、1999（HTTP / 1.1）、1997（HTTP / 1.0）、および1989（HTTP / 0.9）にリリースされました。
