モバイル デバイスで Java ME アプリケーションを使用して Tomcat サーバーと通信しています。
ネットワーク経由で送信されるバイト数を減らすために、Gzip を使用して要求/応答を圧縮できるかどうか疑問に思っていました。
4 に答える
最近の電話は CPU パワーが非常に高く、ネットワークが比較的遅いため、圧縮は完全に理にかなっています。やり方もとっても簡単。
J2ME 側では、次のようにします (HttpConnection を使用すると仮定)。
hc.setRequestProperty("Accept-Encoding", "gzip, deflate");
if (hc.getResponseCode() == HttpConnection.HTTP_OK) {
InputStream in = hc.openInputStream();
if ("gzip".equals(hc.getEncoding()))
in = new GZIPInputStream(in);
...
tinyline の GZIPInputStream を使用していますが、他にもあると確信しています。
http://www.tinyline.com/utils/index.html
サーバー側では、すべて組み込みです。Tomcat の server.xml のコネクタに次の属性を追加するだけです。
<Connector
compression="on"
compressionMinSize="2048"
compressableMimeType="text/html,application/json"
... />
HTTP 要求または応答のコンテンツは圧縮できますが、ヘッダーは圧縮できません。HTTP 1.1 仕様のセクション 3.6 と、Content-Encoding ヘッダーについて説明している後のセクションを参照してください。
編集: これの裏側は、HTTP サーバー側が特定の圧縮形式を受け入れるという保証がないことです。また、HTTP のサーバー側実装の品質によっては、要求の内容が圧縮されていることさえ認識できない場合があります。したがって、サーバー側で圧縮されたリクエスト コンテンツがサポートされていることがわかっていない限り、これを行う必要はありません。
Tomcat を使用しているため、Tomcat サーバーの前に Apache HTTP サーバーのインスタンスを配置する可能性を検討してください。
これは、Apache HTTP Serverのmod_jkモジュールを使用して実行できます。これが完了したら、Apache でmod_gzip / mod_deflateを使用できます。
もちろん、これを機能させるには、クライアントが圧縮された応答を処理できる必要があります。クライアントに圧縮された応答を強制的に使用させると、(通常は) プレーン テキストの応答が期待されるため、クライアントは意味不明な表示をしてしまいます。クライアントの Accept-Encoding ヘッダーには、圧縮された応答を処理するクライアントの機能の明確な指標があります。
これは、ネットワークに Apache HTTP サーバーが導入されるのを避けたい場合は、ZipOutputStream または GZipOutputStream に書き込むサーブレットまたはサーブレット フィルターを使用して、プログラムで行うことができます。これを行う方法については、OReilly OnJava.com サイトにいくつかのヒントがあります。
サーバー側では、ここで説明されているように有効にできますが、モバイル アプリケーションには、このような gzip を解凍できるライブラリが必要になります。それを機能させるには少し手間がかかるかもしれませんが...