HTTP 圧縮

HTTP圧縮は、転送速度と帯域幅の利用率を向上させるためにWebサーバーとWebクライアントに組み込むことができる機能です。^[1]

HTTPデータはサーバーから送信される前に圧縮されます。準拠したブラウザは、正しい形式でダウンロードする前に、サーバーにサポートされている方式を通知します。準拠した圧縮方式をサポートしていないブラウザは、圧縮されていないデータをダウンロードします。最も一般的な圧縮方式には、 gzipとBrotliがあります。利用可能な方式の完全なリストはIANAによって管理されています。^[2]

HTTP では 2 つの異なる方法で圧縮を行うことができます。低レベルでは、Transfer-Encoding ヘッダー フィールドは、HTTP メッセージのペイロードが圧縮されていることを示します。高レベルでは、Content-Encoding ヘッダー フィールドは、転送、キャッシュ、または参照されるリソースが圧縮されていることを示します。Content-Encoding を使用した圧縮は Transfer-Encoding よりも広くサポートされており、一部のブラウザーはサーバーのバグの発生を避けるために Transfer-Encoding 圧縮のサポートを宣伝していません。^[3]

ネゴシエーションは、RFC 2616 および RFC 9110 で説明されている 2 つのステップで実行されます。

1. Web クライアントは、HTTP リクエストにトークンのリストを含めることで、サポートする圧縮方式を通知します。Content -Encodingの場合、リストはAccept-Encodingというフィールドにあります。Transfer -Encodingの場合、フィールドはTEと呼ばれます。

GET  /encrypted-area  HTTP / 1.1
ホスト:  www.example.com 
Accept-Encoding :  gzip、deflate

2. サーバーが 1 つ以上の圧縮方式をサポートしている場合、送信データは、双方がサポートしている 1 つ以上の方法で圧縮される可能性があります。この場合、サーバーは、使用された方式をコンマで区切って、HTTP 応答に Content-EncodingまたはTransfer-Encodingフィールドを追加します。

HTTP / 1.1  200  OK
日付:  mon, 26 June 2016 22:38:34 GMT
サーバー:  Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
最終更新日:  Wed, 08 Jan 2003 23:11:55 GMT 
Accept-Ranges :  bytes 
Content-Length :  438
接続:  close 
Content-Type :  text/html; charset=UTF-8 
Content-Encoding :  gzip

ウェブサーバーは、いかなる圧縮方法を使用する義務もありません。これは、ウェブ サーバーの内部設定に依存し、また、問題のウェブサイトの内部アーキテクチャに依存する場合もあります。

サーバーとクライアントで利用可能なトークンの公式リストはIANA ^[4]によって管理されており、以下のものが含まれています。

• br – Brotli は、HTTP コンテンツ エンコーディング専用に設計された圧縮アルゴリズムで、RFC 7932 で定義され、すべての最新の主要ブラウザーに実装されています。
• 圧縮– UNIX の「圧縮」プログラム方式 (歴史的; ほとんどのアプリケーションでは非推奨で、gzip または deflate に置き換えられました)
• deflate – deflateアルゴリズム (RFC 1951 で説明)に基づく圧縮。これは、 LZ77アルゴリズムとハフマン コーディングを組み合わせたもので、zlibデータ形式 ( RFC 1950) 内にラップされています。
• exi – W3C効率的な XML 交換
• gzip – GNU zip 形式 ( RFC 1952で説明)。圧縮にはdeflateアルゴリズムを使用しますが、データ形式とチェックサム アルゴリズムは「deflate」コンテンツ エンコーディングとは異なります。この方法は、2011 年 3 月現在、最も広くサポートされています。^[5]
• identity – 変換は使用されません。これはコンテンツ コーディングの既定値です。
• pack200-gzip – Javaアーカイブのネットワーク転送フォーマット^[6]
• zstd – RFC 8478で定義された Zstandard 圧縮

これらに加えて、サーバーまたはクライアントによって、非公式または非標準化のトークンが多数使用されています。

• bzip2 – フリーのbzip2形式に基づく圧縮。lighttpdでサポートされる^[7]
• lzma – （生の）LZMAに基づく圧縮はOpera 20で利用可能であり、elinksではコンパイル時オプションを介して利用可能である^[8]
• peerdist ^[9] – Microsoft ピアコンテンツのキャッシュと取得
• rsync ^[10] – HTTPのデルタエンコーディング。rproxyプロキシのペアによって実装される。
• xpress – Windows 8以降でWindowsストアアプリケーションの更新に使用されるMicrosoft圧縮プロトコル。LZ77ベースの圧縮で、オプションでハフマンエンコーディングを使用します。^[11]
• xz – LZMA2ベースのコンテンツ圧縮。非公式Firefoxパッチでサポートされています。^[12] 2013年12月31日からmgetに完全に実装されています。^[13]

• SAP ネットウィーバー
• Microsoft IIS : 組み込みまたはサードパーティのモジュールを使用
• Apache HTTP Server、mod_deflate（名前にもかかわらずgzipのみをサポート^[14]）、およびmod_brotli経由
• Hiawatha HTTPサーバー: 圧縮済みのファイルを提供する^[15]
• チェロキー HTTP サーバー、オンザフライの gzip および deflate 圧縮
• Oracle iPlanet Web サーバー
• Zeus ウェブサーバー
• ライト
• nginx – 組み込み
• Tornadoベースのアプリケーションで、アプリケーション設定で「compress_response」が True に設定されている場合 (4.0 より前のバージョンでは、「gzip」を True に設定)
• Jetty サーバー– デフォルトの静的コンテンツ配信に組み込まれており、サーブレット フィルタ構成を介して利用可能
• ジオサーバー
• アパッチトムキャット
• IBM ウェブスフィア
• AOLサーバー
• Ruby Rack 、 Rack::Deflaterミドルウェア経由
• HAプロキシ
• Varnish – 組み込み。ESIでも動作
• Armeria – 圧縮済みファイルの提供^[16]
• NaviServer – 組み込みの動的および静的圧縮
• Caddy – エンコード経由で内蔵

