プロホスト > ブログ > インターネットニュース > HTTP/3.0 は提案された標準ステータスを受け取りました

HTTP/3.0 は提案された標準ステータスを受け取りました

インターネット プロトコルとアーキテクチャの開発を担当する IETF (インターネット エンジニアリング タスク フォース) は、HTTP/3.0 プロトコルの RFC の作成を完了し、RFC 9114 (プロトコル) および RFC 9204 ( HTTP/3 用の QPACK ヘッダー圧縮テクノロジー)。 HTTP/3.0 仕様は「標準案」のステータスを取得しました。その後、RFC に標準草案 (標準草案) のステータスを与える作業が開始されます。これは、実際にはプロトコルの完全な安定化を意味し、すべての要素を考慮します。されたコメント。 同時に、HTTP/1.1 (RFC 9112) および HTTP/2.0 (RFC 9113) プロトコルの仕様の更新版が公開されたほか、HTTP リクエスト (RFC 9110) および HTTP キャッシュ制御ヘッダーのセマンティクスを定義する文書も公開されました。 (RFC 9111)。

HTTP/3 プロトコルは、HTTP/2 のトランスポートとして QUIC (Quick UDP Internet Connections) プロトコルの使用を定義します。 QUIC は、複数の接続の多重化をサポートし、TLS/SSL と同等の暗号化方式を提供する UDP プロトコルの拡張です。 このプロトコルは、Web 用の TCP + TLS の組み合わせの代替として 2013 年に Google によって作成され、TCP での長い接続セットアップとネゴシエーション時間の問題を解決し、データ転送中にパケットが失われた場合の遅延を解消します。

HTTP/3.0 は提案された標準ステータスを受け取りました

現在、QUIC および HTTP/3.0 のサポートは、すべての一般的な Web ブラウザにすでに実装されています (Chrome、Firefox、Edge では、HTTP/3 サポートがデフォルトで有効になっており、Safari では、「詳細設定 > 実験的機能 > HTTP/3」設定が必要です)有効にする必要があります)。 サーバー側では、HTTP/3 実装は nginx (別のブランチおよび別のモジュールの形式で)、Caddy、IIS、および LiteSpeed で利用できます。 HTTP/3 サポートは、Cloudflare コンテンツ配信ネットワークによっても提供されます。

QUIC の主な機能:

  • TLS と同様の高いセキュリティ (基本的に QUIC は UDP 上で TLS を使用する機能を提供します)。
  • フロー整合性制御によりパケット損失を防止します。
  • 接続を即座に確立し (0-RTT、約 75% の場合、接続セットアップ パケットの送信直後にデータを送信できます)、要求の送信と応答の受信の間の遅延 (RTT、往復時間) を最小限に抑える機能;
    HTTP/3.0 は提案された標準ステータスを受け取りました
  • パケットを再送信するときに別のシーケンス番号を使用します。これにより、受信パケットを識別する際のあいまいさが回避され、タイムアウトがなくなります。
  • パケットの損失は、それに関連付けられたストリームの配信にのみ影響し、現在の接続を通じて送信される並列ストリームでのデータの配信は停止しません。
  • 失われたパケットの再送信による遅延を最小限に抑えるエラー修正機能。 パケットレベルで特別なエラー訂正コードを使用して、失われたパケットデータの再送信が必要な状況を軽減します。
  • 暗号化ブロックの境界は QUIC パケットの境界と一致しているため、後続のパケットの内容のデコードにおけるパケット損失の影響が軽減されます。
  • TCP キューのブロックには問題はありません。
  • 接続識別子のサポート。モバイル クライアントの再接続の確立にかかる時間を短縮します。
  • 高度な接続輻輳制御メカニズムを接続する可能性。
  • 方向ごとのスループット予測技術を使用して、パケットが最適なレートで送信されるようにし、パケットの輻輳やパケット損失の発生を防ぎます。
  • TCP と比較してパフォーマンスとスループットが大幅に向上します。 YouTube などのビデオ サービスの場合、QUIC はビデオ視聴時の再バッファリング操作を 30% 削減することが示されています。

HTTP/1.1 仕様の変更点の中で、コンテンツの本文の外側でキャリッジ リターン (CR) 文字を単独で使用することの禁止に注目することができます。 プロトコル要素では、CR 文字は改行文字 (CRLF) と組み合わせてのみ使用できます。 チャンク化されたリクエストのレイアウト アルゴリズムが改善され、添付されたフィールドとヘッダーのあるセクションの分離が簡素化されました。 「HTTP リクエスト密輸」攻撃をブロックするために、あいまいなコンテンツを処理するための推奨事項を追加しました。これにより、フロントエンドとバックエンドの間のフローで他のユーザーのリクエストのコンテンツに介入できるようになります。

HTTP/2.0 仕様の更新では、TLS 1.3 のサポートが明示的に定義されています。 優先順位付けスキームと関連するヘッダー フィールドは非推奨になりました。 HTTP/1.1 との接続を更新するための未使用のメカニズムは廃止されたと宣言されました。 フィールド名と値をチェックするための要件が​​軽減されました。 以前に予約されたいくつかのフレーム タイプとパラメータの使用が提案されています。 接続に関連する禁止されたヘッダー フィールドがより正確に定義されます。

出所： オープンネット.ru

コメントを追加します