Velocity 2010カンファレンスで、Googleは、ヘッダー圧縮によって大きな利益が得られると述べました。
Hölzleは、ユーザーのIPアドレス、ブラウザー、およびその他のセッションデータに関する情報を提供するWebページヘッダーの処理における明白な非効率性を指摘しました。平均的なWebページは、さまざまなリソースに対して44回の呼び出しを行い、それらの要求の多くは反復的なヘッダーデータを含みます。Holzle氏によると、ヘッダーを圧縮すると、一部の主要サイトでページの読み込みが88％向上します。
Webサーバーによって送信された応答ヘッダーが圧縮されていることをどのように確認しますか？これは今日のテクノロジーでも可能ですか？
HTTPリクエストヘッダーまたはレスポンスヘッダーを圧縮することは、HTTP1.1標準に準拠していません。
ここで言われていることは、そのような計画がどのように作られることができるかについてのいくつかの分析です：
1）たぶん、たとえば、他のカスタムhttpスキームを使用してそれを達成できることを意味しますhttpc://。
また、同じサーバーとの間で5つのバッチで要求と応答を送信すると、Webの速度も向上すると主張することもできます。私はこのスキームを呼びますhttpBrian://。
2）HTTP応答ヘッダーのみを意味すると想定する場合、要求ヘッダーには、非準拠のHTTP応答として応答を含めることを指定する別のヘッダーを含めることができます。ただし、これにはプロキシなどの問題があると思います。
3）部分的なHTTP応答ヘッダーのみを意味すると仮定すると、HTTPサーバーは、別のヘッダーに圧縮された要求を実行するhttpクライアントを除いて、すぐには重要ではない非プロキシヘッダーを配置できます。HTTPリクエストはそのような機能を有効にします。これはおそらく彼らが達成しようとしていることです。
段落をもっとよく読んでください！Hölzleは、httpヘッダーではなくWebページヘッダーについて話します。だから私たちはタグなどのようなものについて話します。meta
確かに、私は（正しく）多くの反対票を投じてきましたが、正しい情報源を最初に見つけたようです。これは、HTTPヘッダー圧縮を提供するGoogleによるSPDY（SPeeDY get it？）という名前の新しいアプリケーション層プロトコルに関するものです。
インフラストラクチャが特定のタイプのカスタムトランスポートプロトコルを介してヘッダー圧縮をサポートしている場合、その機能をサポートしていないエンティティに渡されるまで、完全に圧縮されます。
結局、おそらく私たちのブラウザでさえそれをサポートするでしょう。ですから、彼らはサーバー側でそれを開始し、それがどこまで進むかを見ることによって、積極的なアプローチを取っていると思います。