サーバにアンチウィルスソフトを入れない選択

サーバにアンチウィルスソフトを入れるのは常識と思われるかもしれません。しかし現実問題としてサーバにアンチウィルスソフトを入れてないサイトが非常に多いのです。そこで今回は何故サーバにアンチウィルスソフトを入れないサイトが多いのか述べてみます。

【理由1: サーバ用アンチウィルスソフトは高い】
PC用アンチウィルスソフトだと無料～数千円。それに対してサーバ用は数万円となります。サーバ台数が1台ならなんとか買えますが、サーバ台数が数百台とか数千台の規模になってくると全サーバにアンチウィルスソフトを入れることが財政上困難という場合があります。（無論それだけサーバを必要とするサイトであればそれなりに儲かっているだろうというツッコミはありそうですが）

【理由2: アンチウィルスソフトは重い】
パフォーマンスを追求しているWEBサイトにおいて、アンチウィルスソフトの動作はあまりにも重すぎます。アンチウィルスを入れたせいでフロントエンドWEBサーバの台数を5割増しにしなければならなくなったなどといった話しはよくある話しです。

【理由3: OSをカーネルレベルでいじっているため市販のアンチウィルスソフトが使えない】
ある程度の規模のサイトになると、何らかの形でOSをカーネルレベルでいじっている可能性が高いです。そうなってくると当然アンチウィルスソフトメーカーは動作を保証してくれません。メーカーが動作を保証してくれないアンチウィルスソフトなんて怖くて使えません。

【サーバにアンチウィルスソフトを入れなくて大丈夫なの？】
となると「サーバにアンチウィルスソフトを入れなくて大丈夫なの？」という疑問が当然出るかと思います。これは何とも答えにくい問いです。まず確実に言えるのは「アンチウィルスソフトが入っていれば100%安心ということは絶対ない」ということ。これを前提に、他の手段でセキュリティ対策を施すことになります。例えば、

・ファイアウォールレベルでサービスで使っていないTCP/UDPポートをふさいだり怪しいパケットを遮断する。
・WAF(WEBアプリケーションファイアウォール)などで怪しいリクエストを遮断する。
・重要なデータが入っているサーバ(DBなど)はネットワーク的に奥の奥のほうに置き、簡単にたどり着けないようにする。
・アプリケーション開発時にセキュリティホールがないよう最大限注意する。

などです。

httpd.confがどこにあるか簡単に見つけ出す方法

必要に迫られてhttpd.conf(apacheの設定ファイルですね)の所在地を簡単に見つけ出す方法を調べましたのでご紹介します。

【1. httpdのオプションを使う方法】
---------------------------------------------------
% httpd -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:80 is a NameVirtualHost
default server www.example.com (/usr/local/apache2/conf/httpd.conf:1053)
port 80 namevhost www.example.com (/usr/local/apache2/conf/httpd.conf:1053)
---------------------------------------------------
のように出てきます。

【2. locateコマンドを使う】
---------------------------------------------------
% locate httpd.conf
/usr/local/apache2/conf/httpd.conf
---------------------------------------------------
のように出てきます。ただしlocate用のデータベースがないと使えません。データベースはroot権限でupdatedbコマンドを実行して作成する必要があります。

メンテナンス画面を簡単に出してみる

ウノウラボの記事に対抗しているわけではありません。多分。（笑）

私が昔やっていた方法はメンテナンス画面表示専用ノートPCを用意する方法です。ノートPCにApacheを入れて超軽量メンテナンス画面データを置いておきます。メンテ時間になったらロードバランサーの向き先を切り替えるか、LANケーブルごとぷちっと差し替えることでメンテナンス画面に切り替えます。（ただし後者の場合はネットワーク機器にMACアドレスのキャッシュが残ることで通信できなくなる可能性があるのでその場合は適切に処理します）

さて、なぜこのような方法を取るようにしたか。

・まずメンテナンス画面専用機器を用意したのは、サーバのセキュリティパッチを適用したり再起動したりといったサーバ自体のメンテナンスが発生する場合単純に面倒くさいからです。

・ノートPCにしたのはバッテリーが付いているので一定期間バッテリーで動くからです。これなら電源まわりのメンテナンスも可能になります。

・専用ノートPCとは言ってもかなり低スペックのマシンでも十分だったので秋葉原で1万円で買ってきた超おんぼろPCでした。メンテナンスを行っていたのは深夜ばかりでしたし、メンテナンス画面が超軽量だったのでこの程度のマシンでも十分なんです。

メンテナンス画面と言えば、以下のようなことにも気をつけてました。

・メンテ終了予定時間近くになると急激にアクセスが増えてくるので、わざとメンテ終了時間を長めに書いておいた。

・メンテ時間を過ぎるとユーザの怒りが大きいので、そういう意味でもわざとメンテ終了時間を長めに書いておいた。

