本稿ではHTTPリクエストヘッダである Accept-Encoding ヘッダについて解説します。
通信データの圧縮
HTTPリクエストヘッダ Accept-Encoding を理解するためには、まずはHTTP通信データの圧縮について理解する必要があります。 皆さんが普段目にしているホームページは、HTMLなどのテキストで作られていることは本ページを見られている方ならご存知でしょう。 またスマートフォンアプリなども JSON や XML などのテキスト形式でサーバーとデータの受け渡しをしています。
サーバーとの通信データ量を減らしたいと考えた場合、コンテンツの内容を変えずにそれを実現するには、データを圧縮する方法が考えられます。 テキストはバイナリなどに比べて圧縮しやすく、HTML, スタイルシート(CSS), JavaScript, JSON, XML などのWEBで利用されているテキストを圧縮して送受信すれば、通信データ量を減らすことができるというわけです。
しかし、通信データを圧縮する場合に考慮すべき点もあります。 それはクライアントとサーバーが、共通の圧縮アルゴリズムをサポートしている必要がある点です。 サーバーが一方的に圧縮されたコンテンツを送りつけても、クライアントが解凍できないと意味がありません。
またデメリットとしては、データ送信前とデータ受信後に圧縮・解凍の処理が必要になるため、平文でデータを送受信するよりも処理負荷が高まることがあげられます。
ポイント
- コンテンツを圧縮して送信すれば、ネットワークを流れるデータ量を減らすことができる。
- 通信データを圧縮するには、クライアントとサーバーが共通した圧縮アルゴリズムをサポートする必要がある。
- 通信データを圧縮した場合、データ送信前とデータ受信後に圧縮・解凍の処理を行うため、処理負荷は高まる。
Accept-Encoding ヘッダの用途・目的
Accept-Encoding ヘッダは、HTTPクライアントがサーバーにHTTPリクエストを送信する際に付与するヘッダ項目です。 Accept-Encoding ヘッダの目的は、クライアントがサポートしている圧縮方式をサーバーに教えることです。 サーバーは送られてきた Accept-Encoding ヘッダの値を見て、クライアントに合う圧縮アルゴリズムでコンテンツを圧縮して返却してあげれば良いというわけです。
書式
Accept-Encoding ヘッダの書式は、次のとおりです。
Accept-Encoding: 圧縮アルゴリズム
2017年現在、筆者の手元にある Chrome が実際に送信している Accept-Encoding ヘッダは、次のようになっています。 GZIP, DEFLATE, Bratli の3つの圧縮アルゴリズムをサポートしているということをサーバーに伝えています。
Accept-Encoding: gzip, deflate, br
主に利用されている圧縮アルゴリズム・フォーマット
HTTPのデータ圧縮で用いられる主な圧縮アルゴリズムについて整理します。 主には次のようなものが利用されています。
タイプ | 名称 | 説明 |
---|---|---|
deflate | Deflate | RFC 1951 の DEFLATE データ圧縮アルゴリズム。 |
gzip | GZIP | RFC 1952 の GZIP (GNU zip) ファイルフォーマット。 |
sdch | SDCH | Google が Chrome や Android で採用していたが Chrome 59 でサポートが打ち切られた。 次に紹介する Brotli への移行が進んでいる。 |
br | Brotli | 2015年に Google の技術者によって発表された圧縮ライブラリ。 Deflate に比べて20%程度の圧縮が優れている。 Chrome, Firefox, Opera などで採用が進んでいる。 |
おわりに
本稿では Accept-Encoding について解説しましたが、次は別稿「TelnetでHTTPリクエストヘッダAccept-Encodingの動きを観察しよう」で Accept-Encoding の挙動についてさらに理解を深めてみてください。