Webブラウザにキャッシュさせない

先日、会社で「Webサーバ側のほうで、クライアントにキャッシュを残させないように制御ができるか？」ということが話題になりました。使っているシステムでどうもブラウザ側にキャッシュがないので不思議に思ってそんな話題が出たようです。
　
まあ、HTMLタグとかで制御できそうなものだけど、実際はどうやるのかな・・・、と思って調べてみました。たぶん、googleでこんなワードで検索したらいけるだろう。。。

「Webサーバ　設定　クライアント　キャッシュ　残さない」

あ、あったあった（＾＾）　
http://blog.look-ss.jp/article.php/2008092600255048　のサイトが詳しいです。

HTMLのメタタグで制御するみたいですね。あとは画像ファイルとかまとめてやりたい場合、Apacheだとパラメータ指定で対処できるようですね。非常にわかりやすいです。

まあ、当たり前といわれれば当たり前ですけど、これはあくまでサーバ側がクライアント側にキャッシュをしないように依頼しているだけで、クライアント側（あるいは途中のプロキシ）でそれを無視するようなしくみがあった場合にはその限りではない、ってことですわね。

あと、以前別件で調べ物をしたときに、たまたま見つけた記事が今回も見つかったので紹介しておきます。こちらは＠ITさんです。

http://www.atmarkit.co.jp/fjava/rensai2/webopt12/webopt12.html#ap05

こちらはサーバとブラウザのキャッシュのしくみが原因でWebサーバを1台で運用するより、複数台をロードバランサでバランシングするほうがかえってレスポンスが悪くなってしまった、という話です。

最初、「不思議なこともあるなぁ・・・」と思っていたのですが、よくよく読むと納得です。めったに更新されない画像ファイルなどを配信するシステムだと、画像ファイルはクライアント側でキャッシュされた毎回は取りに行かないのが普通です。

しかし、負荷分散対象の各サーバ毎に、HTTPレスポンスヘッダで返すETag（ファイルの識別情報のようなもの）が異なるため、クライアントがたまたま同じサーバに振り分けられたときしかキャッシュが効かず、その場合には再度画像データを要求してしまう、ということです。これだとクライアントの数が増えれば増えるほど、影響が大きくなりますね。

こちらのサイトには、Apacheの場合の対処法なども紹介されています。

Webキャッシュまわりの話もけっこう仕事で出てくるので、また何かあれば紹介します。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---

Webアクセス解析

ぢろーらもがお世話になっているこのブログ、OCNさんの「ブログ人」では、無料プラン（OCN契約者は無料、ということ）でもアクセス解析ができます。こちらのアクセス解析機能でも、ある日にどのページにどのくらいのアクセスがあったか、どんなキーワードで検索されたか、といった情報はわかります。これはけっこう見ていて面白いです。

毎週このサイトでも、どのような検索エンジンからアクセスがあったか、なんてことは調べています。まあ、まだまだアクセス数が少なく、せいぜい1日に同じキーワードは１，２個だから今の段階では「どんなキーワードで参照されるのかな？」を参照しているくらいなものです。もっとアクセス数が増えればサイトのIn/Outとかももっと注目するかも。

こういう感じなので、検索していただいたキーワードに関して追加情報をつけてみようかな？なんて考えているわけです。

まあ、ぢろーらもは今はまだ研究段階でどういうことをかけばどんな反響があるかを知りたい、という感じなのでやっているからまだいいのかもしれません（本当は浅羽由紀さん関連でもっと貢献したいのですが）。

これが企業のWebサイトになるだと、Webサイトには明確な目的があって、たとえば「このサイトをみて商品を注文してもらえるようにする」というように直接の利益を生むようなことから、「まずは資料請求してもらえるように」とより詳しく知ってもらうための第一アクションをとってもらう、といったことが必要になります。

そのためには、Webアクセス解析をして、コンバージョン（完了）率を高める、そのためにページ途中での離脱率を低くする必要があります。そこで、Webアクセス解析を行なえば、「どのページの離脱率が高いか？どのページに対して工夫が必要か？」と分析し、その結果に基づいて実際に改修が必要となります。

たとえば、自分でApacheを立ててページもすべて自分で作っている、という方は、アクセス解析はWebalizerを使っているかもしれません。こちらはフリーのソフトですが、日、週、月のデータ、In/Outページ、リファラー、検索文字列、User-Agent（ブラウザ情報）などをもとに分析することが可能です。こちらはhttp://www.ahref.org/doc/webalizer.html　などが参考になります。

