GZIP 圧縮 Tomcat と Web パフォーマンスの改善プロセス図

1. はじめに

最近、あるプロジェクトに取り組んでいたのですが、サーバーからクライアントに返される JSON データの量が大きすぎ (約 65 MB)、クライアントでの読み込みとレンダリングに 1 分以上かかり (もちろん、この読み込み時間はローカルのダウンストリーム帯域幅にも関係します)、時間がかかり、大量のトラフィックを消費し、ユーザーエクスペリエンスが極めて悪くなるという問題に遭遇しました。その後、オンラインで最適化方法を検索したところ、Http 圧縮であることがわかりました。

HTTP 圧縮は、Web サイトの閲覧速度を大幅に向上させます。その原理は、クライアントがサーバーから対応するリソースを要求した後、リソースファイルがサーバーから圧縮され、クライアントに出力されるというものです。クライアントのブラウザーは、解凍と閲覧を担当します。つまり、HTTP 応答サイズを縮小することで応答時間を短縮します。通常のブラウジングプロセス（HTML、CSS、Javascript、テキスト）と比較すると、トラフィックを約 40% 節約できます。さらに重要なのは、CGI、PHP、JSP、ASP、サーブレット、SHTML などによって出力されるものを含む、動的に生成された Web ページを圧縮でき、圧縮効率も非常に高いことです。 GZIP 自体はネットワークストリーム圧縮アルゴリズムであり、広く使用されています。この記事では、Apache Tomcat 8.0.47 の GZIP 圧縮の構成について説明します。使用したブラウザは Mozilla Firefox 35.0.1 で、デバッグには組み込みの Firebug を使用します。次のネットワーク関連のスクリーンショットは、Firebug コンソールからのものです。

2. Gzip圧縮の概要

1. HTTP プロトコルは、プロトコル圧縮とも呼ばれる GZIP 圧縮メカニズムをサポートしています。 HTTP GZIP 圧縮は、Web サーバーとブラウザーの両方が従うプロトコルです。つまり、Web サーバーとブラウザーの両方がこれに準拠する必要があります。現在、主流のサーバーとブラウザは GZIP 圧縮技術をサポートしています。 Chrome、IE、FireFox、Opera などを含み、サーバーには Tomcat、Apache、IIS などが含まれます。

2. GZIP は主に、html、css、javascript などの静的テキストファイルを圧縮するために使用されます。また、CGI、PHP、JSP、ASP、サーブレット、SHTML などによって出力されるものを含む、動的に生成される Web ページの圧縮もサポートします。

3. GZIP 圧縮率は通常 3 ～ 10 倍で、サーバーのネットワーク帯域幅を大幅に節約し、ブラウザの閲覧速度を大幅に向上させることができます。

4. GZIP はデータ圧縮形式です。デフォルトでは、データ部分の圧縮に deflate アルゴリズムのみを使用します。deflate は、ハフマンコードを拡張した圧縮アルゴリズムです。

5. プロトコル圧縮は HTTP プロトコルに基づいています。プログラマーは圧縮、解凍、エンコードを実行する必要はなく、代わりに圧縮プロセスは WEB サーバーに引き渡され、解凍プロセスはクライアントに引き渡されます。クライアントが GZIP 圧縮をサポートするブラウザである場合、解凍プロセスにプログラマーが関与する必要はなく、ブラウザは特定のルールに従って自動的に解凍します。クライアントが HttpClient である場合は、GZIP デコードを手動で実行する必要があります。

6. 圧縮プロセス: クライアントは http リクエストを送信します。リクエストヘッダーに Accept-Encoding:gzip,deflate (現在のブラウザーは一般的にこれをデフォルトとして使用します) が含まれている場合、ブラウザーはサーバーが GZIP 圧縮を実行する必要があることを意味し、応答コンテンツタイプがサーバーによって構成された圧縮タイプを満たしているかどうかを確認します。そうである場合、WEB サーバーは応答コンテンツを送信する前に圧縮し、応答ヘッダーに Content-Encoding gzip を追加します。そうでない場合は、圧縮されずに直接返されます。