・メンテ終了予定時間を過ぎるとF5(or CTRL+F5)、俗称F5アタックを使ってリロードを試みる人が増えるのでますますサーバ負荷が上がってページが見えなくなる。これを防ぐためにいろいろなテクニックを使った（方法は内緒）。

・少しでもサーバ負荷を減らすために、HTTP Response headersを書き換えてWEBブラウザのキャッシュに残るようにした。ただしあまり長い時間キャッシュさせるとメンテが終わってもメンテ画面のままなのでほどほどにする。

WEBサイトの閉じ方について考える

WEBサイトの作り方について述べられた文献は多いですが、WEBサイトの閉じ方について述べられた文献は滅多に見ません。そこで今回は私が考えるWEBサイトの閉じ方について考えてみたいと思います。

【WEBサイト閉鎖までに行うこと】
流れとしてはこんな感じになるでしょう。

１．まず最初に「WEBサイトを○月○日に閉鎖します」というアナウンスを出す。
２．閉鎖日になったら「このサイトは○月○日に閉鎖しました」というアナウンスに切り替える。（WEBサーバごと切り替えるのが良し）
３．サービスに使っていたサーバを適切に処理する。
４．その後閉鎖告知ページを残すのであれば、そのページが残るように適切に処理する。

WEBサイト閉鎖はネガティブな作業であるためあまり気合が入らないかもしれませんが、最後まできちんと気を抜かずにがんばりましょう。

【閉鎖告知用サーバでよくあること】
・COPYRIGHT表記が古いまま
　　→「Copyright (C) 1998 ○○」という表記を残す必要があるならきちんと毎年更新しましょう。

・WEBサーバにセキュリティパッチが適用されていない。
　　→管理者不在になるためか、セキュリティパッチが適用されていない例が多いです。こういったサーバが踏み台にされやすいです。

・リンク切れ多発。
　　→リンク先が更新された場合、きちんとリンクを変えましょう。

などなど、お粗末なことが多いです。閉鎖告知用サーバを持つのであればサービス用サーバ同様きちんと管理しましょう。

【おすすめ】
・閉鎖告知用サーバにもきちんと管理者を置く。

・もしくは多少費用がかかっても閉鎖告知用サーバはホスティング業者に管理を委託するのもあり（かなりお勧め）。

・サービスを閉鎖した場合データやプログラムのバックアップをサーバや社内に残しているところも多いが、放置された情報が一番流出の危険性が高いので、それらをCDRなどに焼いて銀行の貸し金庫に保管すると安全。

・閉鎖告知をやめる際のドメイン名処理に注意。ドメイン名を持ち続けるかもしくは信頼できる他社に売るというのがお勧め。何もしないとドメイン名転売業者が手に入れる可能性大。

などがあります。

続：複数WEBサーバへの最新ソースコード配信方法

前回複数WEBサーバへの最新ソースコード配信方法という記事を書きました。前回はやり方だけを記しましたが、実際に試してみるといろいろ注意すべき点がみつかります。そこで今回は続編としてそれらの注意点を記します。

【配信に失敗する場合があるので気をつける】
rsyncやrobocopyが常にうまく動いてくれればいいですが、たまに配信に失敗することがあります。例えば100台に配信しようとして99台だけうまくいって1台だけコケた場合を考えて見ましょう。この場合何も対策を行わないと発見が難しいです。最悪なのはユーザからの指摘で気づくことでしょう。

この対策にはいろいろあります。

　・方法１：全サーバのコンテンツフォルダ配下のチェックサムを取って比較し同一なことをチェックする。（一番確実）

　・方法２：rsyncやrobocopyのログを自動もしくは手動でチェックする。（うまくやらないと漏れが生じる可能性がある）

　・方法３：version.htmlのようなファイルを作り配信日を入れてそれも配信する。配信後全サーバのversion.htmlの内容をチェックする。（実装は結構簡単）

　・方法４：rsyncやrobocopyを3～5回繰り返す。（確実ではないけど大抵の場合うまく配信される。が、本質的な解決にはならない）

【HDD空き容量に気をつける】
配信に失敗する原因で一番多いのはHDD空き容量不足です。特定サーバだけ何故か巨大なログファイルが残っていてHDD容量不足で配信に失敗することが意外とよくあります。サーバリソース監視システムが導入されているのであれば発見が容易ですが、そうでないのであれば注意する必要があります。

【それ以外】
それ以外だと「ネットワーク障害」と「認証失敗」がまれに起こります。ネットワーク障害は、例えばLANケーブルが抜けかかっていただとかL2スイッチの特定ポートだけが故障したなどがあります。認証失敗は、例えばサーバの全パスワードを変更したつもりが1台だけ漏れていたなどがあります。

単純な作業の中にもいろいろノウハウがあります。なかなか奥が深いですね。

複数WEBサーバへの最新ソースコード配信方法

WEBサーバを数台用意して負荷分散している会社が多いと思います。このような場合必ず悩むのが、どうやって複数WEBサーバへ最新ソースコードを配信するかだと思います。そこで今回はソースコードを複数サーバにコピーする方法について述べてみたいと思います。