フリーで有名なのはGoogleAnalyticsですかね。シェアもけっこう高いです。こちらもいろいろ情報は出回ってます。レポートの表示内容を柔軟にかえることができます。一度こちらも講習を受ける機会がありましたが、そのときも「コンバージョン率をどう上げるか？」という点からも説明がありました。

有償のソフトだとVisionalyst、WebTrendsなどがあります。これらはより「マーケティング」や「システム」といったことを意識しています。大量のログを処理し、細かく分析が可能です。広告の効果測定とか、ユーザ単位の分析などが可能です。まあ、個人特定はWebサイト側でCookieなどの手段で個人が特定できるように作りこみが必要にあります。もちろん、「WAF製品説明」でも少し触れましたが、Cookieが平文で送信され、そこに含む個人情報が推測されやすいとセッションハイジャックの危険がある、という別の問題もありますが。
　
ちなみに、Webアクセス解析の疑問に関しては、http://an-k.jp/blog/archives/328　など詳しく説明されているサイトもあります。

そういえば、ぢろーらもはWebアクセス解析ソフトの導入支援、サポートなどに携われるチャンスがあったのですが、どういうわけか諸事情でそのチャンスがすり抜けていきました・・・これらの仕事に携わっていたら、もっと早くからマーケティング（Webマーケティング）について関心を持てたかもしれない、と思うと残念な気持ちもあります。もちろん、今は今でいいですが、今後もっといろいろと勉強できたらと思います。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---

今週の検索ワード：非IT系：2010年6月7日～13日

今週も性懲りもなく（？）、おもちゃ箱サイトの検索ワード分析ですm(_ _)m。現状だと、検索ワードでひっかかってくるのは、IT系が多いようです。まあ、たとえば「どっかに遊びに行った」的なことだと、割と詳しく書いている人がほかにも大勢いらして、このサイトまでは辿り着かないかもしれません。もちろん、よっぽどその場所を気に入っていて、かなりマニアックにかけるようになれば別なんでしょうけど。

以下、今週の検索ワードをいくつか紹介します。

「大田区 浅間神社　お祭り」

やっぱり大田区にお住まいの方は地元のお祭りには関心あるようですね。これだけ多くの方が気にしているのであればもうちょっと詳しく書けばよかったかな。なので、「春日神社お祭り」のほうはもう少し内容を追加してみました。

あと、10月12日は池上本門寺御会式に行く予定です。こちらも外せないんですよね。
　
「多摩川　潮干狩り　場所」

できるのかなぁ？ああ、河口のあたりだとできるのですね。

大田区、という意味では去年は城南島海浜公園に行きました。あまり水がきれいではないので油とかも浮いたりしていたので、妻は砂出しとかもかなり苦労していました。

この公園自体はぢろーらもは好きです。天気のいい日に東京湾を眺めながらぼーっとしたり、散歩したり。大田区でもこんなによい公園があるんですね。

あと、東の空が開けていることから、初日の出見にくる方はけっこう多いです。そういえば1999年のしし座流星群のときもここに行ったけど、深夜にも関わらず大勢の方がいらしてました。ピークの時間が昼になってしまい、夜に見える流星の数は1時間に数十個くらいにとどまりましたが、やっぱりきれいでしたよ、流れ星が見えるたびに「あっ！」とか、けっこう大きいのが流れてきたときに「すげー」とか周りから声が聞こえるのもなんかよいですね。一種のお祭りみたいな感じでした。

「じろーらものおもちゃ箱」

惜しい…（笑）。わたくしは「”ぢ”ろーらも」ですよ（笑）。

もちろん片仮名で「ジローラモ」だと、本家（？）パンツェッタ・ジローラモさんが検索されるのですけど、googleでひらがなで「じろーらも」と検索したら、パンツェッタ・ジローラモさんだけでなく、わたくしぢろーらもも割と上位のほうに来ました。おやおや・・・。

「リオンドォール ユネッサン　ランチ」

こちらは賛否両論あるようですね。まあバイキング（ビュッフェ）なのでそんなにいいものを出していたら破産してしまいます。値段の割に、と考えればぢろーらもはまあ納得できるかな、というところです。食べ放題のステーキは成形肉のようですが、ぢろーらもは抵抗なくおいしく食べれます。最近のものは割とおいしいのではないでしょうかね。

