構成ファイルをZIPでまとめて一括転送する技術、Firefox 3.7に向けて検討中 67
ストーリー by hylom
さらに速く 部門より
さらに速く 部門より
あるAnonymous Coward 曰く、
画像やスクリプトファイルといったWebページの構成ファイルをZIPでまとめて一括転送することで、Webページのロードを高速化する技術がFirefoxの開発者によって提案されている(マイコミジャーナルの記事)。
この仕組みは「Resource Packages」と呼ばれており、非対応ブラウザとの互換性を保ちつつ、高速にWebページの構成ファイルを転送することを目的としている。現在のWebページではスタイルシートや装飾画像、そしてさまざまなスクリプトなど、非常に多数の要素が含まれており、それらに対していちいちHTTPリクエストを送るのではなく、それらを1つのZIPファイル(Resource Package)にまとめて1回のリクエストで一括ダウンロードすることでページの読み込みを高速化する、という仕組みだ。Resource PackageはHTMLのヘッダ部分で指定し、非対応ブラウザでもページが正しく表示されるという。
この提案はFirefox開発者のなかでも好意的に検討されているとのことで、Firefox 3.7で実装される可能性があるという。
麻呂のAA (スコア:3, おもしろおかしい)
And now for something completely different...
Re:麻呂のAA (スコア:1)
これで人大杉でも安心ですね、わかります。
-------- tear straight across --------
RFC2557 (スコア:3, すばらしい洞察)
MHTML を content-encoding: gzip で送るんじゃダメなの?
なんで既存の仕様を使うんじゃなくてゼロから新しいものを作り直す必要があるの?
Re:RFC2557 (スコア:5, 参考になる)
短い答え:
長い答え:
この手法の概要は次のとおり。
この手法では、HTMLファイルはそのまま非対応ブラウザでも見られます。サーバ側での特別な動作も必要ありません。ZIPファイルを作るのも、対象のディレクトリにcdして、zip -r hoge.zip *で済みます。
また、動的に生成されることの多いHTMLファイルをアーカイブからはずせるため、ZIPファイルをキャッシュできます。
Re:RFC2557 (スコア:1, 興味深い)
たしかに、それでいいような気がする。
該当するのは、bmo #18764 [mozilla.org]かなぁ。
他にもコメントがあるけど、Mozillaで内輪受けしたAPNGが、libpng本家に採用を否決 [sourceforge.net]された過去を忘れたから、再度内輪受け技術で挑戦、ということではないでしょうか。bmo #18574 [mozilla.org]のようにならなければいいな。
Re: (スコア:0)
Re: (スコア:0)
それだと10の画像があれば10個ダウンロードしちゃうじゃん。
Re: (スコア:0)
MHTMLだよ?
MHTMLだよ?
Re: (スコア:0)
修正とか動的な変更とかにも対応し難くなるし。
その結果、普通のウェブサイトでもあまりmhtmlって使われてないのだし。
メールなら送るメールが最終便で以降は修正無いから欠点にはならないけど。
Re: (スコア:0)
>修正とか動的な変更とかにも対応し難くなるし。
Resource Packages とやらも同じように感じますが。
>その結果、普通のウェブサイトでもあまりmhtmlって使われてないのだし。
使われないのはメンテの問題じゃなくてブラウザが対応してないからでしょ。
Re: (スコア:0)
はげどう。無意味なAnti-MSイクナイ
それってなんて .docx ? (スコア:3, 参考になる)
.docx がファイルをもっていたら、拡張子を .zip に変えて開いてみてください。
.jar も .xpi もZIPですね。
zip の書庫ってかなりさまざまなファイルに使われていますね。
デザイナさんにお願いアハハーン (スコア:3, 興味深い)
普及するかどうかは微妙。デザイナさん次第だと思います。
エンジニアとしては余りまくってるCPUリソースを使うことで
ネットワークがかるくなるんだよよよ!とウキウキですが、
ヘッダを追加して、コンテンツをzipして別途アップロードするのはデザイナさんなので、
面倒なのでやらないかもですね。んで、やらなくても見れてしまうし。
更新し忘れでzipしたコンテンツが古いままとか。
mhtmlなら複数のファイルがひとつになるのでデザイナさんにもメリットが目に見えるのですけど。
phpのアクセラレータのように全自動でzipファイルの生成とキャッシングする仕組みを作ればいいですけど、
だったらサーバサイドの変更がいらないっていう仕様の意味がなくなります。
#検索エンジンのクローラはどっち見に行くのかしら。両方読んで内容比べて。
#→帯域圧迫→マズー
裏技的手法ですね (スコア:2, 興味深い)
生で提供されるファイルの同期を取るのが厄介という問題が出てくるね。
つまり、この機能を使うブラウザでは表示が古いというミスが起き易くなると。
だから、運用面も考えればブラウザだけ対応すればいいとは言えません。
#面白いし改変コストの低い方法だし有効性は高いから上手くやれば良い結果は得られそうだ。
Re:裏技的手法ですね (スコア:2)
場合によっては文字列だけが更新されていて、重い画像はブラウザのキャッシュにあるからいりません、なんていう場合もありますよね。毎回ブラウザのニーズに合わせてzipファイルを生成していては負荷が高いでしょうし、キャッシュにあるデータまでzipされて送信されると却ってデータが大きくなりますし、バランスを取る必要が出てきそうですね。
人生は七転び八起き、一日は早寝早起き
Re:裏技的手法ですね (スコア:1)
> キャッシュにあるデータまでzipされて
ブラウザに限らずsquidなどのキャッシュサーバにも同じことが言えそうです。
*.zipなどのアーカイブファイルはそうそう頻繁に更新されることもないと考えてsquidの refresh_patternで最低キャッシュ時間を0より大きく設定していたのですが、今後は止めた方が良いかもしれません。
運転手は運転がお仕事。笑うのはブギーポップにはできない僕らのお仕事。
Re: (スコア:0)
> キャッシュにあるからいりません
という判断をするのはブラウザの側でしょ?
前回から更新された、まだ画像にない分の画像だけをzipにまとめて送ってくださいなんて、動的に生成しなければ絶対に無理じゃありませんか。
それにzipだからって圧縮する必要はありません。どうせ中身のほとんどは圧縮がほとんど効かない画像類なんだから、無圧縮で格納すればよろしい。それなら負荷がHTTP/1.1のpersistent connectionより高くなることはありえません。
Re:裏技的手法ですね (スコア:3, 参考になる)
Goal [limi.net]の内容とImprementationをざっと読んでみたんですが、Webページひとつひとつを全部zipにまとめることを意図したものではなさそうですね。たとえば/.-Jで言えば、各ページに共通のアイコンやスタイルシートなどをzipにしておいて、そのページ固有のHTML等はzipとは別に取得するというような雰囲気(href="/static/site-resources.zip"などと例にある)です。
PNGの画像をzipにすると却ってサイズが増えるのでは? なんていうFAQもありますが、そこは確かにご想像のように無圧縮のzipが使われることもあるだろう、などと書かれています。
人生は七転び八起き、一日は早寝早起き
Re:裏技的手法ですね (スコア:5, すばらしい洞察)
というかみんな圧縮にこだわりすぎ。
これはどちらかというと複数ファイルをアーカイブすることによりHTTPリクエストの数を減らす方がメインの目的だと思うんだけど。
データ圧縮は回線が十分高速になると体感上の効果は小さくなるけど、HTTPのリクエスト/レスポンスを減らすのは高速回線でもそれなりにメリットが期待できる。
PNGのサイズが多少増えたとしても、数がたくさんあればリクエスト回数が減ることによるレスポンスの向上がそれを上回ることも多いでしょう。
うじゃうじゃ
Re:裏技的手法ですね (スコア:1)
2003年にNetli [atmarkit.co.jp]という企業が似たようなことやってまして。。
と思ったらAkamaiに買収されてるようで。
特許被らないといいね。
Re: (スコア:0)
Re: (スコア:0)
#関係ないけど、「構成ファイル」っていわれると configuration file みたいだ
Re: (スコア:0)
Re: (スコア:0)
この方法はブラウザ側での実装が簡単なうえ、サーバ側に変更を加える必要がない。 [mycom.co.jp]…サーバー側のことまで考えてなさそうです。
Re: (スコア:0)
パソコン通信の FidoNet なんですが、ホストの方で複数の会議室の未読部分を圧縮してくれるので、その圧縮ファイルを受信していました。
掲示板のテキストだけだったので、圧縮効率は高かったと思います。
やりとりのイメージ (スコア:2, 興味深い)
例を挙げると、こんなかんじかなぁ
1.クライアントがサーバーにindex.htmlをくれという
2.サーバーはindex.htmlを返しつつ、「うちはzipに対応してるよ」ということをヘッダで示す
3.クライアントは、index.htmlからサーバーへの画像やCSSのリンクを抽出し、
こんなファイルがほしいよ〜(zipで)とリストを送る
(キャッシュにあるものはリストに含めない)
4.サーバーは送り返すファイルをまとめzipで返す
(zipにまとめられなかったものもリストで返す)
5.クライアントはzipにないものを個別アクセス
こうすれば、Webサーバーを対応させれば、その上で動くプログラムには影響がないかな
Re:やりとりのイメージ (スコア:2, 興味深い)
かな?
あんまり動的なページをzipに含める事は考えていないように見えますね。 固定のスタイルシートやら飾りやらを送ろうと言うのがあくまで主体のような。 まあ、手法が一般化すると今度はファイルの更新に自動対応するapache用のモジュールも作られるであろう事は疑う余地がありませんが。
だとすると、href="/static/site-resources.zip"の部分に飛んでもなくでかいファイルを指定してやるとか、無限にデータを投げ返してくるcgiやらを指定してやるとかすることで、Resource Packages対応のブラウザでは閲覧がめんどくさいページが簡単に作れちゃうような気がします。そんないたずらを仕込む前向きな理由は思いつきませんが。「Resource Packagesのダウンロードが完了していない段階でブラウザがやることが無くなったら、zipは見捨ててhttpでファイルを取りに行く」みたいな例外処理を入れておくのかな? それはそれで本末転倒のような。
Re:やりとりのイメージ (スコア:2)
このファイルはZIPファイルの最初のファイルでなければなりません。
ZIPファイルは全てを読み込まなくても中身が読めるので、とりあえず読めた部分まではZIPファイルの中身を利用できます。
Re:やりとりのイメージ (スコア:1)
つまり「とりあえずこれらのファイルをまとめて zip にして……」とエクスプローラー上でさくっとまとめる、といったことはしにくいのですね。
なんかオーサリングツールでの支援とかが得られなかったら対応するサイトが極めて少なくなりそうですね。
まだ発展途上? (スコア:1)
いろいろ違いがあるとはいえ、やっと追いついた感じ?
#あ、JIGブラウザも似たような事をやってるんでしたっけ
Re: (スコア:0)
>アナログモデムの頃は通信プロトコル自体にデータ圧縮があったと思うので、
HTTPもサーバクライアント間でネゴシエーションしてgzipやdeflateで圧縮して送る技術は昔からありますよ
Re:まだ発展途上? (スコア:1)
そうなんだよね。
この記事もHTTP1.1でgzip圧縮かけるのと、zipにまとめたファイルをダウンロードするのと、どんだけ違うの?って思った。初回表示以外はキャッシュが働くこととか、スクリプトや装飾画像は複数のページで共有されていることも考えると、全く意味がないと思う。
Re:まだ発展途上? (スコア:1)
「圧縮する」ことよりも「まとめて送る」ことに価値があると思います。
a.htmlが a.css と b.js を読んでる
b.js では、動的にc.css を読んでる
(以下略)
みたいな感じで必要なファイルが連鎖していくと、
順次ファイルを解析しては次のファイルをリクエスト、という流れで
表示に必要なファイルが全部揃うまでにかなり時間がかかります。
それを、最初のa.html を取得する時点で、必要になるファイルを一式全部一緒に渡してしまえば、
「リクエストしては結果が届くのを待つ」時間がなくなりますので、その分の高速化は期待できるかと。
問題は、そういう
> 初回表示以外はキャッシュが働くこととか、スクリプトや装飾画像は複数のページで共有されていること
を考えると、オーバーヘッドが大きいってことですよね。
最初のa.html のリクエストの段階で、
ブラウザから手持ちのファイル群について、If-Modified-Since 群を送りつけて、
サーバからは、無い/新しいファイルだけをまとめてzip転送する、とかすれば効率化は図れそうです。
そんな感じでいろいろ工夫は出来そうですが、
そもそもどのファイルが読まれるか分からない状況ではそういう候補ファイル群をリストアップすることすら難しいでしょうし、
プロトコル的に拡張しないといけないし、サーバ側の対応しなきゃいけないので、実現は難しいでしょうね…
rsync -z (スコア:1, すばらしい洞察)
昔、私も実験しました。 (スコア:1)
実験してたら、アカウントごと消されたっけ...
私の場合は、html内に圧縮したデータをエンコードして組み込んでましたけどね。
だから序文は普通にhtmlなメッセージが入っていて、非対応なブラウザにはそのメッセージだけ
みえるという形。
まあ、それ用のブラウザ構築するまでにはいたらず、飽きてしまったのだけど...
みんな似たような事を考えるみたいですね。
ないです (スコア:1)
暗号化もからめた議論にしてほしい (スコア:1)
応用可能な技術だと思う。
HTTPSとdeflateを絡めると、JavaScriptやCSSの読み込みに失敗したりとか
はまった経験があるので、そのあたりも含めてぜひ議論して欲しい。
aPNGよりも (スコア:0)
ありがちなパターン (スコア:0)
・従来型のデータを更新したときにzipを更新し忘れる、またはその逆
・従来型のデータとzipの内容をわざと違うものにして遊ぶ
・展開すると膨大なサイズになるzipで攻撃
というかページの表示が遅いのは転送のオーバーヘッドのせい
ではなくてやたらと凝ったスタイルシートの(ry
Re:ありがちなパターン (スコア:1)
サーバー側がリアルタイムに圧縮するのでは?
deflate のファイル複数版みたいな挙動を想像したのですが
Re:ありがちなパターン (スコア:1)
いや、一応ウェブ管理者が自分で作成するらしい。
1. 収めるファイルを調べる
2. zip作成
3. html内にlinkタグでリソースzipを指定
だからやっぱり入れ忘れる事もあるんだろうね。そのへんは専用のツールでどうにかするんでしょう。
でも私もサーバ側で自動生成のほうが面白いと思いますね。
httpレスポンスヘッダに追加するんだろうなー
それよりいい方法がある (スコア:0)
OperaにはDelayed Script Executionというオプションがあり(Opera:Config >)
先にページを読み込んでからスクリプトを読んで後から適用する、というものなんだけど、
これで表示は随分速くなる。
・・・というか。
ウェブサイトにでかい.jsファイルやCSSをくっ付けなければ良いだけなんだけどね。
Re:それよりいい方法がある (スコア:1)
やってみたら、スラドのコメントツリーを折りたたもうとしたらリロードされて折りたためなかったので却下。
(Opera 10.01 Windows XP)
うじゃうじゃ
mod_zipって意外と面倒くさいんだよなぁ (スコア:0)
いっそサーバサイドのファイルシステムと合流して、zipなディレクトリにしてしまえばいいかも。
って、静的なファイルって今時無いか。
ついでにEPUBも (スコア:0)
zipよりも (スコア:0)
tar+gzとかの方が良くないか?
多分良くない。 (スコア:0)
中身をlistするだけでも、いちいちgunzipしてやらないとダメじゃん。
キャッシュの判断 (スコア:0)
何も考えずに要素全てを固めて転送じゃあ、かえって遅くなったりする事もありそうじゃない
うーむ (スコア:0)
Webを一つの場としてページを構成することがHTMLの良さだと思うんだけど
画像はあのサーバとかこのサーバから、CSSはこのサーバ……、なんて
バックエンドがDBなんてことは昨今当たり前だし
あんまり意味ないと思うけどなぁ
それよか、HTTP互換の新しいプロトコルを作った方が筋が良い気がする
もちろんW3Cとかみたいな標準化組織を通して
駄洒落なのでAC (スコア:0)