7

HTTP ヘッダーはあまり効率的ではありません。最小限のメソッド ヘッダーと応答ヘッダーの間で、必要以上に数十バイトが使用されます。

HTTP のバイナリ形式または圧縮形式を標準化する提案はありますか?

HTTP 以外に、インタラクティブなモバイル アプリケーションにより適した同様の標準はありますか?

4

4 に答える 4

10

Stackoverflowで参照されているように-HTTP応答ヘッダーを圧縮する方法は?

GoogleのSPDY研究プロジェクトを参照してください:GoogleのSPDY研究プロジェクト

SPDYホワイトペーパーから:

ヘッダー圧縮の役割

ヘッダーの圧縮により、要求ヘッダーのサイズが最大88%減少し、応答ヘッダーのサイズが最大85%減少しました。アップロードリンクがわずか375Kbpsである低帯域幅のDSLリンクでは、特にリクエストヘッダーの圧縮により、特定のサイト(つまり、多数のリソースリクエストを発行したサイト)のページの読み込み時間が大幅に改善されました。ヘッダーの圧縮だけで、ページの読み込み時間が45〜1142ミリ秒短縮されることがわかりました。

于 2011-03-17T00:24:04.817 に答える
5

これは古い質問であり、更新が必要だと思います。私自身、このトピックについて深く理解しているわけではありませんが、HTTP/2 の HPACK 圧縮について説明しているこの非常に優れた記事に出くわしました

要するに、それは言います:

  • SPDY は CRIME 攻撃に対して脆弱であったため、ヘッダー圧縮を実際に使用した人は誰もいませんでした。
  • HTTP/2 は、HPACK と呼ばれる新しい専用ヘッダー圧縮アルゴリズムをサポートします
  • HPACK は CRIME に強い
  • HPACK は、静的辞書、動的辞書、ハフマン エンコーディングの 3 つの圧縮方法を使用します。
于 2016-12-20T15:02:20.697 に答える
5

現在ドラフト段階にあるHTTP/2.0は、これらの問題に対処するために設計された SPDY の進化版です。

具体的には、リクエスト行とヘッダーをコンパクトなバイナリ形式に置き換えます。サーバー プッシュ機能を追加し、単一の接続でストリームを多重化して、複数の接続とヘッドオブキュー ブロッキングのオーバーヘッドを回避します。他にもいろいろなグッズがあります。

私は、軽量/カット トゥ フィットの C++ 実装に取り​​組んでいます。

于 2014-05-14T08:09:37.493 に答える
0

すぐに、私はノーとノーと言うでしょう。HTTPは、独自のサーバー/クライアント通信を廃止するために発明されました。それはあなたがまだ独自のサーバー/クライアント通信を行うことができないことを意味しますか?いいえ。先に進んで、独自のサーバーとプロトコルを作成し、必要なポートを開いて、ボールを持ってください。

于 2011-03-17T00:23:10.287 に答える