チェックするときは、可能な限り動的生成ではないページをチェックしましょう。
動的生成のページとは、CGIの出力するページや、SSIによって加工されているページです。これらは、更新日時が読み取れないため、前回読んだときとサイズなどが違っているかどうか、全部読むことで更新の有無を判断するしかありません。
動的生成でなければ、ファイルの更新時刻やサイズなどの情報を、そのファイルの内容を見るまでもなく即座に知ることができます。
掲示板などをチェックするなら、掲示板のデータファイルのURLをそのページの持ち主に教えてもらってチェックするといいでしょう。非常に短時間に確実な更新チェックをすることができるようになります。
そのページが動的生成かどうかは、チェックしたときにLastModified欄に日付があるかどうかで判断できます。 日付があるのならOK。無い場合は、いちいち全部ダウンロードしてチェックしている「悪い状態」です。
ページを作成し、公開する場合も SSIは可能な限り避けたほうがWWWD(と、ブラウザやプロクシのキャッシュ)に優しいということになります(笑)。
たまに見かけるページに、拡張子.htmlにSSI属性を設定してしまって、SSIの必要も無いすべてのページが動的生成にされてしまっているものがありますが、これは非合理的です。SSIに使う拡張子は.shtmlを使うのが慣例なので、それに従いましょう。
これに関連した話ですが、BBSを設置する場合に、データファイルの拡張子として .cgi を推奨しているものがいくつかあります。実際にはcgiではないものをcgiとして設置するため、それを直接読もうとするとWWWサーバがサーバーエラーを返してしまいます。もし設置するんでしたら、データの拡張子は他の無難なもの( .datや .logなど)に書き換えたほうが良いんじゃないでしょうか[Web裏技の説明によるとセキュリティ上の理由で.cgiにさせているとのことですが、読もうとしたらInternal Server Errorを出させるやり方を推奨するのは感心しません。]
それでもどうしても動的生成のページをチェックしなければならない場合は、選べるのであればサイズの少ないページを選んでチェックしましょう(^^;
WWWDは、HTTP/1.1の手順を実装しています。この手順はHTTP/1.0から色々な点で改良されているのですが、チェック速度の観点で重要なのが、「パイプライン」です。
HTTP/1.0は、一部の独自拡張(Keep-Alive)を除いて一個のリソース(ページなど)を読み取るごとに通信を一回切る必要があり、同一サーバに連続してアクセスする場合は切ってまた接続するために通信の量と時間が余分にかかってしまいます。
HTTP/1.1ではこれを劇的に改善する手順として、一回の接続時に、相手の応答を待たずに一気に連続してリクエストを出せるようにされました。応答も繋がったまま連続して届きます。
この方式によって、相手の応答を待ってから次のリクエスト、という「往復待ち時間」が1回に削減され、多数のリソースをリクエストするときの通信量、時間が大きく削減されます。
WWWDではこれを有効活用するため、チェック予定に入ったすべての項目をサーバごとにまとめ、(グループの違いも関係なく)同じサーバごとにすべて1回のパイプラインリクエストでチェックするようにして、最短時間で大量のチェックが行えるようにしています。
なお、巷のWWWサーバは、すでにほとんどすべてがHTTP/1.1対応サーバになっています。
WWWDの全体設定のタイムアウト欄にある「パイプライン」は、パイプラインでリクエストしたのに1個目の応答のあとに指定秒経過しても2個目の応答が来ないときには、サーバがパイプラインを認識していないとして2個目以降をバラでリクエストしなおすための判断時間です。
htmlのMETA http-equivタグですが、これはHTTPプロトコル自体には影響を与えません。サーバはこれを認識せず、したがってHTTPプロトコルヘッダがこれに影響されることもありません。[2000/2/2注記:
Apacheの場合、"HTML::Embperl"等を使えばHTTPヘッダに出力できるようです。そのため、サーバ管理者がこれを有効にしていればMETAタグも有効に使える場合があります]
WWWDはこのHTTPプロトコルヘッダを見て動作を決定します。html本文のタグは解析していません。
動的生成ページの更新時刻を表したいためにこのタグで Last-modifiedフィールドをいじろうとしても、WWWDは認識しないので注意してください。
これをやるよりは、上記のように、SSIをやめて静的ページとしてサーバから取得できるようにする、あるいはできるファイルを用意してください。SSIは常にサーバに負荷をかけ、全文転送が入るので(チェックをする目的では)通信量の無駄です。
WWWDについて通信量にこだわる理由ですが、こんな理由があります:
上記はまああくまでも一般的な話です。たとえば社内LANの掲示板など、サーバもクライアントも帯域に余裕があるような場合では動的生成ページをチェックしたってぜんぜん気にならないでしょう。
日記などのように、どんどん増えるファイルの最新のものだけを固定アドレスで効率的にチェックできるようにする工夫を考えてみました。(これはチェックする側ではなく、公開する側の話です(^^; )
サーバ上で.htaccessファイルを置くことが許されている場合は、1番が簡単です。これならサーバに負荷はかからないし、最新の本体ファイル名が変わったときは固定アドレスからのリダイレクト先情報を変更するだけで済みます。チェック時の通信量としてはリダイレクトヘッダ、本文ヘッダ、と2段構えになりますが、キャッシュが効きます。
サーバ負荷は気にせず、またcgiのようなサーバ側処理を用意することが可能なら、2番目の方式のほうがさらに効果的です。これならチェックはHEADリクエスト一回で完了しますし、同じページをブラウザで開こうとすると本文ファイルが開くわけです。
上記はもちろん最新ファイルとして飛ばされた先のファイルは動的生成ではなく静的ページであることが前提です。
Inernet Link Agentというソフトのページの中 ( http://www.osk.3web.ne.jp/%7Egoronyan/winprg/ilaop/op.htm )に、
最近では、多くのいわゆる更新チェッカがありますが
売り文句として「他のソフトより高速」等と他をないがしろにしているとも取れるような事も書かれているものもありますが、本当にそんなに速いのでしょうか？？ うそだとは言いませんが、一応 「公開時点では・・わずかながら・・」 と解釈した方がいいですね。
と書かれていますが、これはきっとWWWDのことでしょうね(笑)ということでちょっと書いてみます。
WWWDの更新チェックの何が速いのか。同じサーバに対するリクエストをすべてまとめて一度に送り、すべての応答を一度に貰うHTTP/1.1の仕組み(パイプラインリクエスト)を積極活用しているから「速い」のです。
これにより、ソケットの接続および切断のシーケンスに必要な通信量と、その往復待ちにかかる時間を削減します。従って遅延の大きいサイトのチェック時に特に劇的な時間短縮になります。逆にいえば、同じサーバ上の複数のページチェックをしない場合は速くなりません。(遅くもなりませんが)
しかし実際にはチェック対象を増やしていくと、特に個人ユーザーのページをいくつもチェックする場合、多かれ少なかれ同じサーバ内の複数のコンテンツをチェックするようになるでしょう。それらのサイトはかなりの数が共有されたサーバ領域の一部を貸し出す形式だからです。
巡回にかかる時間は、実際のチェック処理にかかる時間と、その結果更新と判断されたサイトを人間が見て回る時間の合計であると考えることが出来ます。ユーザーの主観的には、後者こそが巡回時間ですね。
WWWDでは、後者の要素も「高速化」しています。それがタスクトレイアイコンをクリックすることで未読ページを開く機能です。
昔からパソコン通信の巡回ソフトやメールソフトなどでは未読をスペースキーなどの同じ操作で短時間にどんどん読み進めることができていたのに、Webの時代になり、また手動でいちいち開いて回る世界に逆戻りしたのが不満でした。読むのに時間がかかってしょうがない。巡回に必要な「実際に読む」以外の操作の時間を削減できれば、浮いた時間を他のことに有意義に使うことができますね(笑)。
とにかくトータルの時間を減らすことを主眼としたため、「どうせ全部読む気なら順番なんてどうでもいいだろう。いちいち毎回更新された中から人間に選ばせる時間こそが無駄だ」と割り切って、たとえるならクレー射撃のように、ユーザーはただ構え、合図をするごとに次々とページが出てくるのを撃つ(=読む)スタイルにしたのです。
上記の目的が現在の主眼であるため、WWWDのことは「更新チェックソフト」というよりは「巡回支援ソフト」と呼んでください。
(ちなみにこの機能の実装自体は馬鹿馬鹿しいほど簡単です(笑))
さてついでに、上記サイトを読んだ方がWWWDではどうなのか気になりそうな部分をフォローしておきます。
WWWDの場合は、1度目のチェック時に得た各サーバのIPアドレスはキャッシュし、2度目以後はIPアドレスが同じならば、つまりサーバマシンが同じならば、違うサーバ名(仮想ホスト)であっても複数のリクエストをまとめてさらに通信量と時間を節約するようになっています。
WWWDの場合は起動後1回目は(指定がなければ)HEADを出しますが、そこで失敗してGETが必要と判断された場合は以後最初からGETを出しています。従って起動後1回だけチェックして終了するような使い方をするのであれば確かに無駄が大きいですね。
(一応フォロー。WWWDは巡回にかかる総時間の短縮に主眼を置き、それ以外の部分はバッサリ切ったソフトです。従って他のソフトのほうが利便性が高いと感じる方も多いはずです。そのあたりはご自分で実際に使って比較してください。)
そういう点ではWWWDの売り文句として「同種のソフトより速い」と、あたかもどんな場合でも速いのかと思わせるような書き方がされているのはまずいとは思います(笑) > yosi
WWWCを使っていた → HTTP/1.1を知った → 同一サーバ内のチェック項目が多かったので、これは使えると思った（笑） → WWWCにHTTP/1.1対応をリクエストしたが受け付けてもらえなかった → 自分でHTTP/1.1が実装してみたくなった → ライブラリを書き、動作テストプログラムを書いた → それがいつのまにか自分専用更新チェックプログラムになった → 知人にも配った → とくに広めるつもりがなかったのになんだか広まっている?
というのが経緯になります。
HTTP/1.1対応以外の点ではWWWCは気に入っていましたし、良い部分は特に無理して変えることもないと思ったので、似たソフトになっています。開発言語は違いますし、WWWCのソースも見ないで作ったので中身はオリジナルですが。(作った後、WWWCからのデータインポート要望に応えるためにファイル書式調査としてソースを1回だけ見ましたが)
新作として公開するつもりで作っていたわけではありませんが(^^; いくらか知られてきてしまったので、何か違いを付けたほうがいいかなあとは思い始めているところです。