2015/04/03(金)モンスターデータベース画像対応、他

モンスターデータベース画像対応

モンスターデータベースを、モンスターの画像を表示できるように改良しました。左メニューの設定で「画像表示」にチェックを入れると表示できます。アクセス数が増えすぎないように、初期状態では非表示です。

画像表示対応は、当初は以下のような方針にするつもりでした。

  • 画像ファイル名はデータベース上のシリアル番号に合わせて"123.jpg"のようにする
  • データベースとしては、画像が存在するかどうかのフラグだけを持つ
  • 画像ファイルの大きさは100×100固定
  • 利点
    • モンスターデータベースのシステムで画像の取り扱いが完結する
    • フラグを持つだけなので、追加の情報量が少ない
  • 欠点
    • モンスターデータベースに画像アップローダーを組み込む必要あり
    • 画像の種類がjpg固定
    • 画像を違うモンスター間やECO-Wikiと共有できない(ブラウザキャッシュが活用できない、画像を多重管理することになる)

しかし、既にECO-Wikiの方に画像があることと、ブラウザキャッシュ活用の重要性を考えて、以下のように方針変更しました。

  • 画像ファイル名(パス)をデータベースの一項目として登録
    • 画像ファイルの大きさもここに含める
  • 画像ファイル自体はECO-Wiki用画像アップローダーで取り扱う
  • 利点
    • 画像アップローダーの組み込み不要
    • 画像の共有・使い回しが可能
  • 欠点(今回はどちらもそれほど問題にならないと判断)
    • 別途画像アップローダーが必要
    • 画像パス・大きさ情報の分、データベース容量が増える

データベース容量については、gzip圧縮して転送するようにしたので、転送量の面ではあまり問題にならなくなったのも方針変更の理由です。

