「Please ship your next Windows Phone app with GZip: speed requests 50-80%」 より
どうやら Windows Phone 7.5 の WebClient は HTTP 圧縮に対応していないみたいです。
けど、WebClient をちょこちょことやってやればそんなに難しくなく圧縮に対応できるよ。そうすれば、通信の時間が短縮できてパフォーマンスアップできるかも、と。
(だから標準で対応してくれって言ってるんですね。確かにこれくらい対応しててもよさそうなもんだけど)
元ネタとなっている記事はこちら。「GZIP Compressed Web Requests in WP7 - Take 2」
WebClient を使って圧縮に対応する方法が紹介されています。(ソースをダウンロードすることもできますし、NuGet から取得することもできます)
簡単に解説。(私もあまり詳しくないけど)
今どきの Web サーバーはレスポンスを gzip で圧縮して返すことができます。圧縮してデータのサイズを小さくできればネットワークの負荷を下げて効率を良くすることができるわけです。けど、毎回圧縮処理をするとそのぶん CPU 負荷があがっちゃうので良い面ばかりでもないです。
JSON や XML などといったテキストベースのデータの場合はかなり圧縮率が高くなることが期待できますが、反対に JPEG や MPEG といったもともと圧縮されているものはそれ以上圧縮しても何の意味もない、というか、かえってサイスが大きくなっちゃったり、CPU 負荷を上げたりと悪い面の方が大きくなってしまいます。
なので、圧縮を使ってるかはサーバーによっていろいろみたいです。圧縮をまったく使ってないサーバーだとか、静的な HTML ファイル等だけ圧縮してそれ以外のファイルや動的な CGI や PHP、ASP.NET などで作られるデータは非圧縮としているサーバーだとか。
で、もちろん、クライアントの側も対応していないと話になりません。
圧縮に対応しているクライアントは HTTP リクエストヘッダーに “Accept-Encoding: gzip” と入れておきます。
これが入っている時のみ、サーバーはレスポンスを gzip 圧縮して返します。(もちろん、非圧縮で返してもいい)
レスポンスが圧縮されているときはレスポンスのヘッダーに “Content-Encoding: gzip” と入っています。
上記で紹介されているコードを見ても、これと同じ事をやっています。で、レスポンスが gzip だったらレスポンスのストリームを SharpGIS.ZLib.GZipStream というもの経由で返すようにしています。
> けど、毎回圧縮処理をするとそのぶん CPU 負荷があがっちゃうので良い面ばかりでもないです。
返信削除事前に gzip 圧縮した静的コンテンツをレスポンスで返すことも出来ますので