【その前にネットワーク確認】
まずはネットワークを確認したいと思います。ほとんどの会社は図1のような感じだと思いますが、安全性を考えればできれば図2のレベルまで持って行きたいところです。

図1

図2

【ステージングサーバを用意しよう】
次に押さえたいのがステージングサーバです。小さな会社ではWEB1にまずは最新ソースを置いて、そこから他のサーバにコピーする方法を取っているかもしれません。しかしいろいろな意味で配信専用のステージングサーバを別途用意することをお勧めします。ステージングサーバを用意することのメリットは

　１．ステージングサーバもWEBサーバと同じ設定をしておけば上で配信前の最後の最後にテストができる。
　　　→PCのhostsファイルに、サービス用FQDNをステージングサーバのIPで書くなどの方法でテスト可能。

　２．本番サーバとステージング用サーバで別々の権限設定ができる。
　　　→本番サーバにはシステム管理者しかアクセスできないが、ステージングは開発責任者以上とか。

　３．その他企業秘密で書けないけどやってみないとわからないメリットたくさん。

※ただしあまりに便利なステージングサーバ。死亡すると結構業務に支障が出るのでハードウェアはいいもの使ったほうがよいと思います。

【ソースコードを配信するためのコマンド】
興味があっていろいろな人に聞いてみましたが、UNIX/Linux系だとrsync、Windows系だとrobocopy.exeがとてもよく使われるようです(私も基本的にはそうです)。

rsyncはSSHを使った配信もできる反面、暗号化しながら送るので配信にとても時間がかかるというデメリットもあります。rsyncを使ったサンプルは以下のような感じです。

---

rsync -aurz -e ssh /var/www 192.168.0.101:/var/www

---

robocopy.exeはWindows2000のリソースキットに付いています。Windows2003のリソースキットに付いているかは知りませんが、Windows2000のrobocopy.exeがWindows2003で動くことは確認しています。robocopy.exeを使ったサンプルは以下のような感じです。まあシンプルですよね。

---

@echo off
REM robocopy /E /XO G:\ F:\

SET SRC_PATH=D:\www\src

CD D:\www\src

ECHO WEB1
D:\bin\robocopy.exe /E /XO /W:3 %SRC_PATH% \\192.168.0.101\src >> d:\Logs\logfile_WEB1.txt

ECHO WEB2
D:\bin\robocopy.exe /E /XO /W:3 %SRC_PATH% \\192.168.0.102\src >> d:\Logs\logfile_WEB2.txt

ECHO WEB3
D:\bin\robocopy.exe /E /XO /W:3 %SRC_PATH% \\192.168.0.103\src >> d:\Logs\logfile_WEB3.txt

---

双方のコマンドを利用するときの注意としては、「送信元にはあって送信先にないファイルを全て削除する」というオプションを付けると、配信時にコマンド入力を間違えると送信先のファイルが全部消えてしまうことがあります。この事故はとてもよく起こるので注意しましょう。

Cookie情報をWEBブラウザーで表示する方法

現在参照しているページに書き込まれているCookie情報を見たいときってありますよね。
そんな場合はWEBブラウザーのURL欄に

javascript:document.cookie;

と書き込むと見ることができます。

開発しているときはもちろんのこと、Cookie情報を元にしてロードバランスしているロードバランサーの挙動を追うときなんかにも有効に使えます。お気に入りにいれておくといいんじゃないでしょうか。

P3P(プライバシーポリシー)の設定方法

P3P(プライバシーポリシー)の設定方法

2年前にもP3Pの記事を書いているんですが、久しぶりにまた書いてみます。というわけで今回はP3P(プライバシーポリシー)の設定方法のご紹介です。

■作業手順
１．各WEBサーバのルートに「w3c」フォルダを作成する。
２．その中に定義ファイルとして「P3P.xml」というファイルを置く。
　　（定義ファイル作成ツールがネット上にたくさんころがっているのでそれを利用す
　　るとよいでしょう）
３．P3Pコンパクト・ポリシーをHTTPヘッダとしてブラウザに返すように指定する。
　　（IISでは、サーバのプロパティ・ダイアログの［HTTPヘッダー］タブでブラウザに
　　返すHTTPヘッダを指定できる。）

[設定例]
カスタムヘッダー名：P3P
カスタムヘッダー値：CP="内緒 内緒 内緒 内緒 内緒 内緒 内緒 内緒 内緒"

■参考資料
・P3Pの詳細説明 http://www.w3.org/P3P/
・P3P化設定が有効であるかどうかのチェック http://www.w3.org/P3P/validator.html

アクセスログを解析するツール

Webサーバなどのアクセスログを解析するツールとして特に有名な４つをご紹介。

■Analog
http://www.analog.cx/http://www.analog.cx/

■AWStats
http://awstats.sourceforge.net/

■HitBox
http://www.hitbox.com/

■Webalizer
http://www.mrunix.net/webalizer/

無料でSSLサイト証明書を発行してもらう方法

