パスワードを忘れた? アカウント作成
168443 story
テクノロジー

構成ファイルを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, おもしろおかしい)

    by sillywalk (15002) on 2009年11月26日 18時52分 (#1678652) ホームページ 日記
    を即座に貼ろうかと思ったんですが、さすがに自粛w
    --
    And now for something completely different...
  • RFC2557 (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2009年11月26日 19時11分 (#1678671)

    MHTML を content-encoding: gzip で送るんじゃダメなの?
    なんで既存の仕様を使うんじゃなくてゼロから新しいものを作り直す必要があるの?

    • Re:RFC2557 (スコア:5, 参考になる)

      by ruto (17678) on 2009年11月26日 22時16分 (#1678808) 日記

      短い答え:

      • MHTMLは対応していないブラウザでは開けない。
      • 動的に生成されることもあるHTMLはアーカイブから外したい。

      長い答え:

      この手法の概要は次のとおり。

      1. HTMLファイルのhead内に <link rel="resource-package" href="hoge.zip" /> と記述しておく。
      2. HTMLは普通に送信する。
      3. 画像やスクリプトは通常通り相対パスで指定してある。
      4. 対応ブラウザはZIPファイルをダウンロードし、相対パスをZIPファイル内のファイルのファイル名として解釈する。もちろんZIPファイル内に見付からない場合はネットワークから取得する。

      この手法では、HTMLファイルはそのまま非対応ブラウザでも見られます。サーバ側での特別な動作も必要ありません。ZIPファイルを作るのも、対象のディレクトリにcdして、zip -r hoge.zip *で済みます。

      また、動的に生成されることの多いHTMLファイルをアーカイブからはずせるため、ZIPファイルをキャッシュできます。

      親コメント
    • Re:RFC2557 (スコア:1, 興味深い)

      by Anonymous Coward on 2009年11月26日 20時00分 (#1678714)

      たしかに、それでいいような気がする。
      該当するのは、bmo #18764 [mozilla.org]かなぁ。

      なんで既存の仕様を使うんじゃなくてゼロから新しいものを作り直す必要があるの?

      他にもコメントがあるけど、Mozillaで内輪受けしたAPNGが、libpng本家に採用を否決 [sourceforge.net]された過去を忘れたから、再度内輪受け技術で挑戦、ということではないでしょうか。bmo #18574 [mozilla.org]のようにならなければいいな。

      親コメント
    • by Anonymous Coward
      tar.gzよりもzipのほうが広く使われてるのと似たような理由じゃないですか?
    • by Anonymous Coward

      それだと10の画像があれば10個ダウンロードしちゃうじゃん。

    • by Anonymous Coward
      HTMLのページまで巻き込むと運用が厄介だからでしょ。
      修正とか動的な変更とかにも対応し難くなるし。
      その結果、普通のウェブサイトでもあまりmhtmlって使われてないのだし。

      メールなら送るメールが最終便で以降は修正無いから欠点にはならないけど。
      • by Anonymous Coward

        >修正とか動的な変更とかにも対応し難くなるし。

        Resource Packages とやらも同じように感じますが。

        >その結果、普通のウェブサイトでもあまりmhtmlって使われてないのだし。

        使われないのはメンテの問題じゃなくてブラウザが対応してないからでしょ。

    • by Anonymous Coward

      はげどう。無意味なAnti-MSイクナイ

  • by ef (25263) on 2009年11月27日 9時24分 (#1678991)

    .docx がファイルをもっていたら、拡張子を .zip に変えて開いてみてください。
    .jar も .xpi もZIPですね。
    zip の書庫ってかなりさまざまなファイルに使われていますね。

  • 普及するかどうかは微妙。デザイナさん次第だと思います。

    エンジニアとしては余りまくってるCPUリソースを使うことで
    ネットワークがかるくなるんだよよよ!とウキウキですが、

    ヘッダを追加して、コンテンツをzipして別途アップロードするのはデザイナさんなので、
    面倒なのでやらないかもですね。んで、やらなくても見れてしまうし。
    更新し忘れでzipしたコンテンツが古いままとか。

    mhtmlなら複数のファイルがひとつになるのでデザイナさんにもメリットが目に見えるのですけど。

    phpのアクセラレータのように全自動でzipファイルの生成とキャッシングする仕組みを作ればいいですけど、
    だったらサーバサイドの変更がいらないっていう仕様の意味がなくなります。

    #検索エンジンのクローラはどっち見に行くのかしら。両方読んで内容比べて。
    #→帯域圧迫→マズー

  • by Anonymous Coward on 2009年11月26日 19時08分 (#1678665)
    ただ、サーバサイドの管理ツールなどが対応していないと、ZIPに含まれるファイルと
    生で提供されるファイルの同期を取るのが厄介という問題が出てくるね。
    つまり、この機能を使うブラウザでは表示が古いというミスが起き易くなると。

    だから、運用面も考えればブラウザだけ対応すればいいとは言えません。

    #面白いし改変コストの低い方法だし有効性は高いから上手くやれば良い結果は得られそうだ。
    • 場合によっては文字列だけが更新されていて、重い画像はブラウザのキャッシュにあるからいりません、なんていう場合もありますよね。毎回ブラウザのニーズに合わせてzipファイルを生成していては負荷が高いでしょうし、キャッシュにあるデータまでzipされて送信されると却ってデータが大きくなりますし、バランスを取る必要が出てきそうですね。

      --
      人生は七転び八起き、一日は早寝早起き
      親コメント
      • > キャッシュにあるデータまでzipされて
        ブラウザに限らずsquidなどのキャッシュサーバにも同じことが言えそうです。

        *.zipなどのアーカイブファイルはそうそう頻繁に更新されることもないと考えてsquidの refresh_patternで最低キャッシュ時間を0より大きく設定していたのですが、今後は止めた方が良いかもしれません。

        --
        運転手は運転がお仕事。笑うのはブギーポップにはできない僕らのお仕事。
        親コメント
      • by Anonymous Coward

        > キャッシュにあるからいりません
        という判断をするのはブラウザの側でしょ?
        前回から更新された、まだ画像にない分の画像だけをzipにまとめて送ってくださいなんて、動的に生成しなければ絶対に無理じゃありませんか。
        それにzipだからって圧縮する必要はありません。どうせ中身のほとんどは圧縮がほとんど効かない画像類なんだから、無圧縮で格納すればよろしい。それなら負荷がHTTP/1.1のpersistent connectionより高くなることはありえません。

        • by WindVoice (14680) on 2009年11月26日 22時07分 (#1678800) 日記

          Goal [limi.net]の内容とImprementationをざっと読んでみたんですが、Webページひとつひとつを全部zipにまとめることを意図したものではなさそうですね。たとえば/.-Jで言えば、各ページに共通のアイコンやスタイルシートなどをzipにしておいて、そのページ固有のHTML等はzipとは別に取得するというような雰囲気(href="/static/site-resources.zip"などと例にある)です。

          PNGの画像をzipにすると却ってサイズが増えるのでは? なんていうFAQもありますが、そこは確かにご想像のように無圧縮のzipが使われることもあるだろう、などと書かれています。

          --
          人生は七転び八起き、一日は早寝早起き
          親コメント
          • Re:裏技的手法ですね (スコア:5, すばらしい洞察)

            by albireo (7374) on 2009年11月27日 4時50分 (#1678949) 日記

            というかみんな圧縮にこだわりすぎ。
            これはどちらかというと複数ファイルをアーカイブすることによりHTTPリクエストの数を減らす方がメインの目的だと思うんだけど。
            データ圧縮は回線が十分高速になると体感上の効果は小さくなるけど、HTTPのリクエスト/レスポンスを減らすのは高速回線でもそれなりにメリットが期待できる。

            PNGのサイズが多少増えたとしても、数がたくさんあればリクエスト回数が減ることによるレスポンスの向上がそれを上回ることも多いでしょう。

            --
            うじゃうじゃ
            親コメント
    • by Anonymous Coward
      ZIPに含まれるファイルの方を、Firefox3.7では見られませんとかいうような内容にすれば、万事解決だ。
      • by Anonymous Coward
        中身を全部 NOFRAMES にして、フレーム側には「このページは、フレーム非対応のブラウザで見てください」とか書いておくようなもの?

        #関係ないけど、「構成ファイル」っていわれると configuration file みたいだ
    • by Anonymous Coward
      当然mod_deflateのようなモジュールで(mod_zip?)自動的に生成したりするんでしょ? BlogのRSSを手動で更新する人がいないのと同じこと。
    • by Anonymous Coward
      圧縮して送信というと FidoNet の BBS を思い出します。
      パソコン通信の FidoNet なんですが、ホストの方で複数の会議室の未読部分を圧縮してくれるので、その圧縮ファイルを受信していました。

      掲示板のテキストだけだったので、圧縮効率は高かったと思います。
  • by Anonymous Coward on 2009年11月26日 20時47分 (#1678746)

    例を挙げると、こんなかんじかなぁ

    1.クライアントがサーバーにindex.htmlをくれという
    2.サーバーはindex.htmlを返しつつ、「うちはzipに対応してるよ」ということをヘッダで示す
    3.クライアントは、index.htmlからサーバーへの画像やCSSのリンクを抽出し、
        こんなファイルがほしいよ〜(zipで)とリストを送る
        (キャッシュにあるものはリストに含めない)
    4.サーバーは送り返すファイルをまとめzipで返す
        (zipにまとめられなかったものもリストで返す)
    5.クライアントはzipにないものを個別アクセス

    こうすれば、Webサーバーを対応させれば、その上で動くプログラムには影響がないかな

    • by s02222 (20350) on 2009年11月26日 21時58分 (#1678796)
      リンク先をざっと読んでみたところ、サーバの対応は要らなさそうな。
      1. htmlのヘッダに<link rel="resource-package" type="application/zip" href="/static/site-resources.zip" />とかそういう記述があればzipファイルを取ってくる
      2. zipファイルには中に何が入っているかなどをを示すmanifest.txtが先頭に格納されている
      3. manifest.txtを参考にhtmlの残りをパーズ。zipファイルに含まれているリソースは改めては取りに行かず、zipから取り出して使う

      かな?

      あんまり動的なページをzipに含める事は考えていないように見えますね。 固定のスタイルシートやら飾りやらを送ろうと言うのがあくまで主体のような。 まあ、手法が一般化すると今度はファイルの更新に自動対応するapache用のモジュールも作られるであろう事は疑う余地がありませんが。

      だとすると、href="/static/site-resources.zip"の部分に飛んでもなくでかいファイルを指定してやるとか、無限にデータを投げ返してくるcgiやらを指定してやるとかすることで、Resource Packages対応のブラウザでは閲覧がめんどくさいページが簡単に作れちゃうような気がします。そんないたずらを仕込む前向きな理由は思いつきませんが。「Resource Packagesのダウンロードが完了していない段階でブラウザがやることが無くなったら、zipは見捨ててhttpでファイルを取りに行く」みたいな例外処理を入れておくのかな? それはそれで本末転倒のような。

      親コメント
      • by ruto (17678) on 2009年11月26日 22時31分 (#1678819) 日記
        Resource Packagesではmanifest.txtファイルにアーカイブ内の全てのファイル名を記述しておきます。
        このファイルはZIPファイルの最初のファイルでなければなりません。
        ZIPファイルは全てを読み込まなくても中身が読めるので、とりあえず読めた部分まではZIPファイルの中身を利用できます。
        親コメント
        • by Stealth (5277) on 2009年11月27日 11時12分 (#1679041)

          つまり「とりあえずこれらのファイルをまとめて zip にして……」とエクスプローラー上でさくっとまとめる、といったことはしにくいのですね。
          なんかオーサリングツールでの支援とかが得られなかったら対応するサイトが極めて少なくなりそうですね。

          親コメント
  • by duenmynoth (34577) on 2009年11月26日 19時09分 (#1678666) 日記
    アナログモデムの頃は通信プロトコル自体にデータ圧縮があったと思うので、
    いろいろ違いがあるとはいえ、やっと追いついた感じ?

    #あ、JIGブラウザも似たような事をやってるんでしたっけ
    • by Anonymous Coward

      >アナログモデムの頃は通信プロトコル自体にデータ圧縮があったと思うので、
      HTTPもサーバクライアント間でネゴシエーションしてgzipやdeflateで圧縮して送る技術は昔からありますよ

      • そうなんだよね。

        この記事もHTTP1.1でgzip圧縮かけるのと、zipにまとめたファイルをダウンロードするのと、どんだけ違うの?って思った。初回表示以外はキャッシュが働くこととか、スクリプトや装飾画像は複数のページで共有されていることも考えると、全く意味がないと思う。

        親コメント
        • 「圧縮する」ことよりも「まとめて送る」ことに価値があると思います。
          a.htmlが a.css と b.js を読んでる
          b.js では、動的にc.css を読んでる
          (以下略)
          みたいな感じで必要なファイルが連鎖していくと、
          順次ファイルを解析しては次のファイルをリクエスト、という流れで
          表示に必要なファイルが全部揃うまでにかなり時間がかかります。

          それを、最初のa.html を取得する時点で、必要になるファイルを一式全部一緒に渡してしまえば、
          「リクエストしては結果が届くのを待つ」時間がなくなりますので、その分の高速化は期待できるかと。

          問題は、そういう
          > 初回表示以外はキャッシュが働くこととか、スクリプトや装飾画像は複数のページで共有されていること
          を考えると、オーバーヘッドが大きいってことですよね。

          最初のa.html のリクエストの段階で、
          ブラウザから手持ちのファイル群について、If-Modified-Since 群を送りつけて、
          サーバからは、無い/新しいファイルだけをまとめてzip転送する、とかすれば効率化は図れそうです。

          そんな感じでいろいろ工夫は出来そうですが、
          そもそもどのファイルが読まれるか分からない状況ではそういう候補ファイル群をリストアップすることすら難しいでしょうし、
          プロトコル的に拡張しないといけないし、サーバ側の対応しなきゃいけないので、実現は難しいでしょうね…

          親コメント
  • rsync -z (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2009年11月26日 21時15分 (#1678762)
    ですね。わかります
  • 契約しているWEBサーバがなかったので、無料のWEBサービスのアカウントとって
    実験してたら、アカウントごと消されたっけ...

    私の場合は、html内に圧縮したデータをエンコードして組み込んでましたけどね。
    だから序文は普通にhtmlなメッセージが入っていて、非対応なブラウザにはそのメッセージだけ
    みえるという形。
    まあ、それ用のブラウザ構築するまでにはいたらず、飽きてしまったのだけど...

    みんな似たような事を考えるみたいですね。
  • by kabuchan (37144) on 2009年11月27日 9時54分 (#1679006)
    • 意図しないファイルをアーカイブしちゃうかもしれないので宝探しゲームが流行る?
    • zipの中までアクセス制御とかrewriteとかかけられないのでうれしくないなぁ
    • そもそも取りに行くの多重化になってるんだから意味ないんじゃない?
  • ZIPの暗号化の強度については門外漢なのでわからないが、
    応用可能な技術だと思う。

    HTTPSとdeflateを絡めると、JavaScriptやCSSの読み込みに失敗したりとか
    はまった経験があるので、そのあたりも含めてぜひ議論して欲しい。
  • by Anonymous Coward on 2009年11月26日 19時03分 (#1678661)
    普及するよう、お祈り申し上げます。
  • by Anonymous Coward on 2009年11月26日 19時09分 (#1678667)

    ・従来型のデータを更新したときにzipを更新し忘れる、またはその逆
    ・従来型のデータとzipの内容をわざと違うものにして遊ぶ
    ・展開すると膨大なサイズになるzipで攻撃

    というかページの表示が遅いのは転送のオーバーヘッドのせい
    ではなくてやたらと凝ったスタイルシートの(ry

    • by upken (38225) on 2009年11月26日 19時38分 (#1678684)

      サーバー側がリアルタイムに圧縮するのでは?
      deflate のファイル複数版みたいな挙動を想像したのですが

      親コメント
      • by feenal (37359) on 2009年11月27日 18時33分 (#1679432)

        いや、一応ウェブ管理者が自分で作成するらしい。
        1. 収めるファイルを調べる
        2. zip作成
        3. html内にlinkタグでリソースzipを指定
        だからやっぱり入れ忘れる事もあるんだろうね。そのへんは専用のツールでどうにかするんでしょう。

        でも私もサーバ側で自動生成のほうが面白いと思いますね。
        httpレスポンスヘッダに追加するんだろうなー

        親コメント
  • by Anonymous Coward on 2009年11月26日 19時11分 (#1678670)

    OperaにはDelayed Script Executionというオプションがあり(Opera:Config >)
    先にページを読み込んでからスクリプトを読んで後から適用する、というものなんだけど、
    これで表示は随分速くなる。

    ・・・というか。
    ウェブサイトにでかい.jsファイルやCSSをくっ付けなければ良いだけなんだけどね。

  • by Anonymous Coward on 2009年11月26日 19時50分 (#1678700)

    いっそサーバサイドのファイルシステムと合流して、zipなディレクトリにしてしまえばいいかも。
    って、静的なファイルって今時無いか。

  • by Anonymous Coward on 2009年11月26日 19時51分 (#1678702)
    ついでにEPUB [wikipedia.org]もレンダリングできるようになる予感。
  • by Anonymous Coward on 2009年11月26日 19時55分 (#1678705)

    tar+gzとかの方が良くないか?

  • by Anonymous Coward on 2009年11月26日 20時02分 (#1678715)
    cssやjavascript、バナー画像とか、キャッシュが効く要素の判断は誰がいつやるの?
    何も考えずに要素全てを固めて転送じゃあ、かえって遅くなったりする事もありそうじゃない
  • by Anonymous Coward on 2009年11月26日 20時08分 (#1678720)

    Webを一つの場としてページを構成することがHTMLの良さだと思うんだけど
    画像はあのサーバとかこのサーバから、CSSはこのサーバ……、なんて
    バックエンドがDBなんてことは昨今当たり前だし

    あんまり意味ないと思うけどなぁ

    それよか、HTTP互換の新しいプロトコルを作った方が筋が良い気がする
    もちろんW3Cとかみたいな標準化組織を通して

  • by Anonymous Coward on 2009年11月26日 20時19分 (#1678729)
    zipでくれ
typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...