多重化は、複数のリクエストやレスポンスのメッセージを同時に転送することを可能にし、このような問題に取り組みます。転送中に別のメッセージの一部が混在することも可能になります。同様に、クライアントはページを読み込むために、オリジンごとに1個の接続だけを使用すればよいことになります。個の接続を使用しています。個を超える接続を使用することになります。設計上の多くの前提を崩しているのです。各接続において応答データが一挙に流れ出すと、途中経路上のネットワークのバッファーが溢れ、輻輳が発生しパケット再送が起こる危険性があります。いることになるのです。解析し、それらのリクエストを送信するまで待たなければなりません。することでラウンドトリップを回避します。平均ページロード時間におけるヘッダーの影響度を計算し、ヘッダー圧縮の必要性を強く示してくれました。ラウンドトリップが必要です。これは応答時間を含めていないことに注意してください。クライアントからヘッダーを送出する時だけでこれほど必要なのです。メカニズムが原因なのです。このメカニズムは、確認応答が得られたパケットの数を元にパケット送信のペースを調整するのです。これにより、新しい接続の最初の数ラウンドトリップにおいて送信できるパケットの数は実質的に制限されることになります。これに対し、比較的緩い圧縮であってもヘッダーに施せば、これらリクエストを一つのラウンドトリップで送出できます。うまく行けばひとつのパケットに収めることができます。オーバーヘッドは大きいものです。良いコンディションにおいてもラウンドトリップの遅延が数百ミリ秒に達するのが普通であるモバイルクライアントにおいては特にそうです。コンテキストを使用することを提案しました。これは実装が簡単なだけでなく、効率的でした。ストリーム圧縮の使用に対する大規模な攻撃手法が報告されました。"探り出し"、それを復元することができます。使用してクッキーや認証トークンを復元するデモも存在します。圧縮を使用できませんでした。ユースケースに適しているだけでなく、安全に使用できる他のアルゴリズムは見つかりません。そこで、我々は新たに粒度の粗いヘッダー向けの圧縮方式を開発しました。ヘッダーはメッセージ間で変更されないため、この新しい圧縮方式は合理的な圧縮効率をもたらし、より安全であるといえます。ヘッダーやメソッドといった転送プロトコルの改訂作業に注力しました。広く使われていることがその理由です。非互換になってしまうことを意味します。変換し、情報を失うことなくそれを元に戻せることを目指しています。多くに互換性の問題が生じることになります。これは、単に新しいプロトコルの採用に対する対立が生むことになります。全てに対する責任があります。下位互換でさえあれば、バージョンに依存する新しい機構に取り組むことができます。使用することができると考えています。おいて良い性能特性を持つことが示されました。リクエストのオーバーヘッドを考慮する必要がなくなるからです。いいつつも、やはり主となる性能向上はブラウザーによるユースケースであると我々は考えています。それこそがこのプロトコルの基本的なユースケースであるからです。デプロイメントについてこれらの目標を達成する予定です。は新しいプロトコルにおいてサポートされるべきです。最終的な仕様はこれらの使用を無効にする可能性があります。暗号化が必須なのですか?いいえ。必須にすることについてコンセンサスを得ることができませんでした。暗号化された通信路上でのみサポートすると発言しています。プロファイルを定義しています。Suite、使用する拡張が含まれています。詳しくは仕様を参照してください。ついての議論もあります。最新版でサポートされています。サポートするでしょう。サポートする予定があることを告知しています。提供されており、デプロイしてのテストが可能なオープンソースの実装も多数あります。詳しくは実装リストを参照してください。使用でき、その成果を見ることがワーキンググループの目標です。言うものの、我々は、人々がプロキシーやサーバーをデプロイする方法や、世界に対して移行を強制することはできません。間使用される可能性は高いと言えます。新しいバージョンをサポートすることが可能になるはずです。超える可能性があり、その場合一つのフレームに収めることができないからです。実装の上で最も間違いが少ないような解決方法を模索したところ、全ヘッダーデータが連続したフレームで送信されなければならないというルールに落ち着きました。これはデコード時のバッファー管理も容易になるというメリットもあります。使用するメモリ量を常に制御します。