技術日誌
数年前までは、CPUのクロック数がどんどん上がっていき、それに伴いどんどん性能が良くなっていくというイメージだった。しかし、最近のCPUはなんだか素人には分かりづらい。。自分自身いまいちピンとこなかったのですが、『Googleを支える技術』という本を読んで消費電力の観点からそんな話をしており、イメージがわいた。
ちょっと前は、Pentium 4 3.8GHz といった CPU周波数をどんどん高めたモデルが出ていたが、最近は Core 2 Quad 2.83GHz といった 前より周波数の低いモデルが販売されている。では、性能が悪いのかというと、そんなことはなさそうだ。多分。。ではその裏側で、どんな理屈が隠されているのか・・・
どうも、Pentium 4 までは効率を無視してでも処理性能を追求していたようですが、消費電力が無視できない状況まで到達した。
http://www.itmedia.co.jp/news/0104/18/idf_keynote3.html
そこで、マルチコア（１つのCPUパッケージの中に複数のCPUコアを入れる）化することで、性能向上と、消費電力の削減の２つを同時に行おうとしているみたい。
http://www.intel.co.jp/jp/business/japan/event/IDF_2006/index.htm
バランスが大事だと。そんな話になっている。でも、実際は効率良くマルチスレッド化されたプログラムならマルチコアで性能を最大限に発揮できるが、通常使用しているデスクトッププログラムなどの場合はそんなに動作速度に向上はないような気がする。
この先、CPUの性能をバランスと効率で追求していくのなら、それに伴うプログラミングという技術が必要になってくるのかも知れない。
盗聴による危険があるとはいえ、何より実装が簡単なBasic認証。
裏側で何が起こっているのか正確に把握したい。
仕組みとしては単純
(1) HTTPクライアントであるWebブラウザがリクエストの度に毎回 『ユーザー名/パスワード』 のセットをWebサーバーに送信。
(2) Webサーバーは上記が正しければページを返す。『ユーザー名/パスワード』 のセットが間違っているもしくは送信しなかった場合は、レスポンス 『401 Authorization Required』 を返す。
HTTPプロトコル仕様上、クライアント側から見て毎回
『接続 → ファイル要求 → ファイル受信 → 切断』
を繰り返している為、サーバー側では毎回要求に対しての認証処理を行う必要がある。
Basic認証では、毎回クライアントから『ユーザー名/パスワード』の情報を送信することで認証するという単純な考え方で実現されている。
(1) の『ユーザ名/パスワード』の送信はクライアントから送信するHTTPヘッダーに下記の文字列を加えることで実現する。
-----------------------------------------------------------
Authorization: Basic aG9nZTptb2dl
-----------------------------------------------------------
『aG9nZTptb2dl』は、ユーザ名:パスワードを Base64 エンコードした文字列で可逆変換。下記のようにエンコード/デコード できる。(ユーザー：hoge パスワード：moge の場合)
[hyaku@hyakutem hyaku]$ echo -n 'hoge:moge' |nkf -MB
aG9nZTptb2dl[hyaku@hyakutem hyaku]$
[hyaku@hyakutem hyaku]$ echo -n 'aG9nZTptb2dl' |nkf -mB
hoge:moge[hyaku@hyakutem hyaku]$
(2) のサーバー側では、.htpasswd などに記載された『ユーザー/パスワード』の情報と受信した『ユーザー/パスワード』が一致するかチェックする。
---<.htpasswdの生成例と中身>----------------------------
[hyaku@hyakutem hyaku]$ htpasswd -bc .htpasswd hoge moge
Adding password for user hoge
[hyaku@hyakutem hyaku]$ cat .htpasswd
hoge:QCFLlFCom8GDU
[hyaku@hyakutem hyaku]$
-----------------------------------------------------------------------
上記のパスワード部分は、通常 crypt により暗号化されており、不可逆変換。(総当たりのパスワードクラックにより解読可能だが、時間はかかるという状態。)
Webサーバーは、クライアントから受信したパスワードと、上記.htpasswdファイルのパスワードの最初の２文字(salt)を使用してパスワードの一致をチェックする。(受信したパスワードを暗号化して、暗号化したパスワードの一致をチェックする)
[hyaku@hyakutem hyaku]$ perl -e 'print crypt("moge","QC")'
QCFLlFCom8GDU[hyaku@hyakutem hyaku]$
ポイントは、『毎回クライアントからパスワードを送信していて、かつ、Base64 エンコードしているだけなので簡単に元に戻せる。』というところか。そう考えると、通信自体がすべてSSL等で暗号化されていれば基本的には問題ない。しかし、ブラウザが間違えて違うサイト(SSL暗号化なし)にパスワードを送ってしまったらどうなるの？ 等、『そんなことはブラウザつくった人に聞いてくれ！』ということも考えなくてはならなくなるのか。難しいところだ。