HTMLは圧縮して転送した方が効率良くないですか？

何らかの共通の方法で可逆圧縮されたHTMLをサーバにアップするようにし、
それがダウンロードされたら、ブラウザがそれを解凍し、復元する。
まぁJAVAでいうJAR形式みたいな感じです。

こうした方が圧倒的に転送効率が上がると思うんだけど、どう？

既にあります

当然ブラウザには圧縮に対応した解凍機能を付ける必要はあるけど、
ＣＰＵなんかも高性能化していることだし。問題ないでしょ。
生でTEXT（HTML）送られるよりは。

圧縮が面倒くさいっていうならエディタ自体がHTMLとして保存する時に
圧縮して保存するように浸透してけばいいだけだよね。GIFとか画像みたいに。

今までそうされてなかったのが不思議なくらいな案だと思うんだけど。
まぁ結局浸透しなきゃ意味無いが。

やっぱあるよね。
じゃあ何で浸透してねぇんだろう？

ちなみにその在処は分かります？

RFC2616のContent-Encodingに関する説明を読みましょう。

IEとかってContent-Encodingのgzip扱えそうだよね。誰か実験
してみた人とかいない？

>7
gzipでリクエストだしていたよ。
でgzipでレスポンス返すとちゃんと表示してれた。

をー、使えるのか。
となるとあとは、サーバー側でgzip実行するオーバーヘッドを
考慮して、いいカンジだったら実装すればよいのか。ふむふむ。
キャッシングとかもするとよりよいか？