ただ、画像アップローダーと行ったり来たりする必要があるのは、登録・編集するユーザーにとっては面倒かもしれません。画像アップローダー上の画像一覧から選択、みたいな機能があると良いかもしれませんが、今のところはコピー&ペーストでパスを貼り付けてもらうことになります(;^_^A

eco.acronia.net下のコンテンツ追加

各種DBをeco.acronia.netのURLでアクセスできるようにしてみました。

正直あまり意味は無いのですが、URLが短くなって、各種データベースがECO-Wiki付属っぽくなります*1。中身は完全に同じですが、色合いだけはちょっとECO-Wikiに似せてみました。

特に更新履歴などには書いていませんが、転送量・アクセス数削減のため4つのデータベースでCSSファイルを共通化したりもしています。


ついでに、ECO Simの転送URLも作ってみました。

結局 http://jasmin.sakura.ne.jp/eco/script/eco_sim/ に転送されるのであまり意味は無いのですが、短いURLの方が良い場面で使えるかも?

*1 : メニューの(外部)も取ってみました。

2015/03/26(木)PukiWiki If-Modified-Since(条件付きリクエスト)対応

PukiWiki If-Modified-Since(条件付きリクエスト)対応

別の日記に少し書いてますが、ECO-Wiki (acronia)をIf-Modified-Since(条件付きリクエスト)に対応させたので、その方法をメモしておきます。

If-Modified-Since(条件付きリクエスト)とは

If-Modified-Sinceを使うと、ページが更新されている時だけデータを送って欲しい、という要求ができます。

  • 初回アクセス
    1. [クライアント] ファイルください。
    2. [サーバー] はいどうぞ。ファイルの更新日時は「Wed, 25 Mar 2015 15:07:33 GMT」。(200 OK 応答)
  • 2回目以降:更新されてない場合
    1. [クライアント] 更新日時「Wed, 25 Mar 2015 15:07:33 GMT」のキャッシュ持ってるけど最新版ある?(If-Modified-Sinceフィールド)
    2. [サーバー] 更新されてないから、内容は送らない。そのキャッシュ使って。(304 Not Modified 応答)
  • 2回目以降:更新されている場合
    1. [クライアント] 更新日時「Wed, 25 Mar 2015 15:07:33 GMT」のキャッシュ持ってるけど最新版ある?(If-Modified-Sinceフィールド)
    2. [サーバー] 最新版あるので送る。(200 OK 応答)

PukiWikiでIf-Modified-Since対応する場合の問題

PukiWikiの場合、各ページの更新日時をどのような基準で決めるかが問題となります。

  • ページを編集した日時にした場合:pcommentやinclude先、メニューバーが更新されても、そのページは更新されたと見なされない
  • ページを構成しているファイル郡の中の最新更新日時にした場合:正しく動作するが、追加の処理が必要。負荷も増える。

対応方針

この問題は、bodycache適用時の問題と似ています。そこで、今回はbodycacheファイルの更新日時を対応するページの更新日時と見なすようにしました。

  • bodycacheファイルはpcommentやinclude先が更新されたときもアップデートされるようにしているので、更新見落としが起こらない
    • bodycache patch適用範囲拡大を実施していることが前提
    • メニューバーの問題については、メニューバー更新のたびにbodycacheを全削除*1することで対応

改造内容

主にread.inc.phpを書き換えます。

  • lib/bodycache.php
    • キャッシュファイルの更新日時を元にLast-Modifiedヘッダフィールドを返す関数
      • どこに書いても良いですが、bodycacheを前提にした記述なので、bodycache.phpに書きました。
        // Last-Modified header
        function header_lastmod_cache($page = NULL)
        {
            global $lastmod;
        
            if ( is_cache($page) && get_cachetime($page) != 0 ) { //get_cachetime==0の時は、そのキャッシュは破棄予定なので無視
                pkwk_headers_sent();
                header('Last-Modified: ' .
                    date('D, d M Y H:i:s', get_cachetime($page)) . ' GMT');
            } else if ( is_page($page) ) { //キャッシュが存在しない問いは現在時刻を使う
                header('Last-Modified: ' .
                    date('D, d M Y H:i:s', UTIME) . ' GMT');
            }
        }
        
  • plugin/read.inc.php
    • If-Modified-Sinceフィールドヘッダの内容をunixtimeに変換して返す関数
      function get_if_modified_since()
      {
          static $unixtime = null ;
          if ($unixtime !== null ) {
              return $unixtime ;
          }
      
          if (!isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
              $unixtime = false ;
              return false ; // If-Modified-Since なし
          }
          
          $unixtime = strtotime( $_SERVER['HTTP_IF_MODIFIED_SINCE'] );
          return $unixtime ;
      }
      ?>
      
    • plugin_read_action関数内の改造
      • 変更前
        if (is_page($page)) {
            // ページを表示
            check_readable($page, true, true);
            header_lastmod($page);
            return array('msg'=>'', 'body'=>'');
        
      • 変更後: 更新の有無を確認して、更新されていなかったら304 Not Modifiedを送って処理を打ち切ります。また、header_lastmod_cacheでLast-Modifiedフィールドを送るようにします。
        if (is_page($page)) {
            // ページを表示
            check_readable($page, true, true);
            
            $ims = get_if_modified_since();
            if ( $ims ) {
                $ctm = get_cachetime($page);
                if ( $ctm && $ctm <= $ims) {
                    // 更新されていない
                    header('HTTP/1.1 304 Not Modified') ;
                    header_lastmod_cache($page);
                    exit;
                }
            }
        
            //header_lastmod($page);
            header_lastmod_cache($page);
            return array('msg'=>'', 'body'=>'');
        

*1 : メニューバー更新と同時に、bodycacheファイルの更新日時を現在時刻に書き換えてしまう手もありますが、間違えて古いbodycacheを最新扱いしないように注意が必要です。

2015/03/10(火)ECO-Wiki アクセス状況 ~2015/03/09

ECO-Wiki アクセス状況 ~2015/03/09

2月末からのアクセス状況は以下のようになっています。

20150310_access_log.png

グラフ中のA、B、Cは、以下の対応を実施した時点です。

  • A: 画像の同時読み込み数制限
  • B: CSSとJSファイルについて、サーバーへの更新問い合わせ無しでキャッシュ参照する設定にした
  • C: Wikiページをif-modified-sinceに対して、304 Not Modified応答(キャッシュ参照)するように改良

土曜日、日曜日のアクセス数はそもそも多いという点に注意する必要がありますが、だいたいの傾向は以下のような感じでしょうか。

  • Aの後: 503がやや減ったかも
  • Bの後: 304 Not Modified応答が減少(更新問い合わせがなくなったため)
  • Cの後: 304 Not Modified応答割合がやや増えたかも?
    • ログ詳細を確認するとWikiは3000件/日くらい304 Not Modified応答を返している。今後に期待?
  • 最近1週間の503エラーの発生数は100件/日以下(ピーク時は1000件/日程度)

とりあえず、問題の503エラーについては改善傾向にあるようです。連絡しないと制限解除してくれないようですし、アクセス制限の解除依頼をしてもよいかもしれないですね。


追記: 2015/03/11

サポートに連絡して、アクセス数制限は現在解除されています。

制限を実施する条件は「サーバ運用に支障のある負荷が発生している場合」とのことで詳細はよく分からず。

追記: 2015/03/30

サポートからの回答があり、今回の制限については「サーバ負荷のピーク時にアクセス数が多かった」ためで、転送量やCPU使用量で判断したわけでは無いとのことでした。

2015/03/08(日)Kaspersky Internet Security 2015 にSSL通信をスキャンさせない

Kaspersky Internet Security 2015 にSSL通信をスキャンさせない

アドウェアSuperfishが問題になって気にする人もいそうなので書いてみます。

元は、以下の不具合について調べてたときの副産物です。(今はFirefoxにもちゃんと証明書がインストールされるようです。)
セキュリティ証明書絡みの不具合 - Kaspersky Lab Forum

KIS2015インストール時のSSL通信

  • IEの場合
    IE_cert_1.png
  • Firefoxの場合
    Fx_cert_1.png

このように、初期状態ではKasperskyのルート証明書になっていて*1、SSL通信がスキャン対象になっています。

SSL通信もしっかりスキャンしたい人はこれで良いですが、SSLはブラウザまでEnd-to-Endで暗号化して欲しいとか、本来の証明書が隠れるのが嫌とか、KISが本来の証明書をちゃんと検証しているのか心配、という人はSSL通信をスキャンさせないように設定変更できます。*2

SSL通信をスキャンさせない設定

  • 設定→詳細→ネットワーク、と設定項目をたどると、「暗号化された接続をスキャンする」という設定があるのでチェックを外します。
    KIS_setting_1.png
  • 上記設定だけだと、GoogleなどのSSL接続の検索サイトは、まだ危険サイト診断の対象のままです。そちらも解除するには、設定→プロテクション→ウェブ保護→詳細設定、と設定項目をたどると、「危険サイト診断を有効にする」という設定があるのでチェックを外します。
    KIS_setting_2.png
    • SSL通信スキャンとは関係ないですが、KISがブラウザに追加するアドオン*3を無効にしたい場合は、「製品のプラグインを全てのWebブラウザーで自動的に有効にする」のチェックを外す必要があります。
    • 危険サイト診断の内容ですが、「危険サイト診断の設定」をクリックして出てくる以下の設定画面からすると、一種のWebフィルタリングのようです。これらのコンテンツに不用意にアクセスしたくない/させたくないなら、有効にしておくのが良いかもしれません。
      KIS_setting_3.png

設定後

  • IEの場合
    IE_cert_2.png
  • Firefoxの場合
    Fx_cert_2.png

本来の証明書が表示されるようになりました。

なお、この設定だけではKasperskyのルート証明書は削除されないので、どうしても気になる人は削除しておきましょう。

*1 : SSL通信を傍受するにはMan-In-The-Middle(中間者)攻撃の要領で通信に割り込むことになるので、必然的に自前の証明書に差し替えることになります。アドウェアSuperfishがやっていることと技術的には同じですね。

*2 : セキュリティソフトにどこまでチェックさせるかは悩ましいところです。なお、KIS2014では、初期設定ではSSL通信はスキャンしていませんでした。

*3 : コンテンツブロック、セキュリティキーボード、ネット決済保護のアドオンが追加されます