月曜日

高還元率クレカ「漢方スタイルクラブカード」申し込んだ

ポイント還元率1.75%のクレカ「漢方スタイルクラブカード」

ポイント還元率の高いクレジットカードの情報を探していると必ず目にする「漢方スタイルクラブカード」
あまり手持ちカードを増やしたくなかったので指をくわえて見ていましたが、手持ちカードの使い勝手が残念になってきたため申し込んでみました。
1.75%という比類ない高還元率
1.0%でも高いほうと言われる中で、まさかの還元率1.75%
ポイント利用時の用途制限や目減りなし
還元されたポイントは、カード引き落とし額からの値引きに使えます。 「高還元率だけど特定のお店でしか使えない」とか「汎用の金券の交換レートが渋くて目減りする」ということもありません。
年会費はボーナスポイントで埋め合わせ可能
このカードは2年目からは年会費1,575円がかかりますが、年100万円以上使えばボーナスポイントが2,500円分つくのでお釣りが来ます。「見かけの還元率が高くても、年会費も高いので実質還元率は…」という心配もいりません。 (ただし、入会タイミングに関わらず「2月~翌年1月の利用額」で算定するようなので要注意)
nanacoチャージでもフル還元
nanacoチャージでもポイント1.75%還元です。何がうれしいかというと、クレジットカードが使えない支払い(税金など)も、セブンイレブンでnanaco支払いにすれば、実質的にクレカで払ったのと同じ還元が受けられるのです。 なお、Edyチャージにはポイントはつきません。Suicaチャージは…私はビックカメラSuicaカード持ってるのでそっちで。
還元率UPキャンペーンが年4ヶ月?
年に4ヶ月間くらいのペースで還元率が2.0%に上がるキャンペーンも行なわれています。 今後もあるかどうかは分かりませんが、2012年は2~3月度・9~10月度、2013年も2~3月度。次は半年後?

申込みから到着まで約半月

えんためねっとというポイントサイト経由で申込みました。約半月で到着。審査にあたって、(私の場合は)職場に在籍確認の電話はかかってこなかったようです。
カードは本人限定受取郵便で届くので、受け取るには住所地または指定した郵便局で、本人が身分証明書を提示する必要があります。(特伝型なので家族に代理で受け取ってもらうことはできません)

カード利用と明細掲載タイミング

還元率UPキャンペーンは「2・3月度の利用代金明細書で獲得するポイントがUP」のように行なわれますが、ではその期間の明細に載るにはいつ買い物をすればいいのでしょう?
2chによると、N月度の明細に載るには、店舗からアクワイアラーに伝票が下記の期間に上がる必要があるとか。
  • JACCS加盟店 … (N-1)月12日~(N)月11日
  • JCB加盟店(JACCS非加盟) … (N-2)月16日~(N-1)月15日
どのタイミングで伝票をアクワイアラーに上げるかは、店舗によって違うので注意。JACCS加盟店で(N)月11日に買い物をしても、店によっては(N)月ではなく(N+1)月の明細になる可能性があります。
なお、VISAは最近対応したばかりでまだ情報が少ない模様。

(N)~(N+1)月度のキャンペーンの場合、(N-1)月下旬~(N)月上旬あたりの買い物なら、大体どこのお店でも安全?

火曜日

WebKit版Operaのユーザエージェント

WebKitを採用したAndroid版Operaを試してみました。
Opera ブラウザ ベータ版

UserAgentはというと、
HTTP_USER_AGENT:
Mozilla/5.0 (Linux; Android 4.0.4; L-01D Build/IMM76D) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.123 Mobile Safari/537.22 OPR/14.0.1025.53005
もはやOperaだかMozillaだかChromeだかSafariだか判りません…!
肝心の「Opera」という文字列が含まれておらず「OPR」となっているのも不思議です。ベータだからでしょうか。

「データ圧縮モード」にすると、従来のOpera Miniになります。Prestoはお役御免になったわけではないようです。
HTTP_USER_AGENT:
Opera/9.80 (Android; Opera Mini/14.0.1025/28.4200; U; ja) Presto/2.8.119 Version/11.10
REMOTE_HOST:
s10-02.opera-mini.net

ちなみに現在最新のOpera MiniのUAはというと、
HTTP_USER_AGENT:
Opera/9.80 (Android; Opera Mini/7.5.32193/28.4200; U; ja) Presto/2.8.119 Version/11.10
バージョン番号が7.5から14.0に変わっただけで、中身は同じようです。

月曜日

CloudFlareの3種類のキャッシュレベルの違いを調べた

【この記事の概要】

前回⇒ CloudFlareでキャッシュ可否の条件は「URLの末尾がキャッシュ対象拡張子に見えること」だった