フリーの認証機関CAcertというものを発見しました。

http://www.cacert.org/

が、弱点が２点あります。

１． IEなどのWEBブラウザーにデフォルトでCAcertのルート証明書が登録されていないので個別に登録する必要があります。
２．SSLサイト証明書は信頼できる認証機関が発行するということが大前提になりますが、この認証機関の信頼性はどうなんでしょうねぇ。

HTTP圧縮を実現するアプライアンスサーバ

サーバ設定変更でHTTP圧縮を実現するのは結構大変です。Apacheであればmod_gzipインストール、IISであればIISの圧縮機能設定やISAPI追加等の必要があります。これらの設定は概してとても面倒で、HTTP圧縮の威力はよくわかるものの、システム管理者としては極力楽にそれを実現したいと思うわけです。そこで今回はHTTP圧縮を実現するアプライアンスサーバをいくつかご紹介しましょう。

【HTTP圧縮アプライアンスサーバの仕組み】
通常のネットワーク構成ではロードバランサーの下にWEBサーバをぶら下げる構成を取ります。HTTP圧縮アプライアンスサーバを導入する場合は、WEBサーバからの戻りパケットがアプライアンスサーバを通るように構成します。すなわち戻りパケットをWEBサーバから受け取り、アプライアンスサーバがデータを圧縮してクライアントに返すわけです。とってもお手軽です。

【販売しているHTTP圧縮アプライアンスサーバ】
現在販売されているものを簡単に調べてみました。ハードウェアタイプのものとソフトウェアタイプのものがあります。

・http://www.macnica.net/redline/
・http://www.takachiho-kk.co.jp/products/networking/prod/netscaler/
・http://www.ashisuto.co.jp/prod/detail.php?A=83
・http://www.ashisuto.co.jp/prod/quix/web/gaiyo01.php
・http://www.zend.co.jp/products/zps/

■参考
http://nosa.cocolog-nifty.com/sanonosa/2004/09/http.html

HTTPヘッダー研究その４： IISのHTTPヘッダーを書き換えよう

IISのHTTPヘッダーを書き換える方法は、apacheのそれと比べて情報源がかなり限定されていて調べるのに大変苦労しました。それだけにここでその方法を書いてしまうのはちょっと惜しい気持ちもあるのですが、まあ隠しても仕方ないので書いてしまいます。（この書き込みが役に立たれたら是非コメント欄に書き込んでください・・・）

基本的にIISでHTTPレスポンスヘッダーを書き換えるためにはISAPIフィルタリングアプリケーションをIISに登録する必要があります。

【HTTPヘッダーを自由自在に書き換える方法】
HTTPヘッダーを自由自在に書き換えられる無料のISAPIアプリは残念ながらみつかりませんでした。しかし有料ではservermaskという強力なものがあります。

servermaskは不要なHTTPヘッダーを消したり書き換えたりする機能の他に、HTTPヘッダー的に他のWEBサーバに化けるという機能もあります。HTTPヘッダーいじりが本当に自由自在にできるので便利です。価格は１サーバライセンス99.95ドル。サーバ台数が少ないサイトでは有効ではないでしょうか。（うちはサーバ台数が多すぎて無理です・・・）

【HTTPヘッダーの製品情報を隠蔽する】
製品情報の隠蔽、すなわちServerName部分だけ隠蔽するだけだったら無料のISAPIが２つ存在します。

１つめはマイクロソフト社が提供するURLSCANツールを入れる方法です。

まずはインストールしましょう。次に設定ファイルを変更します。設定ファイル

c:\WINNT\system32\inetsrv\urlscan\urlscan.ini

の中で「RemoveServerHeader=1」として、urlscan.exeを実行し、IISを再起動することで適用されます。ただしURLSCANツールはHTTPヘッダーの書き換えのためにあるというよりは不正アクセスの防御のために作られたツールです。適用の前にはURLSCANの仕組みをよく理解しておくことが必要です。特に[AllowExtensions]に.aspを追加し、[DenyExtensions]で.aspを削除しておかないとASP言語の実行がされなくなります。使い方を間違えるととても危険なツールです。

もう１つはMoIISProtectをISAPIに追加する方法です。

MOIISProtectをISAPIフィルタに登録するだけでIIS製品情報が非表示になります。これは簡単で便利です。

【HTTPヘッダーのETag情報を隠蔽する】
最後にETag情報だけを隠蔽するためのETagFixというISAPIアプリを紹介します。これは試してないですが、多分予想通りの働きをしてくれるものと思われます。無料だそうです。

HTTPヘッダー研究その３： キャッシュコントロール

ロゴや.cssのように滅多に更新されないデータがあったとします。サイトにアクセスする度にWEBブラウザーがこういったデータを毎回読み込むようになっているとネットワーク帯域の無駄遣いですし、レスポンスも遅くなります。そこで今回はHTTPレスポンスヘッダーを書き換えてそれらのデータをWEBブラウザーのキャッシュに残るようにする方法を記してみたいと思います。