「プッコチュ　大田区」

これで妻の実家の焼肉屋：山水苑を検索していただけるのはありがたいです。「焼肉山水苑：大田区：蒲田」でも紹介していますが、蒲田駅に近いのであれば是非いらしてください。辛いの好きであればプッコチュ入りのチヂミはきっと気に入ると思います。もちろん、我々もまた山水苑に足を運んだ時はブログアップしますよ。

来週は「春日神社」とかはいってくるかな・・・。

あとは浅羽由紀さんの路上ライブも行ければ行きたいので、そのことを書ければいいな、と思っています。天気が心配ですけど、まあそのときの流れにまかせてみましょう♪

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---

SEOを考える：おまけ

以前SEOについては「SEOを考える」の記事を書きましたが、自分の無知をひけらかしつつも性懲りもなくSEOの続き（汗）。しかも、今回はおまけの記事でございます・・・。

こちらももしかすると小手先のテクニックの類になってしまうのかもしれませんが、
以前仕事でちょっとでた話を紹介します。

このときに出た話は「動的URLだとSEO上好ましくはないので、動的URLを静的URLに書き変えたい」ということでした。

動的URL・・・たとえば動的変数を含めてリクエストを送信する場合、通常は”http://www.example.com/mypage.cgi?category=xxxx"というように"?変数="という形のURLになるのですが、このようなURLを動的URLといいます。

それに対して、このような?変数形式ではなく、

”http://www.example.com/mypage.cgi/category/xxxx”

という形式になるのが「静的URL」です。

どうも昔は、このような動的URL形式のものをgoogleなどのクローラーが取りこぼす可能性が高い、とされてきました。最近はgoogleは「静的か動的かによって特にSEO上差異はない」と明言しているようですが、やはり複雑なパラメータがついたものだと、取りこぼす可能性があるとも言われているようです。実際のところはわかりませんが、いずれにせよ以前のブログで書いたとおり、恒久的な対策にはならないでしょう。

私がうけた質問としては「（SEO対策のため）サーバ側でmod_writeというツールを使ってURLを動的なものから静的なものに書き換えているが、（うちが扱っている）ネットワーク機器で不都合はないか？」でした。特にHTTPのデータ部とかいじったりはしないから、基本的にはバグとか特殊な要件がない限り問題出るはずないけどなぁ…そのあたりを丁寧に回答しておきました。

ぢろーらも個人でよく目にする例としては、「動的URL」というと、変数部分はHTTPでクライアントとサーバのセッションを維持するための「セッションID」を思いつきます。

セッションID・・・ユーザを識別するためのランダムな文字列です。こんな文字列をもとにSEO対策して何になるのだろう？そのURLにアクセスするのは基本的には1人しかありえないのに…。

ただ、これは単なるぢろーらもの思い違いのようです。このときのお客さんは「就・転職サイトを運営するシステム屋さん」でした。で、使用方法を考えてみる…。

ああ、そっか、この手のサイトの場合、業種・職種ごとにカテゴリがわかれていてその部分が（本来のアプリケーションの作り上は）動的変数になってしまうから、SEO対策のために静的URLにしたいのか…。
（たとえばソフトウェアの業種であれば、http://www.example.com /mypage.cgi?category=sofware　など）
確かにこれであれば「業種などの条件でしぼりこんだページのみについても検索上位にしたい」というのも十分納得がいきます。

効果がどのくらいかは別として、意気込みは感じます。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---

おもちゃ箱ブログのアクセス解析 5月 ： IT編

さきほどの「おもちゃ箱ブログのアクセス解析　5月」続きでございます。こちらはIT編。これらに関しては、こういう情報を求めている人になんらかのヒントになればいいかな、と思って書いています。

「cn コモンネーム ワイルドカード文字 rfc」

　最終的に何を調べたかったのかはわかりませんが、お役に立てたでしょうか？確かにRFCの部分では「仮想サイトの場合には証明書を提供する段階ではどのサイトにアクセスされたのかわからないので、SSLパケット上にホスト名がわかるような情報を載せる」というところでRFCの話題をだしました。

「x-forwarded-for 多段プロキシ」

　おっと、これは以前の「多段プロキシ」の記述がちょっとに違ってましたね・・・。多段プロキシの場合、前段のプロキシがX-Forwwarded-Forをoffにしてしまうと、その先のプロキシではX-Forwarded-Forが読み取れず、もとのクライアントのIPがわからなくなります。もとのクライアントのIPを隠ぺいできる、というのはセキュリティ上のメリットにはなるのでしょうが、当時はそれが裏目にでてしまいました。