多くのコンテンツ配信ネットワークでは、エンドユーザーへのリソースの配信速度を向上させるために HTTP 圧縮も実装しています。

HTTP での圧縮は、 PHPなどのサーバー側スクリプト言語やJavaなどのプログラミング言語の機能を使用することで実現することもできます。

HTTP圧縮の実装が機能しているかどうかを確認するためのさまざまなオンラインツールが存在します。これらのオンラインツールは通常、URLの複数のバリアントを要求し、それぞれに異なるリクエストヘッダー（Accept-Encodingコンテンツが異なる）が含まれます。サーバーが圧縮された形式でドキュメントを返す場合、HTTP圧縮は正しく実装されていると見なされます。^[17]返されたドキュメントのサイズを比較することで、有効な圧縮率を計算できます（異なる圧縮アルゴリズム間でも）。

Google のエンジニアである Arvind Jain と Jason Glasgow による 2009 年の記事では、ユーザーが圧縮されたコンテンツを受信しない場合、ページの読み込み時間が長くなるため、毎日 99 人年以上の時間が無駄になっていると述べられています^[18]。これは、ウイルス対策ソフトウェアが接続を妨害して圧縮解除を強制する場合、プロキシが使用される場合 (Web ブラウザが過度に慎重な場合)、サーバーが誤って構成されている場合、ブラウザのバグによって圧縮が使用できなくなる場合に発生します。プロキシの背後では圧縮やパイプラインなどの機能のない HTTP 1.0 に落ちる Internet Explorer 6 (企業環境では一般的な構成) は、圧縮されていない HTTP にフェールバックする傾向が最も強い主流のブラウザでした^{[18] 。}

HTTP 圧縮を大規模に展開する際に見つかったもう 1 つの問題は、 deflateエンコーディングの定義によるものです。HTTP 1.1 では、deflateエンコーディングはzlib形式のストリーム (RFC 1950 ) 内の deflate (RFC 1951) で圧縮されたデータとして定義されていますが、Microsoft のサーバーおよびクライアント製品は歴史的にこれを「生の」deflate ストリームとして実装していたため、^[19]展開が信頼できませんでした。^{[20] [21]}このため、Apache HTTP Server を含む一部のソフトウェアでは、gzipエンコーディングのみが実装されています。

圧縮により、選択平文攻撃の一種が可能になります。攻撃者がページに任意のコンテンツを挿入できる場合、暗号化されたストリームのサイズの増加を観察することで、ページに指定したコンテンツが含まれているかどうかを知ることができます。増加がランダムな挿入で予想されるサイズよりも小さい場合、圧縮者がテキストの繰り返しを見つけた、つまり挿入されたコンテンツが秘密情報と重複していることを意味します。これが CRIME の背後にある考え方です。

2012 年に、データ圧縮の使用に対する一般的な攻撃であるCRIMEが発表されました。CRIME 攻撃は、TLS や SPDY や HTTP などのアプリケーション層プロトコルを含むがこれに限定されない多数のプロトコルに対して効果的に機能しますが、TLS と SPDY に対するエクスプロイトのみが実証され、ブラウザーとサーバーで大幅に緩和されました。CRIME の作者は、この脆弱性は SPDY と TLS 圧縮を組み合わせたものよりもさらに広範囲に及ぶ可能性があると警告しているにもかかわらず、HTTP 圧縮に対する CRIME エクスプロイトはまったく緩和されていません。

2013年、HTTP圧縮に対するCRIME攻撃の新しい事例であるBREACHが公開されました。BREACH攻撃は、攻撃者が被害者をだまして悪意のあるWebリンクにアクセスさせることで、TLSで暗号化されたWebトラフィックからログイントークン、メールアドレス、またはその他の機密情報を30秒ほどで抽出することができます（抽出するバイト数によって異なります）。^[22] TLSとSSLのすべてのバージョンは、使用されている暗号化アルゴリズムや暗号に関係なく、BREACHのリスクがあります。^[23] TLS圧縮またはSPDYヘッダー圧縮をオフにすることでうまく防御できる以前のCRIMEの例とは異なり、BREACHはHTTP圧縮を悪用します。これは、事実上すべてのWebサーバーがユーザーのデータ転送速度を向上させるためにHTTP圧縮に依存しているため、現実的にオフにすることはできません。^[22]

2016年現在、TIME攻撃とHEIST攻撃は公知となっている。^{[24] [25] [26] [27]}

• RFC 2616: ハイパーテキスト転送プロトコル – HTTP/1.1
• RFC 9110: HTTP セマンティクス
• Internet Assigned Numbers Authority による HTTP コンテンツ コーディング値
• lighttpd による圧縮
• コーディングホラー: IIS 6.0 での HTTP 圧縮 2014-02-06 にWayback Machineでアーカイブ
• 15 秒: Wayback Machineでの Web サイトの圧縮(2011 年 7 月 16 日アーカイブ)
• HTTP 圧縮の使用 2016-03-14 にWayback Machineでアーカイブされました(Server Watch の Martin Brown 著)
• PHP での HTTP 圧縮の使用
• Apache httpd による動的および静的 HTTP 圧縮