CloudFlareのキャッシュレベルは Basic / Simplified / Aggressive の3段階から選べますが、その違いがイマイチ解らなかったので調べました。


3段階のキャッシュレベルの違いは?

CloudFlareの「パフォーマンス設定」画面では、Caching Levelを下記3段階に設定できるとあります。
  • Aggressive: http://cloudflare.example.jp/pic.jpg?with=query
  • Simplified: http://cloudflare.example.jp/pic.jpg?ignore=this-query-string
  • Basic: http://cloudflare.example.jp/pic.jpg
言わんとすることはだいたい分かるんですが、具体的な挙動を見てみました。

BasicSimplifiedAggressive
(1) test.js○される○される○される
(2) js.cgi?q=.js○される○される○される
(3) test.html×されない×されない×されない
(4) js.cgi?1=.js&2=query×されない×されない×されない
(5) test.js?with=query×されない△されるけど※1○されるけど※2

(1)や(2)のように、URLがキャッシュ対象拡張子で終わっている(ようにみえる)なら、3レベルともキャッシュされます。
(3)(4)のように、URLが「キャッシュ対象拡張子」で終わっていない場合は、3レベルともキャッシュされません。

レベル設定で挙動が変わるのは、
(5)のような「キャッシュ対象拡張子で、クエリ文字列がある場合」です。

(※1) Simplifiedではクエリ文字列は削られるけど……?

キャッシュレベルがSimplifiedで、上記表の(5)のパターン、つまり「キャッシュ対象拡張子・クエリ文字列あり」の場合、次のような挙動になります。
  1. エッジサーバーからオリジンサーバーへは、クエリ文字列を取り除いてリクエストが送られる
  2. ただしキャッシュ内容はクエリ文字列付きのURLごとにそれぞれ保持される

ユーザー file.js?with=query
→①→

←④←
file.js?with=query
CloudFlare
エッジ
サーバー
file.js
→②→

←③←
file.js
オリジン
サーバー

挙動Aは文字どおりですが、Bがちょっと理解しにくいので、具体例で見てみます。
次のような、日時とURIをJavaScriptで出力するCGIスクリプトを用意しました。

#/usr/bin/ruby
puts "Content-type:application/javascript"
puts
puts "document.writeln('#{Time.now.to_s}');"
puts "document.writeln('#{ENV['REQUEST_URI']}');"
このCGIスクリプトに、js.cgi/pathinfo.js?with=query という形でアクセスしてみます。
$ curl -i 'http://cloudflare.example.jp/js.cgi/pathinfo.js?with=query'
HTTP/1.1 200 OK
CF-Cache-Status: MISS

document.writeln('Mon Mar 04 00:30:00 +0900 2013');
document.writeln('/js.cgi/pathinfo.js');

$ curl -i 'http://cloudflare.example.jp/js.cgi/pathinfo.js?with=query'
HTTP/1.1 200 OK
CF-Cache-Status: HIT

document.writeln('Mon Mar 04 00:30:00 +0900 2013');
document.writeln('/js.cgi/pathinfo.js');
1回目のアクセスでキャッシュが作られ、2回目のアクセスではそのキャッシュが返ってきています。
ENV['REQUEST_URI'] が「pathinfo.js」で終わっていて、「?with=query」が付いていません。クエリ文字列はエッジサーバーが切り落としたようです。

ここで、クエリ文字列を変えてアクセスしてみます。
$ curl -i 'http://cloudflare.example.jp/js.cgi/pathinfo.js?with=query2'
HTTP/1.1 200 OK
CF-Cache-Status: MISS

document.writeln('Mon Mar 04 00:32:22 +0900 2013');
document.writeln('/js.cgi/pathinfo.js');

$ curl -i 'http://cloudflare.example.jp/js.cgi/pathinfo.js?with=query2'
HTTP/1.1 200 OK
CF-Cache-Status: HIT

document.writeln('Mon Mar 04 00:32:22 +0900 2013');
document.writeln('/js.cgi/pathinfo.js');
さっきとは別のキャッシュがエッジサーバーに作られました。(Time.nowの出力する日時もさっきと違います)
しかし ENV['REQUEST_URI'] はこちらもさっきと同じ「/js.cgi/pathinfo.js」です。

というわけで、オリジンサーバーに対してはクエリ文字列を削った状態でアクセスしにくるけど、キャッシュはそれぞれ作成されるというよく分からない挙動です。
どうせクエリ文字列を切り落とすなら、キャッシュも共有してくれたほうが嬉しかったかも。

ちなみに、表の(2)のケースではクエリ文字列は削られずにオリジンサーバーに渡ります。
$ curl -i 'http://cloudflare.example.jp/js.cgi?q=.js'
HTTP/1.1 200 OK
CF-Cache-Status: MISS