【基礎知識編】
キャッシュコントロールを考える際、知っておくべきHTTPレスポンスヘッダーは４つ。Cache-Control、Pragma、Expires、及びETagである。細かい話しは省略するので次のサイトを見ておいてください。（ずるい？）

事例に学ぶWebシステム開発のワンポイント（12）

今回はETagは無条件削除、Cache-ControlだけコントロールするとしてPragmaとExpiresは対象外とします。

【Apacheでの設定編】
apacheの場合いろいろなやり方があるようですが、ここではmod_expiresを追加する方法をご紹介します。

まずmod_expiresを追加してコンパイルします。
./configure --enable-module=expires
make; make install

そして以下のような要領でhttpd.confを書き換えます。

---

＜Directory /＞
Options None
AllowOverride None
ExpiresActive On
ExpiresByType text/html "access plus 1 hours"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType text/css "access plus 1 days"
ExpiresByType application/x-javascript "access plus 1 days"
＜/Directory＞

---

【Tux Web Serverでの設定編】
①/proc/sys/net/Tux Web Server/generate_cache_controlが"1"になっていなければ"1"にします。ただしデフォルトが"1"なので特に書き換える必要はないかも。
②/etc/Tux Web Server.mime.typesを次の要領で書き換えます。

---

text/html html|3600 htm|3600
image/gif gif|86400
image/jpeg jpeg jpg|86400 jpe

---

③/etc/init.d/Tux Web Server restart

【IISでの設定編】
IISの場合は拡張子別でのHTTPヘッダーコントロールができず、フォルダ単位になります。IISの場合はGUIベースなので簡単です。

【やってみた結果】
HTTPレスポンスヘッダーを見て次のようになっていたら成功です。
Date: Thu, 28 Oct 2004 09:31:06 GMT
Content-Type: text/html
Cache-Control: max-age=3600

さて効果はどうか。実際のデータを多少改変したのが以下の図です。日曜日と月曜日の間に設定変更をしましたが、リクエスト、レスポンス共激減したようですね。

徹底的にリンク切れを取り除こう

HTMLファイルを注意深くのぞいてみると、リンク切れしている部分が意外と多く発見できるものです。特にデザイン変更を繰り返しているページはそれが顕著に見られます。これをWEBデザイナーに指摘すると「開発効率を上げるためにはそんな些細な部分まで追求できないよ」という答えが返ってきそうです。しかしシステム管理者の立場から見るとリンク切れは徹底的に取り除くべきだといえそうです。

【リンク切れが引き起こす影響】
度々参照されるファイル、例えばロゴや.cssファイルは通常HTTPレスポンスヘッダーを操作してWEBブラウザーのキャッシュに残してもらうような記述をします。このファイルがうまく読み込まれれば以後はそのファイルに対してほとんどアクセスがなくなるのですが、もしこれがリンク切れだとすると、該当ページへのアクセスの度にそのファイルを読み込みにいきます。これはレスポンスの低下とネットワーク帯域の無駄遣いにつながります。

【404エラーページは極力簡略化すべき】
とはいいつつもWEBデザイナーや開発者が常にリンク切れに気を配ってくれることを期待すべきではないし、システム管理者が常にリンク切れをチェックすることも現実的ではないです。そう考えるとリンク切れ、すなわちFile Not Foundが発生したときに読み込まれる404エラーページは極力簡略化しておいたほうがよいといえます。もし404エラーページが凝っていると、リンク切れがあるページにアクセスがあるたびに凝った404エラーページも読み込まれることになります。

【リンク切れをどのように探す？】
apacheのログをひたすらチェックするという方法もありですが、私は秀まるおさんが作られた横取り丸というソフトを使っています。これはIEのプロクシーサーバとして機能して、アクセスのあったURLをその名の通り横取りして、HTTPリクエストとHTTPレスポンスをリアルタイムに表示してくれます。このソフトを動かしながらサイトにアクセスすると、慣れればすぐにリンク切れ発生個所がわかるようになります。

HTTPヘッダー研究その２： 不要なHTTPレスポンスヘッダーは消しましょう

HTTPレスポンスヘッダーって無駄が多いですよね。何を持って無駄かというのも議論が分かれるところですが、大規模サイトになると１行の無駄でも数万～数百万アクセスという量になってかなり大きな無駄が発生してしまいます。これは当然ネットワーク費用にも跳ね返ってくるのでもったいない話しです。そこで今日はapacheのHTTPレスポンスヘッダーの削除方法を記して見ます。

【設定方法】
apacheの場合、いくつかのHTTPレスポンスヘッダーはhttpd.confの編集で操作できますが(例： ETagの場合は「FileETag none」とか)、それ以外のものになると基本的にはC言語で書かれているソースの該当個所を削除することになります。え、危険ではないかって？それがオープンソース(すなわち自己責任)というものなのでリスクは積極的に受け入れましょう。

ではまずは何を消すかを考えてみましょう。
---------------------------------------------------
% telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK

