FasterFox（Firefoxアドオン）に関する意見っぽいもの
まずはじめに、私はwebサーバ管理者でもないし、プログラマでもない、ということは明記しておきたいなと。Linuxをたまに触る程度のWindows使いですよ、と。つまり、正確なところは知らないので責任は持ちません。でも、異論反論は歓迎します。
はてなブックマーク - FasterFox問題のフォローアップ - Mozilla Flux
Fasterfoxの先読み機能とサーバー当たりの最大持続接続数の話についてだけども、もっぱら後者について焦点が当たっているので後者について考えてみる。まずこの機能の是非だけども、Windowsには窓の手というフリーソフトが存在する。
窓の手でインターネット速度向上/無料でパソコン最適化！
このソフトで「同時に張れるコネクション数の上限」がIE版FasterFoxにあたると思うのだけれども（筆者の勘違いで違うというのならご容赦くださいな）。
私の知る範囲では、この数を増やすなという話を聞いたことがないんですよね。この手のハック自体は、Firefoxが無かった時代からすでに存在していたと。ま、昔の話なのですけども。なもんで、何をごちゃごちゃ今更言っているんだみたいな。
持続的接続を使用するクライアントは、サーバへ維持する同時接続の数を制限すべきである。 シングルユーザクライアントは、どんなサーバやプロクシへも 2 接続より多く維持すべきではない。
RFC 2616参考日本語訳から、どうしてFasterfoxが非難されるのかという最大の根拠がこれ。原文では"SHOULD NOT"になっているからすべきではない、というもの。RFC 2616なんかは1999年6月ともうかれこれ10年は経つ枯れたものだと思いますが、この文言が当時から10年経って進化したハードウェア、ネットワーク環境でもそのまま尊重されるべきものなのか、という疑問が一つ。
"SHOULD NOT"で私の記憶に強く残っているのが、若干本題と毛色が違うのだけれども、XHTMLのMIME Typeの問題かなと。XHTML Media Types (ja)なんかの時は、ほとんどのXHTML familyに対してapplication/xhtml+xmlが"SHOULD NOT"とされて結構な論争になった名残が今でも残っているのだけれども、現実にIE（正確にはWindowsのレジストリ）のサポートの関係で、application/xhtml+xmlをwebサーバからレスポンスを返すよう仕向けるのは、現実的な選択肢ではないというのは誰もが知るところだと思う。要するに、W3CノートとRFCという違いはあるけど"SHOULD NOT"は意外とアテにならない一面もあるということを述べておきたい*1。なお、先に挙げた文章はXHTML Media Types ― 第二版として最近改訂されており、だいぶ文言が変わっている。
KoshianX referred id:momdo さんの反論かー。俺もapache2はほとんどいじってないんで、具体的な対処法があるなら知りたいなー。 2009/02/05
http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/Rockridge/20090205/1233789982
周知の通り、apache2のほうが今やメインストリームな訳で、id:koshianXさんのapache1.xでの経験上のコメントが今の環境でどこまで通用するのかな、という疑問はあったりなかったり。
mod_limitipconnで検索したら、MIME Typeごとに最大接続数を変えることができるみたいだけど、text/html以外を制限するとか、そういうチューンナップじゃダメなんですかね、よくわかりませんが。
とまあそれっぽいことを並び立ててみましたが、はてさて付け焼き刃でどこまでいけることやら。