・・・って、もうすでにどっかのメーカーが実践してそうだな。
しかも特許とってたり(w

キャッシングはいいですね。
今度実装してみよう。

ぁゃιぃ系でつかわれてる掲示板スクリプトのくずはすくりぷとでは既に gzip を用いた圧縮転送を実現していますよ。

http://members.tripod.co.jp/kuzuha/

# とはいえクライアントが gzip を受け付ける場合に限った場合ですが。
# 以下の処理でいいみたいです
# print "Content-encoding: gzip\n\n";
# open ( STDOUT＠｀ "| $gzip -1 -c" );

レスポンスありがとうございます。
なるほどgzipはそういう使い方が出来たんですね。
ところでUNIX以外でgzip圧縮って出来るのかな？（無知）
もしくは.gzと.zipって圧縮アルゴリズムは同じ？

あとそれとは別の話として、
TEXTの汎用で標準な圧縮フォーマット（GIFのような）は
あったら良いなぁと思いません？

.gzと.zipは違うもの。で、もちろんUNIX以外でもgzipは使えるぞ。
ていうか

>あとそれとは別の話として、
>TEXTの汎用で標準な圧縮フォーマット（GIFのような）は
>あったら良いなぁと思いません？

いらないだろ。もう一度頭冷やしてよく考えろ。

テキストととか圧縮ききやすそうなものは
ルータレベルで圧縮かかってるんじゃないの？

>14
モデムとかは圧縮してると思うけど.(思うしか言えないでごめん)
ATMなんか48byte単位で圧縮しても効果はあまりないと思う。
どっちにしても上の層でまとめて圧縮した方が効果があるのでは？

ルータというか Layer7 より下の圧縮がうまくいくとは限らない。

ルータで圧縮するときは PPP レベルでの圧縮になるが、テキストのようなデータは圧縮率がよく
スループットを稼げる半面、画像や zip/lha などのすでに圧縮されているファイルに対しては
逆にサイズが大きくなってスループットを落とすこともある。
だからルータレベルで圧縮する際には、トラフィックの性質をある程度正確に
理解している必要がある。

ルータに対する負荷もバカにならない。とくに専用ハードがない限り、暗号化と圧縮を
併用するのは危険。

M$はchm使いたがってるね

＞１７
そうなの？ヘルプファイル専用では？
作るの面倒だし。

>17
M$-Stac でわ？ rfc2118

圧縮するよりHTMLや画像ファイルやclassファイルなどを一まとめにして転送・表示できるプロトコルがほしい
HTTPでも出来ないことはないと思うけど・・・

以前、ルータ間でcodecする場合と、end-to-endでcodecする場合の
パフォーマンスをシミュレータ使って比べてた。OPNETってシミュレ
ータのトレーニング項目だったよ。end-to-endのほうが速かった気
がした。

ISP側にMIME: text/* とかのコンテンツだけ圧縮がかかる
proxyサーバをおいて、細い線のこっち側のその逆をするような
proxyを置くようなメカニズムってないのだろうか...
サーバとかプロトコルとか変更しなくても出来そうだけど。
負荷の問題が発生するかな。

ルータのPredictorとかでかかる圧縮より圧縮率高そうなんだけど。
だめかなぁ って、誰かやってません？

サーバに無駄な負荷がかかって余計に重くなりそうですな。

サーバ側なら予め圧縮しとけばいいのでは？

>>23 ですよね。SSLとかより重そうですよね。

>>24 そうじゃなくて

Webサーバ -太い線-> ISPの圧縮付きproxy --細い線-- 伸長付きproxy　-LAN--> Webブラウザ

ってことですよ。これなら、どんなコンテンツにも対応できない？

サーバ＆プラウザの対応が不要な点でグー
あと、POPやNNTPにも対応できそう
proxy作って！>>25

圧縮の問題は、処理に時間がかかって結果として転送より遅くなって
しまうと意味がないんじゃないか、という……。いや、
トラフィック的にはいいんだろうけど。キャッシングである程度
緩和できるかな？ HTTPアクセラレータ(リバースプロクシ？)で
その手の製品ないのかな。

あと、HTTPに限っていえば、トラフィックのほとんどはtext/*
以外じゃないのかな。画像をてきとーにまびいたほうが効果あがる
よん、とかIntelあたりがいってたような。

>>26 NNTPとかPOPとかには効果的かもしれませんね。
でも、今思ったんですが、sshのport forward に圧縮かませれば
結構ゆけたりして... どうなんでしょうか。
>>27 その分析は正しいですね。たぶん、Webでのコンテンツの
ほとんどは、ふつうの可逆圧縮が効果的なものじゃないですよね。
27さんが指摘しているように、Intelがそんなことを言っていて、
なにか、Intel の実装があったような気がしましたが、よく
知りません。知っています？

>>27
うちのproxyのトラフィックのだいたい５割は画像で、
４割はわけわからない圧縮ファイルとかいろいろ。
のこり１割がテキスト。
圧縮のききそうなものはあまりないのが実際のところかな。

2chなら効果があるんだけどねぇ

context-encoding: gzip なストリームを展開して流してくれる
proxyならIBMが出しているけどね。逆はみたことないなぁ。
でも、delegate ならHTTPヘッダも含めて、外部フィルタ使って
いろいろ変換できるから、自分でちょっとスクリプト組めばすぐ出来そうだ。

ちなみに以前同じようなことを試したときは、
proxyと自分のマシンが速度が遅くても順調に
データが流れているときは、ブラウジングの
体感速度が上がった。けど、データがつっかえ
つっかえ送られてくるときは、gzipってある程度
データが来ないと展開できないから表示されはじめる
までの時間が長くてかえっていらいらした。

ちなみに以前同じようなことを試したときは、
proxyと自分のマシンが速度が遅くても順調に
データが流れているときは、ブラウジングの
体感速度が上がった。けど、データがつっかえ
つっかえ送られてくるときは、gzipってある程度
データが来ないと展開できないから表示されはじめる
までの時間が長くてかえっていらいらした。

論文も出てるみたい。pass掛かってるけど。
USENIX99かな？
Compression Proxy Server: Design and Implementation
http://www.usenix.org/events/usits99/chi.html

>>32
そういう意味では28の言うようにssh使って圧縮した
ほうがいいかもね.
gzipでも時々フラッシュしたらいいけど。

http://itpro.nikkeibp.co.jp/free/NIT/NEWS/20000919/1/
自動的にコンテンツ圧縮、フォーマット変換などを行い、Web アクセスを高速化する
Transparent Proxy が発表になった。PacketShaper の製品。

ここで総括されているね。
mod_gzip というものもある。
http://apachetoday.com/news_story.php3?ltsn=2000-10-13-002-01-NW-HE-SW