Date: Mon, 18 Oct 2004 11:23:39 GMT
Server: Apache/1.3.31 (Unix)
Last-Modified: Fri, 10 Oct 2003 11:39:51 GMT
ETag: "b7d74-64-3f869a87"
Accept-Ranges: bytes
Content-Length: 100
Connection: close
Content-Type: text/html
---------------------------------------------------
賛否両論あるかと思いますが、一旦上記赤字の部分としてみたいと思います。ということで以下の要領で該当部分をコメントアウトしてコンパイルしてみましょう。

src/main/http_core.c

/*
ap_set_last_modified(r);
ap_set_etag(r);
ap_table_setn(r->headers_out, "Accept-Ranges", "bytes");
*/

そしてapacheを再度起動してHTTPレスポンスヘッダーを出して見ると・・・
---------------------------------------------------
HTTP/1.1 200 OK
Date: Mon, 18 Oct 2004 11:23:39 GMT
Server: Apache/1.3.31 (Unix)
Content-Length: 100
Connection: close
Content-Type: text/html
---------------------------------------------------

大成功です。

404エラー用ページを用意しよう(apache編)

apacheをなにも考えずにインストールすると、404エラーがこんな感じになります。

Not Found

The requested URL /a was not found on this server.

---

Apache/1.3.31 Server at hogehoge.nifty.com Port 80

これはむちゃくちゃかっこ悪いですしapacheのバージョンもバレバレなので、多少でも加工してみることにしましょう。

【設定方法】
httpd.confファイルに下記の行を追加するだけです。①だとメッセージがそのまま送信されます。②だと指定のURLにリダイレクトします。

①ErrorDocument 404 "＜h1＞404 error. File Not Found＜/h1＞"
②ErrorDocument 404 http://www.hogehoge.com/404error.html

今回をきっかけに、他社サイトを参考にしながら是非かっこいい404エラーページ(?!)を作ってみてください。

【他社の例】
Yahoo!
楽天
ビッダーズ
朝日新聞
@NIFTY
biglobe
ラクーン
NAVER
ハンゲーム

WEBサイトランキングを調べる方法

あなたのサイトは世界や日本で何番目に多く利用されているか知りたいことってないですか？インターネット視聴率を調査しているNetRatings等を使うと有料だから嫌だなあと普通思うわけです。そんなあなたのためにWEBサイトランキングを無料で調べるサイトをご紹介します。

【ALEXA.COM】

www.alexa.comというamazon.comの子会社があります。ここではいろいろなことが調べられます。

■日本国内ランキング

http://www.alexa.com/site/ds/top_sites?ts_mode=lang&lang=ja

■サイト別詳細ランキング(今話題のライブドアの例)
http://www.alexa.com/data/details/traffic_details?q=&p=Det_W_t_40_L1&url=livedoor.com

※余談：日本国内ランキングを見ると、上位はポータルサイト、ISP、無料ホームページ会社、アダルトばっかりですね。それ以外の会社にもがんばってもらいたいものです。

HTTPヘッダー研究その１： apache製品情報隠蔽しよう

HTTPヘッダーって見たことありますか？ 見てみると製品情報がバレバレです。

---------------------------------------------------
% telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 18 Oct 2004 11:23:39 GMT
Server: Apache/1.3.31 (Unix)
Last-Modified: Fri, 10 Oct 2003 11:39:51 GMT
ETag: "b7d74-64-3f869a87"
Accept-Ranges: bytes
Content-Length: 100
Connection: close
Content-Type: text/html
---------------------------------------------------

こんな製品情報を出しておく合理的な理由は特にないです。悪意を持ったユーザが
こんな情報をこんな簡単な方法で入手できるのも問題です。そこで今回は
apacheでの製品情報隠蔽方法をお教えしましょう。

【apacheでの製品情報隠蔽方法】

以下の要領でファイルを書き換え、通常の方法でコンパイルすればＯＫです。
既にインストールされているapacheの場合でも再コンパイルが必要となります。

※apache1.3系の場合
include/httpd.h
　#define SERVER_BASEPRODUCT "Apache"
　#define SERVER_BASEREVISION "1.3.31"
↓
　#define SERVER_BASEPRODUCT "HogeHoge"
　#define SERVER_BASEREVISION ""

※apache2.0系 の場合
include/ap_release.h
#define AP_SERVER_BASEPRODUCT "Apache"
#define AP_SERVER_BASEREVISION AP_SERVER_MINORREVISION "." AP_SERVER_PATCHLEVEL
　↓
#define AP_SERVER_BASEPRODUCT "HogeHoge"
#define AP_SERVER_BASEREVISION ""

すると以下のようになります。

---------------------------------------------------
HTTP/1.1 200 OK
Date: Mon, 18 Oct 2004 11:23:39 GMT
Server: HogeHoge/ (Unix)
Last-Modified: Fri, 10 Oct 2003 11:39:51 GMT
ETag: "b7d74-64-3f869a87"
Accept-Ranges: bytes
Content-Length: 100
Connection: close
Content-Type: text/html
---------------------------------------------------

