Software Design 2007年 09月号にmod_rewrite活用テクニックを書きました。
公式ドキュメントでも黒魔術などと称されている悪名高いモジュールmod_rewriteですが、要は設定例や内部でどのように動くかが解説されていないためによくわからないモジュールとされているだけであって、それらを理解してしまえば普通に使いこなすことができるようになります。
例えば以下のことを知らないような人向けに書いてみました。
prototype.jsを10KBにする方法やSafari と gzip 圧縮 JavaScriptなどですでに述べられてることですが、mod_deflateでリクエストがある度にアセット（CSSやJavaScript）にdeflate圧縮をかけるのは、deflate処理が軽いからと言っても、塵も積もれば馬鹿にならない（WWWサーバーやAPサーバーに本来使って欲しいCPUリソースを蝕む）訳で、deflateしたいアセットには予めgzip圧縮してそれを配信し、サーバーのCPUリソースに優しいようにしましょう、というお話。
普通の帯域節約術としては、mod_deflateでdeflate圧縮するとか、CSSやJSファイルのHTTPレスポンスヘッダにLast-ModifiedやEtagを追加しておいて、ブラウザがHTTPリクエストヘッダにIf-Modified-SinceやIf-None-Matchを付加するようにし、コンテンツが変更されていなかったら304 Not Modifiedを返すという方法を取るかと思います。
しかし、HTTPサーバーはコンテンツの数だけ304 Not Modifiedを返さないといけないため、その分帯域を消費しますし、またCSSや画像などのパーツの304 Not Modifiedが返ってくるまで、そのパーツのレンダリングが行えないという問題があります（つまり体感速度に影響します）。
今回紹介するのはExpiresヘッダやCache-Control: max-age=31536000を活用して、CSSやJSなどのファイルをリクエストする際、それらのファイルが変更されない限り、If-Modified-Sinceなどのリクエストをそもそも発生させなくする方法です。
ApacheにはコンテンツのMIME-typeに応じてフィルターをかけるAddOutputFilterByTypeディレクティブがありますが、Apache 2.1 以降で非推奨になり、代わりにmod_filterでフィルターをかけることが勧められているようです。
しかしながら、mod_filterの実例があまりにも少ないため、どう使っていいか分からないのが現状です。なので、AddOutputFilterByType DEFLATE text/htmlを書き換えてみることにしました。
naoyaさんが公開されてるInside Hatena Bookmark’s Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。
なので、経験を元に書いてみることにします。
『SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも』という記事があるように、 パスワードを送信する段階で初めてSSLを使うはなく（パスワード入力フォームはHTTPで送信され、そのページのformタグのaction属性がhttpsになってる状態）、その前の段階でパスワード入力フォームが改竄されていないことを証明するために、パスワード入力フォームもHTTPSなページで表示することが望ましい状況になってきました。
で、そんなような仕組みを作った後で考えないといけないことは、認証後どうやってHTTPに戻すかと言うこと。つまり、すべてのページでHTTPSを使うのはサーバーに負荷がかかり現実的ではないので、認証する部分だけHTTPSで改竄や盗聴を防ぎ、その他のページはHTTPで済まそうという事です。図にするとこんな感じ。
| クライアント | 経路 | サーバー | 経路 | クライアント | |
|---|---|---|---|---|---|
| ステージ1 | ログインフォームへのリンクをクリック | HTTPS | ログインフォームHTMLを返す | HTTPS | ログインフォームを得る |
| ステージ2 | ログインフォーム送信 | HTTPS | ログイン処理 | HTTPS(*1) | ログイン後の画面 |
普通に考えると、パスワードを認証後のHTTPレスポンスヘッダ(*1の部分)でLocation: http://www.exmaple.com/logined.html
とかすればいいんじゃないの？と思うのですが、そうするとIEで「セキュリティーで保護されていないページに移動しようとしています」というような警告ダイアログが出てきてしまいます。
そんな警告ダイアログが出るのはユーザーフレンドリーじゃないので、それを防ぐ方法。
Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。
このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。
Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。
そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。
Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。
このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。
Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。
そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。
Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。
このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。
Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。
そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。
Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。
このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。
Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。
そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。