最近、 IETF （インターネット技術特別調査委員会）は、インターネットのプロトコルとアーキテクチャを開発し、 それを知らせた そのニュース HTTP/3.0プロトコルのRFCの形成を完了しました 識別子RFC9114およびRFC9204の下で関連する仕様を公開しました。
HTTP/3.0仕様 「提案された標準」ステータスを受け取り、 その後、作業はRFCにドラフト標準（ドラフト標準）のステータスを与え始めます。これは、実際にはプロトコルの完全な安定化を意味し、行われたすべてのコメントを考慮に入れます。
プロトコル HTTP / 3は、QUICプロトコルの使用を定義します （Quick UDPインターネット接続） HTTP/2のトランスポートとして。 QUICは、複数の接続の多重化をサポートし、TLS/SSLと同等の暗号化方式を提供するUDPプロトコルへのプラグインです。
プロトコルは2013年にGoogleによって作成されました Web用のTCP+TLSの代替として、TCPでの長い接続セットアップとネゴシエーション時間の問題を解決し、データ転送中のパケット損失による遅延を排除します。
現在のところ、 QUICとHTTP/3.0のサポートはすでにすべてのブラウザに実装されています 人気のあるウェブサイト。 サーバー側では、HTTP / 3の実装は、nginx（別のブランチで、別のモジュールとして）、Caddy、IIS、およびLiteSpeedで使用できます。 HTTP / 3は、Cloudflareのコンテンツ配信ネットワークでもサポートされています。
QUICの主な機能：
- TLSと同様の高度なセキュリティ（実際、QUICはTLS over UDPを使用する機能を提供します）
- パケット損失を防ぐための伝送整合性制御
- 接続を即座に確立し、要求の送信と応答の受信の間の遅延を最小限に抑える機能（RTT、ラウンドトリップ時間）
- パケットを再送信するときに別のシーケンス番号を使用して、受信したパケットを判別する際のあいまいさを回避し、タイムアウトを取り除くことができます
- パケットを失うと、それに関連付けられたストリームのみの配信に影響し、現在の接続を介して並行して送信されるストリームでのデータの配信を停止しません。
- 失われたパケットの再送信による遅延を最小限に抑えるエラー訂正ツール。 失われたパケットデータの再送信を必要とする状況を減らすための特別なパケットレベルのエラー訂正コードの使用。
- 暗号化ブロックの境界はQUICパケットの境界と一致し、後続のパケットのコンテンツのデコードに対するパケット損失の影響を軽減します
- TCPキューのブロックに問題はありません
- モバイルクライアントの再接続時間を短縮するための接続識別サポート
- 接続過負荷制御のための高度なメカニズムを接続する可能性
- 各方向で帯域幅予測技術を使用して、最適なパケット転送速度を確保し、パケットが失われる輻輳状態を回避します。
- TCPを超える顕著なパフォーマンスとパフォーマンスの向上。 YouTubeのようなビデオサービスの場合、QUICはビデオバッファリング操作を30％削減することが示されています。
これに加えて、同時に、HTTP / 1.1（RFC 9112）およびHTTP / 2.0（RFC 9113）プロトコルの仕様の更新バージョン、およびHTTP要求（RFC）のセマンティクスを定義するドキュメントが公開されました。 9110）およびHTTPキャッシング制御ヘッダー（RFC 9111）。
の変更点 仕様 HTTP / 1.1、あなたは禁止に気付くことができます キャリッジリターン文字の個別使用から （CR）内容のある体外つまり、プロトコル要素では、CR文字は改行文字（CRLF）と一緒にのみ使用できます。
El チャンクリクエストレイアウトアルゴリズムが改善されました 添付されたフィールドとヘッダー付きのセクションの分離を簡素化するため。 フロントエンドとバックエンドの間のフローで他のユーザーのリクエストのコンテンツに侵入する可能性のある「HTTPリクエストスマグリング」クラスの攻撃をブロックするために、あいまいなコンテンツを処理するためのガイドラインを追加しました。
仕様の更新 HTTP / 2.0は、TLS1.3のサポートを明示的に定義しています。 非推奨の優先順位付けスキームと関連するヘッダーフィールドおよび更新メカニズム 非推奨のHTTP/1.1接続は非推奨になりました。
最後に、あなたがそれについてもっと知ることができることに興味があるなら、あなたはの詳細を調べることができます 次のリンク。