※ただしapacheの世界シェアは7割以上ということもあり、こんな隠蔽をしてもapacheであることはバレバレだと思ったほうがよいです。今回の対応は、まあやらないよりはやっておいたほうがよいくらいに思ったほうがよいでしょう。

HTTP圧縮はネットワーク帯域削減に効果的

規模が大きくなるにつれて当たり前なことですがネットワークトラフィック使用量がどんどん増えます。ネットワーク部分の費用って結構高いのでこのコストを減らすことはビジネスの上でとても大切です。

そこで最近果たして我々はネットワーク帯域を効率的に使っているのかという観点で考えました。そしてあることに気づきました。それはHTMLファイルのようなテキストファイルは無駄にスペースやタブがたくさん含まれていたりするので圧縮すればその分ネットワーク帯域を節約できるはずだ、ということです。この件についてちょっと調べて見ると、なんとWEBサーバ自体にHTTP圧縮という機能がついているではありませんか。

ということで早速試してみたのが以下の内容です。ものすごい効果です。

ちょっとした設定変更でネットワーク費用が削減できるなんてすばらしいですよね。是非お試しください。

■参考
・HTTP圧縮を使用するだけで帯域幅もコストも削減できる～米調査結果(2003/7 InternetWatch)
・IIS 5.0 Web サイトで HTTP 圧縮を使用する
・Apacheにmod_gzipを組み込んで帯域を節約したい

画像データ配信にCDNサービスやキャッシュサーバを使おう

一昨日の投稿では画像データ配信に超高速WEBサーバTux Web Serverを使うことを提案し、昨日の投稿では画像データだけ分離して別サーバに置くことを提案しました。今日はそれと併せて画像データ配信にキャッシュサーバやCDNサービスを使うことを提案したいと思います。

【キャッシュサーバ】

イメージサーバを複数台並べて運用する方式の問題点は、デザイナーが画像を生成する度にデータをサーバ毎にコピーしなければならないということです。この問題が深刻だと考えるならば、キャッシュサーバの導入はきっとすばらしいソリューションとなることでしょう。キャッシュサーバの役割はHTTPリクエストを受けて、キャッシュサーバ上にデータが残っていればそれをそのまま返し、残っていなければマスターイメージサーバからデータを取得してそれをキャッシュに蓄え、レスポンスを返すというシンプルなソリューションを提供します。

しかし私の経験ではキャッシュサーバにもいくつか問題があります。

　①間違えたデータがアップしたことに気づき再アップロードしても、キャッシュサーバのキャッシュがすぐには更新されないことがある
　②キャッシュサーバは価格が高い。キャッシュサーバに置き換えることでサーバ台数節約になり費用軽減になるとメーカーは言ってますが、個人的にはTux Web Server WEBサーバの入った安いIAサーバを並べたほうがよっぽど安価だと思っています。無料のキャッシュサーバsquid(本当はproxyサーバですが、キャッシュサーバとしても使えます)はパフォーマンスが出ないのでやめておいたほうがよいです。

特に①の不具合はECサイトでは致命的かもしれません。

【CDNサービス】

キャッシュサーバよりも強力なのはCDNサービスを使うことです。CDNサービスというのは、（概念的な説明で実際はちょっと違いますが）CDN業者が全国にばらまいたキャッシュサーバを借り受けるサービスです。このサービスを利用するとユーザはネットワーク的に一番近くにあるキャッシュサーバを検出してそこからデータを取ってくるようになります。CDNサービスを利用するメリットとしては、①ユーザから見てレスポンスが上がる、②サーバ増強不要、③ネットワーク費用節約、というものです。

ただしCDNサービスもキャッシュサーバの①の問題が出ます。

ちなみにCDNサービスの課金体系は、業者によっても違うのかもしれませんが、主にネットワークトラフィック量とコネクション数によるようです。ですから非常に小さい画像データをたくさん配信するとネットワークトラフィック数が少ないのにコネクション数が増えるので料金が上がったりすることもあるようなので一応要注意です。

■CDN提供業者の例
アカマイ
CDNソリューションズ
アクセリア

画像データだけ分離して別サーバに置くべし

WEBサイトを開設した時には1台のWEBサーバですべてのアクセスを処理できていたとして、アクセスが増えてくるとWEBサーバを複数台用意して負荷分散を行わなければならなくなります。その時一番シンプルな方法、すなわち全てのデータを複数台のWEBサーバにコピーして負荷分散をするというやり方を行うことも決して悪くはないのですが、もっと良い方法がありますのでご紹介します。

WEBサイトのデータには、かなり大雑把に分類してHTMLファイル、画像ファイル、CGI等によって動的に生成されたファイルの3種類があります。今回私が推奨するのはこの中の「画像ファイル」だけ切り離して別サーバ、ここではイメージサーバと呼びます、に置くことです。

このメリットは