document.writeln('Mon Mar 04 00:35:00 +0900 2013');
document.writeln('/js.cgi?q=.js');

(※2) Aggressiveでクエリ文字列がある場合、すぐにはキャッシュは作られない?

続いてキャッシュレベルがAggressiveで、キャッシュ対象拡張子・クエリ文字列ありの場合。
次のような挙動になります。

  1. 同一URL(同一クエリ文字列)に複数回アクセスがあっても、すぐにはキャッシュを作らない
  2. 何回かアクセスがあったらキャッシュを作り、以降のアクセスはキャッシュを返す
$ curl -i 'http://cloudflare.example.jp/js.cgi/pathinfo.js?with=query'
HTTP/1.1 200 OK
CF-Cache-Status: MISS

document.writeln('Mon Mar 04 00:40:00 +0900 2013');
document.writeln('/js.cgi/pathinfo.js?with=query');

$ curl -i 'http://cloudflare.example.jp/js.cgi/pathinfo.js?with=query'
HTTP/1.1 200 OK
CF-Cache-Status: MISS

document.writeln('Mon Mar 04 00:40:11 +0900 2013');
document.writeln('/js.cgi/pathinfo.js?with=query');

$ curl -i 'http://cloudflare.example.jp/js.cgi/pathinfo.js?with=query'
HTTP/1.1 200 OK
CF-Cache-Status: MISS

document.writeln('Mon Mar 04 00:40:22 +0900 2013');
document.writeln('/js.cgi/pathinfo.js?with=query');

$ curl -i 'http://cloudflare.example.jp/js.cgi/pathinfo.js?with=query'
HTTP/1.1 200 OK
CF-Cache-Status: HIT

document.writeln('Mon Mar 04 00:40:22 +0900 2013');
document.writeln('/js.cgi/pathinfo.js?with=query');
最初の3回はオリジンサーバーにアクセスが行っていますが、4回めでキャッシュが返ってきました。

キャッシュを作る条件が「同一クエリで(一定期間中に?)3回アクセスがあったら」なのかどうかは不明ですが、いきなりキャッシュが作られて使われるわけではないのは要注意。

たぶん検索フォームなどで「よく検索されるワードの検索結果はキャッシュして、あまり検索されないワードの検索結果は(ロングテールになってエッジサーバーのキャッシュヒット率が悪そうなので)キャッシュしない」という使われ方を想定しているんじゃないかと。

次回:キャッシュレベル設定では選べない特殊メニュー「Cache everything」

この記事では3種類のキャッシュレベルの挙動の違いを見ましたが、実は「パフォーマンス設定」の画面からは選べない第4の選択肢が存在するのです。それが「Cache everything」。

次の記事では、この「Cache everything」の挙動を確認します。

CloudFlareでキャッシュ可否の条件は「URLの末尾がキャッシュ対象拡張子に見えること」だった

【この記事の概要】

この記事を3行でまとめると、
  • CloudFlareでエッジサーバーがキャッシュしてくれるかどうかは、
  • URLの末尾が「キャッシュ対象の拡張子」に見えるか否かで決まる
  • (MIMEタイプは関係ない)

では、以下、本文です。

そもそもCloudFlareって?

CloudFlareは、無料でも転送量無制限で利用できるリバースプロキシ型サービスです。

Webサイトを運営する上で、「転送量」はなかなか頭の痛い問題です。
安いレンタルサーバーだと、ちょっとアクセスが増えるとすぐアクセス量制限に引っかかって“503 Service Temporarily Unavailable”が表示されがち。
“Bandwidth: Unlimited”をうたう海外レンタルサーバーを頑張って英語で契約してみたら、「転送量は無制限だがセッション数の上限を超えた」という理由でアカウントをsuspendされて、凍結解除の交渉を英語でするハメに陥ったり……。

そんな中で、無料プランでも転送量制限のないCloudFlareは、実にありがたい存在です。
以前はエッジサーバーが日本国内になかったので「CloudFlareを使うとサイトが遅くなる」という問題もありましたが、今では日本にもエッジサーバーが設置されたようで、pingを打つと最速で5msなんて数字を叩き出したりします。

CloudFlareはどういう動作をするの?

CloudFlareはリバースプロキシとして動作します。
つまり、対象WebサーバーへのすべてのアクセスはCloudFlareのエッジサーバーを経由します。
ユーザー →①→
←④←
CloudFlare
エッジ
サーバー
→②→
←③←
ウチの
Web
サーバー

その際、特定のファイルをエッジサーバーにキャッシュしてもらうことができます。
キャッシュされたファイルは、アクセスがエッジサーバーで折り返すようになります。
ユーザー →①→
←②←
CloudFlare
エッジ
サーバー
   