「マルチホーミング　dns　インバウンド　自宅」

　自宅で、ですか・・・・。ちょっとわたくしも調べてみましたが、http://princo.org/tips/iproute2.html　http://flatray.com/linux/multihome/　などに紹介されているように、Linuxにインストールできるパッケージのiproute2を駆使して、一応構成はできるみたいですね。アウトバウンドの通信についてラウンドロビン的な振り分けができたり、WAN側からはいってきたリクエストに対する応答を、もとの回線に戻すこともできるようです。DNSの部分は本当は回線に障害があった場合がその回線に紐づいたAレコードは返さないようにしたいところですが、Webとかの通信であれば名前解決の部分は単純なDNSラウンドロビンだけにしても、IEとかだと障害時もうまく処理してくれるようです。なので、アプリケーションによってはどうにかなるかもしれません。

　この構成の制限としては、http://flatray.com/linux/multihome/　でも触れられているように、回線の障害監視まではできないこと、あとはアウトバウンド通信時にクライアントIPアドレスに基づいた接続維持（同じクライアントからの通信は宛先にかかわらず一定時間は同じ回線を使い続ける）がないので、一部のサイトに関しては複数のセッションが別の回線から出てしまうことで弊害が起きることはあるようです。

　もちろんカスタマイズできるのであればそれでクリアできるのでしょうけど、簡単に行うとなるとやはり市販のマルチホーミング機器になるのかな、と思います。http://japan.zdnet.com/release/story/0,3800075480,10024926,00.htm　にもあるように、一番ローエンドなものでも３０万円近くはするので、一般家庭にいれるには高価なものですわね。

「Active-Active　ファイアウォール　構成例」

　こちらはどういうわけか、たまたま別の記事に書いていたそれぞれの語句でマッチングしてgoogleにひっかかりました。なので、おそらく検索された方の目的は達成されなかったことかと思います。

　たとえば、比較的一般的かな、と思うのは、VRRPグループを複数持てるようなファイアウォールを使って、半分のクライアントにはVRRP１側のデフォルトゲートウェイ、もう半分はVRRP2側のデフォルトゲートウェイを設定する、という方法です。発想としてはシンプルかと思いますが、クライアントに別の設定をするのは面倒かもしれませんね。たとえばこのサイト：http://www.furukawa.co.jp/fitelnet/product/f100/setting/detail/vrrp2.html　まあ、ルータではありますけど、考え方はいっしょです。

　あとは、ファイアウォールをロードバランサで負荷分散する、という手もあります。「ファイアウォール　負荷分散」で検索すると、Radware、Nortel（といっても、L4/L7部門はRadwareに買われてしまったので、結局は「Radware」ですが）、PIOLINKといったメーカーがマッチします。行きと帰りの通信を同じファイアウォールに戻すために、バランサはファイアウォールの上下でサンドウィッチにします。

　けっこうお金のかかりそうな構成なのですが、負荷が増えたら並列にファイアウォールを増やせばいいので、ファイアウォールのリプレイスをするよりも簡単でコストも少ない場合もあります。もちろん、バランサがボトルネックになっては本末転倒なのでバランサにもそれなりのスペックは必要です。ただ、ファイアウォールといっても純粋にファイアウォールの役割だけさせるのであればけっこうスループット高くても、IPSとかアンチウィルスみたいな高度な処理をさせるとなるとスループットはガクンと落ちるはずです。そういう場合には、ファイアウォールのスケールアップで対応しようとするとコストがかさんでしまうので、このソリューションも有効かもしれませんね。

　あとは、http://www.atmarkit.co.jp/fsecurity/special/12fire/fire01a.html　で「自律型」と称されているように、ファイアウォール自身で互いのセッション管理をしてうまく振り分ける、という方法を実現しているものもあります。まあ、このあたりはCheck PointのIPシリーズ（旧NOKIA製品)のIPクラスタリングなどのようにメーカー独自の方法なのかと思います（参考サイト：http://www.asgent.co.jp/Products/CP_IP/ip_point.html　など）。

　

　まあ、こんな感じで自分の勉強にもなりました。こういう作業を続けると、サイトの内容を工夫するヒントが得られそうです。もうちょっと頑張ってみます。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---