1. 画像ファイルは単なる静的なデータなので、高機能で重くてApacheの変わりに低機能だけど軽いWEBサーバを使える。
2. (今後執筆しますが)将来イメージサーバと相性の良いキャッシュサーバもしくはCDNサービスが利用できる。
3. プログラマーが関わるWEBサーバと、デザイナーが関わるイメージサーバというように明確に分離できる。

というところになります。

またサーバのボトルネックについても考えやすくなります。通常のWEBサーバはCPU,メモリ使用量,TCPコネクション数の3つのボトルネックについて気にする必要があります。しかしイメージサーバではCPU処理がほとんどないため、通常TCPコネクション数についてだけ気にしていればよいことになります。つまり安価なサーバにRedHat Linux+Tux Web Serverという構成であっても驚くべきパフォーマンスを得られることになり、大幅なコストダウンにつながります。

Apacheの代わりに高速WEBサーバTux Web Serverを使おう

「無料で使える世界最高速WEBサーバ、Tux Web Server」をご存知ですか。下記の特徴を読めば、きっとTux Web Serverを使いたくなるはずです。

■Tux Web Serverの特徴
・世界最高速WEBサーバである。
・無料で使える。
・設定がシンプルで扱いやすい。
・有名でないのでクラッキングされにくい。
・クラッキングされにくいので、セキュリティパッチがほとんど出ない。
・ただしCGI等、動的なコンテンツは扱えない。(その場合はapacheとの連携が必要になる)
・RedHatが開発したのでRedHat Linuxでしか動かない。

■Tux Web Serverを使うのに向いている用途
・静的なコンテンツ配信。(画像、htmlファイル等)

■参考文献
http://linux.ascii24.com/linux/news/today/2000/09/04/535520-000.html

http://nosa.cocolog-nifty.com/sanonosa/2004/06/windows_vs_unix.html

【P3Pのお話し】「IE6にバージョンアップした途端、急にサイトが利用できなくなった」というクレームを受けた場合

ユーザから「IE6にバージョンアップした途端、今まで利用できていたサイトが急に利用できなくなった」というクレームを受けたことのあるWEBサイト管理者の方はいらっしゃいますか。この症状は、WEBサイトにプライバシーポリシーが導入されていないことが原因でIE6によってクッキー（Cookie）の受け渡しがブロックされてしまうことによって発生します。

このことを知らない多くのサイトでは、ユーザに「ブラウザの設定で Cookie の受け渡しを有効にする(自動Cookie処理を上書きする)設定」、すなわち無条件にCookieを受け入れる設定をさせるという苦肉の策でこの問題を乗り切ろうとしています。しかしどう見てもそれはスマートな解決方法ではないので、この機会に是非P3P(Platform for Privacy Preferences)をサイトに導入しましょう。

【導入は簡単ですか？】
設定内容はごくわずかなのですが、プライバシーポリシーの作成とその適用がとてもわかりづらいので、導入は難しいと言いきってみたいと思います。

【プライバシーポリシーの導入方法は？】
WEB上に文献がたくさん出回っているのでリンクだけ張っておきます。

http://www.nmda.or.jp/enc/privacy/
http://www.microsoft.com/japan/msdn/workshop/security/privacy/overview/createprivacypolicy.asp

【プライバシーポリシーの確認方法は？】
適用されたプライバシーポリシーの確認方法をご紹介します。

「表示」→「プライバシーレポート」→(適当なサイトをクリック)→「概要」です。

例として下記にYahooのプライバシーポリシーを載せてみます。

KeepAliveについて考える

「KeepAlive設定のon/offの違いだけでサーバのキャパシティが数倍違ってくる」。大規模サイトならではの経験則です。ApacheやIIS等、一般的なWEBサーバでは通常KeepAliveの設定ができます。この設定はアクセスが少ないWEBサーバの場合にはonでもoffにしても大差がないため、小規模サイト運営の経験しかない管理者はこの設定についてあまり深く考えない場合が多いと思います。しかし大規模サイトではこの設定を誤るとサーバのキャパシティをすぐに超えてしまうので要注意です。

【一般的にonとoffのどっちがよいの？】

あくまでも私の大規模サイト運用上での経験則ですが、offにしておいたほうが安全であると感じています。例をお見せしましょう。これは非常にアクセス数の多いWEBサーバの例です。

KeepAliveがoffの時にはTCPコネクション数が少なく押さえられていますが、onにした途端TCPコネクション数がうなぎ昇りとなっています。これはTCPコネクションがボトルネックとなりサーバのキャパシティを超えてしまう可能性があることを示しています。

【KeepAliveをonにするのがよい場面はないの？】

もちろんあります。TCPコネクション数の見込みが少ない場合、すなわちアクセス数が少ないかもしくはサーバ台数がたくさんあって1台毎のコネクション数が少ない場合はKeepAliveをonにしたほうがよいです。通常KeepAliveをonにするとTCPコネクションを張りなおすコストが減ることでレスポンスが良くなることが期待されます。