ウチの
Web
サーバー
こちらのWebサーバーまでアクセスが来ないので、転送量などの資源を節約できるというわけです。

CloudFlareがキャッシュするファイルとは?

CloudFlareがどんなファイルをキャッシュしてくれるのかと言うと、具体的にはFAQ(What file extensions does CloudFlare cache for static content?)に列挙されています。
ざっくり説明すると、以下のような拡張子を持つファイルです。
  • .css
  • .js
  • .jpg/gif/png/ico/svgなどの画像ファイル
  • .pdf/csv/doc/ppt/xlsxなどのドキュメントファイル
  • .swf
  • .midi/mid
  • .pls(プレイリストファイル)

逆に言うと、リストに含まれない次のようなファイルはキャッシュされません。
  • .html/xhtml
  • .cgi/php
  • .xml
  • .json
  • .zip/bz2/rar
  • .mp3/mp4/flv
  • その他、リストに記述されていない拡張子のファイルすべて

(これらのファイルもキャッシュしてもらう方法もあるのですが、それは次回)

キャッシュ可否を決めるのはMIMEタイプ? 拡張子?

拡張子.jsはキャッシュされて、拡張子.cgiはキャッシュされない――となると気になるのが「JavaScriptを出力するCGI」はキャッシュされるのか、それともされないのか。
そこで実験してみました。

用意したのは、下記のようなJSを出力するCGIファイル。
#!/usr/bin/ruby
puts "Content-type:application/javascript"
puts
puts "document.writeln('#{Time.now.to_s}');"

これをCloudFlare経由で、以下のURLでアクセスしてキャッシュされるかどうか見てみました。

js.cgi×キャッシュされない
js.cgi/pathinfo.js○キャッシュされる
js.cgi?query=.js○キャッシュされる

MIMEタイプだけではダメで、PATH_INFOでもQUERY_STRINGでもいいからURLの末尾が対象拡張子で終わっている必要があるようです。

【確認内容】(レスポンスヘッダは一部省略)
キャッシュされる場合:
$ curl -i 'http://cloudflare.example.jp/js.cgi/pathinfo.js'
HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Mon, 04 Mar 2013 00:00:00 GMT
Content-Type: application/javascript
CF-Cache-Status: MISS
Expires: Mon, 04 Mar 2013 02:00:00 GMT

document.writeln('Mon Mar 04 09:00:00 +0900 2013');
※↑1回目のアクセス:まだキャッシュがなかった(この内容でキャッシュが作られる)

$ curl -i 'http://cloudflare.example.jp/js.cgi/pathinfo.js'
HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Mon, 04 Mar 2013 00:00:12 GMT
Content-Type: application/javascript
CF-Cache-Status: HIT
Expires: Mon, 04 Mar 2013 02:00:12 GMT

document.writeln('Mon Mar 04 09:00:00 +0900 2013');
※↑2回目のアクセス:キャッシュが使われている

キャッシュされない場合:
$ curl -i 'http://cloudflare.example.jp/js.cgi'
HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Mon, 04 Mar 2013 00:00:30 GMT
Content-Type: application/javascript

document.writeln('Mon Mar 04 09:00:30 +0900 2013');
※↑1回目のアクセス:CF-Cache-Statusヘッダがない

$ curl -i 'http://cloudflare.example.jp/js.cgi'
HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Mon, 04 Mar 2013 00:00:42 GMT
Content-Type: application/javascript

document.writeln('Mon Mar 04 09:00:42 +0900 2013');
※↑2回目のアクセスでもキャッシュされていない

ちなみに、CGIのレベルでExpiresレスポンスヘッダをわざわざ吐いても、結果は変わりませんでした。

クエリ文字列の末尾が拡張子っぽく見えること

「クエリ文字列が拡張子っぽい場合」の挙動をもう少し掘り下げてみます。

1) js.cgi?1=query&2=.js○キャッシュされる
2) js.cgi?1=.js&2=query×キャッシュされない
3) js.cgi?1=query&2=js×キャッシュされない

1)のように、URLの末尾がキャッシュ対象拡張子であれば、クエリが複数あってもキャッシュされます。

ただし、2)のように、クエリの順番を入れ替えるとキャッシュされなくなります。
3)は1)のクエリの「.js」を「js」に置き換えた(ピリオドを削った)ものですが、これもキャッシュされません。

どうやら「URLの末尾が拡張子に見える」という形式を必ず守らなければならないようです。

次回

CloudFlareの3種類のキャッシュレベルの違いを調べた
CloudFlareのキャッシュレベルは Basic / Simplified / Aggressive の3段階から選べますが、その違いについて調べます。

LinkWithin


Related Posts with Thumbnails