7. 解凍プロセス: (ブラウザ) クライアントは応答を受信します。応答ヘッダーに Content-Encoding GZIP が含まれている場合、ブラウザは自動的に GZIP を使用して応答コンテンツを解凍し、ページに表示します。含まれていない場合は、ページ上で直接レンダリングされます。

8. GZIP の欠点。 GZIP を使用しないプロジェクトと比較すると、GZIP を使用すると、サーバーの圧縮 (CPU 消費) とクライアントの解凍の負荷が増加するため、サーバーの構成要件が高くなります。また、圧縮には時間がかかります。より少ないスペースを占有して高い圧縮率を得たい場合は、より長い時間を犠牲にする必要があります。逆に、時間の方が貴重でスピードが求められる場合は、圧縮率を小さくする必要があり、当然より多くのスペースを占有します (圧縮率 = 元のコンテンツのサイズ/圧縮サイズ、圧縮率が大きいほど、圧縮後の圧縮パッケージが占めるサイズは小さくなります)。これが物理的なスペースと時間の矛盾です。

3. tomcatでの設定方法

バージョン要件: Tomcat 5.0 以上。 %TOMCAT_HOME%/conf/server.xml を変更し、ノードを次のように修正します。

<コネクタポート="8080"
プロトコル="HTTP/1.1"
接続タイムアウト = "20000"
リダイレクトポート="8443"
圧縮="オン"
圧縮最小サイズ="2048"
noCompressionUserAgents="gozilla、traviata"
圧縮可能なMimeType="text/html,text/xml,text/javascript,
アプリケーション/javascript、テキスト/css、テキスト/プレーン、テキスト/json"/>

パラメータの説明:

1. compression="on" は圧縮をオンにします。オプションの値: 有効にする場合は「on」、無効にする場合は「off」、すべての場合に有効にする場合は「force」。

2. compressionMinSize="2048" 2KB を超えるファイルのみが圧縮されます。最小圧縮データサイズを B 単位で指定するために使用されます。デフォルト値は 2048 B です。この値のサイズに注意してください。適切に設定されていない場合、小さなファイルが圧縮後に大きくなり、期待した効果が得られなくなります。

3. noCompressionUserAgents="gozilla, traviata"、これら 2 つのブラウザでは圧縮は実行されません (これら 2 つのブラウザが何であるかはわかりませんし、Baidu でも見つけることができません)。その値は正規表現であり、一致する UA は圧縮されません。デフォルト値は空です。

4. CompressibleMimeType="text/html,text/xml,application/javascript,text/css,text/plain,text/json" は、圧縮される MIME タイプのリストです。複数のタイプはコンマで区切られ、html、xml、js、css、json などのファイル形式の圧縮がサポートされていることを示します (plain は形式がないことを意味しますが、それが何であるかは不明です)。 CompressableMimeType は非常に重要です。これは、Tomcat にどのファイルを圧縮するかを伝えるために使用されます。タイプが誤って指定されると、確実に圧縮されません。では、圧縮するファイルの種類をどうやって知るのでしょうか?これは次の方法で見つけることができます。

4. 設定が成功したかどうかを確認する

変更後、Tomcatを再起動し、最後にテストWebサイトhttp://seo.chinaz.com/?host=iitshare.comにアクセスして効果を確認します。

5. 一般的なエラー（設定後は影響なし）

以下の手順に従ってトラブルシューティングを行うことができます。

1. Tomcat の設定パラメータが間違った場所に書き込まれています。設定パラメータは、以下の図の領域 B ではなく領域 A、つまり protocol="HTTP/1.1" のコネクタに書き込む必要があることに注意してください。

2. 応答データは、compressibleMimeType パラメータで設定されたタイプではありません。私はこの落とし穴に遭遇しました。私たちのプロジェクトでは、フロントエンドとバックエンドの送信に json を使用していました。最初は「text/json」だと思っていましたが、Firebug コンソールを開いてみると、Content-Type の値が「application/json」であることがわかりました。図3を参照してください。

3. 応答データのサイズがcompressionMinSizeの設定値よりも小さい。

付録: 最適化結果

圧縮比 = 65.6 / 8.4 = 7.810、時間比 = 96 / 16.2 = 5.926 となり、すでに理想的であることがわかります。