2010年11月28日日曜日

PythonでSqlite3に大量のデータをInsertしてみた

次はPython2.xでSqlite3に対して大量のデータをinsertしてみました。
尚、Sqlite3は少なくとも最新のPython2.xでは内部に組み込まれている為、特に何かをインストールする必要はありません。

これもPythonのDocumentを参照して以下のようなコードを作成して実行しました。
#!/usr/bin/env python
import csv
import sqlite3
import time

if __name__ == '__main__':
    start = time.time()
   c = sqlite3.connect('./testdb')
    i = 0
    reader = csv.reader(open("./neta.csv"))
    for row in reader:
        id = row[0]
        value = row[1]
        t = (id,value,)
        c.execute('insert into hash (id,value) values(?,?)',t)
        i += 1
        if i % 100000 == 0:
            c.commit()
            print "commit! %d" % i
    c.commit()
    c.close()
    end = time.time()
    print end-start
前回同様、neta.csvというファイルを1件ずつ読み込み、testdbのhashテーブルに対してデータをinsertしてます。100万件のデータをinsertするのにかかった時間は27.1sでした。

・上記の例では10万件でcommit()するようにしましたが、30万件程度に1回のcommit()とした場合、若干パフォーマンスがあがりました。
・pythonのsqlite3モジュールはデフォルトではAutoCommitではないようで明示的にCommitしなければ、データが格納されません。因みに、Connectの際に以下のように変更する事でAutoCommitと出来るようです。
c = sqlite3.connect('./testdb',isolation_level=None)
やってみると、我慢出来ない位、遅くなります。

PythonでMongoDBに大量のデータをinsertしてみた

今回はPython2.xでMongoDBに大量のデータをinsertしてみました。

PythonでMongoDBにアクセスするには、PyMongoというモジュールを使用します。
http://api.mongodb.org/python/1.9%2B/index.html


掲載されているDocumentに従い、以下のようなコードを作成して実行しました。
尚、以前にも使用したCSV(neta.csv)をinsertネタに使っています。
#!/usr/bin/env python
import csv
import pymongo
import time

if __name__ == '__main__':
    start = time.time()
    c = pymongo.Connection()
    db = c.testdb
    reader = csv.reader(open("./neta.csv"))
    for row in reader:
        id = row[0]
        value = row[1]
        t = {"id":id , "value":value}
        db.hash.insert(t)
    end = time.time()
    print end-start
CSVを1件ずつ読み込み、1件ずつネタをhashコレクションにinsert()を実行します。MongoDBでは特にCommitの概念はありません。100万件のデータをinsertするのに要した時間は234.9sでした。

2010年11月10日水曜日

MongoDBのCSVロード機能をSqlite3、PostgreSQLと比較してみた

DBMSにはCSV等の外部ファイルを一括ローディングする機能があるものがあります。今回はMongoDB,Sqlite3,PostgreSQLのCSVローディング機能を実行して速度を比較してみました。

0.CSVネタの準備
郵便番号のCSVがあったのでこれを使おうと思いましたが、思うところあって約50MBのデータを自作しました。1フィールド目=番号、2フィールド目=番号のSha1値という非常に簡単なもので、100万行分作成しました。(Pythonで作成してます)
↓こんな感じ…
------------------------------------------------
1,356a192b7913b04c54574d18c28d46e6395428ab
2,da4b9237bacccdf19c0760cab7aec4a8359010b0
3,77de68daecd823babbb58edb1c8e14d7106e83bb

999999,1f5523a8f535289b3401b29958d01b2966ed61d2
1000000,b27585828a675f5acfef052dd1a8cf0c6c1ee4b0
------------------------------------------------

↓Pythonで作成する際は以下のような感じで・・・
---------------------------------------------------
import hashlib

i=0
while i < 1000000:
 i += 1
 print str(i)+","+hashlib.sha1(str(i)).hexdigest()
---------------------------------------------------


尚、以下の確認は家のローカルPC(Dell製)で行いましたが、

CPU→ Celeron(R) Dual-Core CPU  T3000  @ 1.80GHz
OS→ Fedora13
です。



1.MongoDB

MongoDBにはmongoimportコマンドというものがあり、CSVファイルを一括ローディング可能です。以下のような形で実行しました。今回はtimeコマンドで時間を測定しています。

[user@user ~]$ time mongoimport -d test -c hash --dbpath /home/user/mongodata/ -f id,value --type csv --file /tmp/neta.csv

testデータベースのhashコレクションにid,valueというカラムを持ったneta.csvを格納します。結果は以下です。
----------------------
real    0m40.137s
user    0m30.579s
sys     0m8.410s
----------------------
何度か行いましたが、大体同じような結果になりました。
尚、他のデータでもやってみましたが、mongoimportコマンドは数字のみの値については全てnumber型?と解釈するようで、前に0が埋まっている数字を文字列としてローディングしようとしても前0は全てカットされました。また"--type CSV"を指定しないと、大量のエラーが出力されます。

※MongoDBのバージョンはv1.6.2です。


2.Sqlite3

.import コマンドによりCSVネタのローディングが可能です。
まず、TABLEを作成しました。
sqlite> create table hash ( id INTEGER PRIMARY KEY , value TEXT );

その後、
以下のコマンドでローディングを行います。
[user@user ~]$ time sqlite3 testdb ".import '/tmp/neta.csv' hash"
testdbのhashテーブルに対してneta.csvをローディングしました。
結果は以下の通りです。
----------------------
real    0m8.961s
user    0m6.609s
sys     0m0.949s
----------------------

すこしはまったのですが、sqlite3はデフォルトのDelimiterは"|"らしいのでCSVネタを
1|356a192b7913b04c54574d18c28d46e6395428ab
のように作成しなおしました。

※Sqlite3のバージョンは3.6.22です


3.PostgreSQL

COPYコマンドによりCSVの一括ローディングが出来ます。

まず、以下でテーブルを作ります。
testdb=# create table hash ( id integer PRIMERY KEY , value TEXT ) ;

その後、
COPY hash FROM '/tmp/neta.csv' DELIMITER '|' ;
と記載したファイル(copy.txt)を作成し、以下を実行します。

-bash-4.1$ time psql testdb -f /tmp/copy.txt
testdbに対してcopy.txtに記載してあるCOPYコマンドを実行しました。
結果は以下の通りです。
----------------------
real    0m12.746s
user    0m0.001s
sys     0m0.003s
----------------------

※PostgreSQLのバージョンは9.0です。


まとめ
Realだけで比較すると以下になります。
Mongodb…0m40.137s
Sqlite3…0m8.961s
Postgresql…0m12.746s

パフォーマンスが一番良いと勝手に考えていたMongoDBは実は一番悪いという結果になりました。もちろんこれだけでその製品のパフォーマンスを語る事は出来ませんが、少なくともCSVのローディング機能についてはSqlite3やPostgreSQLに軍配があがりました。

と言うか、MongoDB遅すぎっ!

これがMongoDBの構造的な問題なのか、まだまだ改善の余地があるのかは不明です。また、上記確認ですが、全てインストール時のデフォルトの状態で実施しており、何らかのパラメータをいじってチューニング、、、みたいな事は一切していません。

2010年10月27日水曜日

お掃除ロボ ルンバ527

SEの仕事とは全く関係無い話です。。

前から気になっていたお掃除ロボ・ルンバ。近所のK'sデンキに行った際に思わず買ってしまいました。値段は46,000円。ルンバの隣には何やら安い廉価版みたいな自動掃除機もあったので店員にどう違うのか聞いてみると、彼曰く、、
「これはルンバの二番煎じ。全然売れてないです。やっぱりルンバですよ」
との事。値段は高かったですが、我が家は共働きで、休日以外に全く掃除機をかけない為、外出中に勝手に掃除してくれる事を期待して思い切って購入しました。

で、実際に使ってみて感じた事は以下です。
・案外、吸引力は無い
・普通の掃除機ほどでは無いが、それなりにうるさい。(昔のラジコンみたいな音がします)
・電気コードに引っかかってしまい、抜け出せなくなる事がある
・掃除機をかける為に、床に落ちているものを片づける必要有
・K'sデンキに置いてあったパンフレットには「人口知能」と宣伝されていたようだが、そのかけらも感じない
・突然、掃除するのを止めるように思う
・じっと見てると、「何故そっちばっかり行くのか?!」と多少いらつく
・毎回、ロボの中のごみを取る必要があるが、これが意外と面倒
・我が家のソファー下を掃除してくれる事を期待したが、高さ制限で入れずっ!

と、否定的な事ばかり書いてしまいましたが、家を出る時に掃除をスタートさせて、帰ってきたら「それなりに」綺麗になってる感じがするので、「それなりに」重宝しています。

改善してほしいなと強く感じるのはやはり吸引力でしょうか。ルンバだけでその他の掃除機はいらなくなるのかなと思っていましたが、ルンバは所詮サブ掃除機としてしか使えません。それと、もう少し効率的に掃除出来ないのかっ?とも思います。しかし、これはカメラ等を搭載の上で、映像から位置を掃除機自身が把握したりしないとダメかなーと思います。まあ10年以上先の事ですかね。

尚、私が買ったのはルンバ527という一番安いモデルですが、上位機種では
・充電が必要になったら勝手に充電してくれる
・タイマーで自動起動してくれる
との事です。私は全くこれらの機能に魅力は感じませんが。。。

汚い写真ですが、これが我が家のルンバ527


高さはティッシュボックスより少し高い程度?
我が家のソファーの下には残念ながら入れませんでした。。

2010年10月15日金曜日

よく分からないCAP定理の話をしよう

MongodbやCassandra等の最近流行のNosqlの紹介に何故かついてくる「CAP定理」。その内容はさらっと書くと以下との事。


分散システムでは以下の3つのうち、2つしか満たす事は出来ない。
C:Consistency(一貫性)
A:Availability(可用性)
P:Tolerance to network Paritions(ネットワーク分割耐久性※)
※造語です。


で、例えばMongoDBはCPのシステムですよー。CassandraはAPのシステムですよー。OracleやPostgresql等の従来型RDBはCAですよー。という解説が大体続く。


上記説明を聞いて、「はっ??」と思う人は多いんじゃないでしょうか。
私がよく分からなかったポイントは以下です。


・C(一貫性)の定義が不明。私はACID特性の"C"を連想してしまう。Mongodb等はTransactionの概念が無く、ACIDもくそも無いはずだ。


・A(可用性)の定義も不明。例えばMongodbは"A"が無いという分類になっているが、障害が起きたらしばらく復旧できない、とか、Dataが消失する。。という事を連想してしまう。それは無いだろう。


・P(ネットワーク分割耐久性)の定義も不明。何となくだが、スケールアウト出来るか、出来ないか?という事だろうが、OracleのRAC等は"P"では無いのだろうか。


と言う訳で、CAPのそれぞれの意味を深く考える事がCAP定理の理解につながると考え、色々調べてみました。


CAP定理をGoogleで検索してみた。役に立ちそうなのは以下。。。


http://www.hyuki.com/yukiwiki/wiki.cgi?BrewersCapTheorem
↑訳は間違ってはいないと思うが、この記事の内容は日本語にすると何だか変な気がします。


http://yohei-y.blogspot.com/2009/03/cap-base.html
↑CAP定理が生まれるまでが分かりやすい流れで記載されています。


http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
↑Brewerさんが問題提起した時のスライド。この中でCAP-theoryという用語で出てきます。(読みましたが、意味があんまり分かりません)


http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&rep=rep1&type=pdf
↑CAP定理の証明、らしい。どういうものかと思ってたが論理学?っぽい。
  この論文の中にC、A、Pのそれぞれの定義が記載されている。(上記に同じくよく分かりません)


http://el.jibun.atmarkit.co.jp/forest1040/2009/06/caporacle-rac12.html
↑ORACLE RACの例を取ってCAP定理を解説しています。


日本語の本では以下の解説が分かりやすかったです。

クラウド・アーキテクチャの設計と解析―分散システムの基礎から大規模データストアまで




・・・私の思考過程は省きます



【まとめ】
CAP定理のC、A、Pの定義は"大体のところ"以下だと思う。


Consistency:
あるデータを更新後、他のユーザからの参照時に必ず更新後のデータが読める事。
※ACIDでの"C"とは直接関係は無い。


Availability:
いつでも、ストレス無くデータの読み書きが可能な事。
※高可用性を意味する"High Availability"とは関係が無い。


tolerance to network Partitions:
データを複数のサーバに分割保持する事。
※Oracle RACはデータファイルを分散して持てない為、これには該当しない。(ように思う)

"CA"を満たすシステムの例
→従来型のRDBMS(Oracle,Mysql,Postgresql ...etc)


"CP"を満たすシステムの例
→DNS等


"AP"を満たすシステムの例
→分散データベース等


分からなかったのはココには、"AP"の例としてCassandra,CouchDBを挙げ、"CP"の例としてMongoDBを挙げているのですがなぜなのか分かりませんでした。


また、"A"の定義がやはりあいまいだと感じます。どんなDBMSでも程度の差はあれ一貫性を保つ為に排他制御を行ってるし、それがどの程度でストレスになるかは人によって違いますし。


しかし、この"CAP定理"、米国のwikipediaにも掲載されていませんし、Net上でもあまり目にかかりません。そこまで気にする必要は無いのかなと感じました。

2010年10月9日土曜日

HackerJapan

HackerJapanという雑誌。

前から少し気になってはいたんですが、いつも行く本屋ではなんだかやばそうな雑誌群の近辺にあったので確認はしていませんでした。
今回、何となく手にとって確認しましたが、驚くほど普通のセキュリティ関連雑誌です。初心者にも分かりやすく解説しており、非常に好感が持てました。

http://www.byakuya-shobo.co.jp/hj/

セキュリティ関連の仕事をしてる人は要チェックかと。。

2010年10月2日土曜日

ITゼネコンビジネスモデル

Web+DB Press(No.58)を久しぶりに買って読みました。その中で記事の一つが色々と考えさせてくれる内容だったので紹介します。

題は「なぜ日本のソフトウェアが世界で通用しないのか」というもの。米国と日本のソフトウェア産業の仕事のやり方を比較していますが、日本でのソフトウェア開発は、ITゼネコンビジネスモデル(大手ベンダが仕事を受注し、実際のプログラミングは下請けベンダが行う構図)であり、その事が以下のような副作用ともたらしているとの事。

・結果的にソフトウェア開発が労働集約型のビジネスモデルとなってしまっている
・必然的にウォーターフォール開発となり、人手と手間がかかりがち
・IT関連企業の海外での競争力低下
・ベンチャー企業を立ち上げにくい環境
・エンジニアの地位の低下

ソフトウェア産業は本来知識集約型産業であり、ソフトウェアは流れ作業で大量に作れるものでは無く、優秀な頭脳により作りあげるものだ。日本企業のやり方だとソフトウェア開発の優秀な人材は海外に流れていくのでは?と結んでいます。

私は「海外ではこうだ。それに引き換え日本はこうだからダメなんだ」的な記事は好きにはなれませんが、そもそもなぜ日本がITゼネコンビジネスモデルになっているかを考える必要があると思います。

海外は知りませんが、日本のIT現場では「人月」がまるで通貨単位のように現状では使われています。見積もりの段階でも、XX人月なんでXX円です。という金額計算が使用されてます。変な話ですが、「なぜ、XX円なんですか?高く無いですか?」という質問に対して「この作業がXX人月だからです」という変な会話も日本のIT業界だと十分ありえる話です。

そこでプライムベンダーはXX人に相当する人数を連れてこようとしますが、一人当たりの金額を下げないと利益は出ない為、本当に何も分かっていない人を連れてきたりします。そういうIT知識がほぼゼロの人でもものづくりに参加させるには、設計書を出来るだけ細かく書き、プログラミングをほぼタイピングのようにさせる必要があります。

全部がこのような発想とは言い切れませんが、日本ではプログラミング作業=タイピング作業ととらえている節があります。自動車工場で自動車を作るようにシステムを作り上げようという発想でしょう。まさに労働集約型+ITゼネコンビジネスモデルです。

と、本当に簡単に書きましたが、上記が日本のIT現場の典型的な仕事のしかたではないでしょうか。もちろん、Webサービスを展開する企業や、ミドルウェア等を自社で作っている会社はこの限りではありません。


現状は確かに問題点が多いとは思いますが、変わるのは時間がかかりそうです。

2010年9月28日火曜日

HTTPHeaderの"Server"をいろいろ確認してみた(ドイツDAX編)

HTTPHeaderのServerをドイツの株式指数(DAX)を構成している銘柄で確認してみました。
英語社名をgoogleで検索しましたが、困ったのはgoogleで1位となるのはドイツ語のサイトでは無かった為、ドイツ語のページがあればドイツ語のページを確認し、英語のページしか見当たらない場合には英語のページを確認しました。結果は以下の通り。。。



アディダス Microsoft-IIS/6.0
アリアンツ Apache
BASF
-
バイエル Microsoft-IIS/7.5
バイヤスドルフ Consultix WebServer
BMW BMW Webservice
コメルツ銀行 Apache
ダイムラー IBM_HTTP_Server
ドイツ証券取引所 -
ドイツ銀行 -
ドイツ・ポストバンク Apache
ドイツポスト WEB
ドイツテレコム Apache
エーオン Apache/2.0.59(Unix)  PHP/5.2.3  mod_jk/1.2.23  mod_ssl/2.2.13 mod_perl/2.0.3 Perl/v5.8.8
フレゼニウス -
ヘンケル Apache/2.0.49 (Linux/SUSE)
インフィニオンテクノロジーズ Apache-Coyote/1.1
ルフトハンザドイツ航空 IBM_HTTP_Server
リンデ Microsoft-IIS/6.0
マン Apache-Coyote/1.1
メトロ Microsoft-IIS/5.0
メルク -
ミュンヘン再保険 Microsoft-IIS/6.0
RWE Server
SAP Microsoft-IIS/6.0
K+S Apache/2.2.10(Unix) DAV/2 mod_jk1.2.27 mod_ssl/2.2.10 OpenSSL/0.9.8a
シーメンス Microsoft-IIS/7.0
ザルツギッター Zope(Zope 2.7.5-final, python 2.3.5,linux2) Zserver/1.1
ティッセンクルップ Apache/2.2.13(Unix) mod_ssl/2.2.13 OpenSSL/0.9.8k  DAV/2  PHP/5.2.10
フォルクスワーゲン Apache

NYダウよりも若干Server名を変更してたり、Server名を出して無かったりする会社が多いかなー。。。というところでした。まあ、何回もやってるのであまり新鮮味は無いです。



尚、FireFoxで簡単にServerヘッダが分かる・・・と以前書きましたが、正確にはアドオンでLiveHTTPHeaderを入れれば分かる。。でした。



2010年9月19日日曜日

HTTPHeaderの"Server"をいろいろ確認してみた

HTTPには応答headerとして"Server"があります。クライアント側から送信する"User-Agent"のサーバ版みたいなものなんですが、セキュリティ監査等で「"Server"を表示していると、サーバ側のハードやミドルウェアが攻撃者に分かってしまう為、消した方が良い」と指摘される事があります。
日本の大企業は一体"Server"をどういう設定をしているのか?以下はTOPIXを構成する銘柄100社のServerヘッダを確認した結果です。"-"はServerヘッダが無かった企業です。以外に少ないのが以外でした。(FireFoxだと簡単にHTTPヘッダの値が確認できます) 日本語の社名をgoogleで検索し、1位にヒットしたページを確認してます。



国際石油開発帝石 Apache
大和ハウス工業 Mircosoft-IIS/6.0
積水ハウス Apache/2.0.46 (Red Hat)
キリンホールディングス Apache
日本たばこ産業 Apache
セブン&アイ・ホールディングス Apache
東レ Apache/2.0.61 (Unix)
旭化成 Sun-ONE-Web-Server/6.1
住友化学 Apache
信越化学工業 Apache
三菱ケミカルホールディングス Apache
花王 Mircosoft-IIS/6.0
武田薬品工業 Apache
アステラス製薬 Apache
エーザイ
第一三共 Apache
ヤフー
富士フイルムホールディングス Apache
資生堂 Mircosoft-IIS/6.0
新日本石油 Apache
ブリヂストン httpd
旭硝子 Apache/1.3.37(Unix)mod_jk2/2.0.4 mod_ssl/2.8.28 OpenSSL/0.9.7m
新日本製鐵 Apache
住友金属工業 IBM_HTTP_Server
神戸製鋼所 Apache
JFEホールディングス Apache
住友金属鉱山 Apache/2.0.52 (CentOS)
住友電気工業 Apache/2.0.59(Unix) mod_ssl/2.0.59 OpenSSL/0.9.9a mod_jk/1.2.19
SMC Mircosoft-IIS/6.0
小松製作所 Apache
クボタ Apache
ダイキン工業 Apache
日立製作所 Apache
東芝 Apache/MAGNIA
三菱電機 Apache
日本電産 Zope(unreleased version, python2.3.3, linux2) Zserver/1.1
日本電気 Apache
富士通 Apache
パナソニック
シャープ Apache
ソニー Apache
TDK Mircosoft-IIS/6.0
キーエンス
デンソー Apache/1.3.41 (Unix)
ファナック Apache
ローム Apache
京セラ Apache
村田製作所 Apache
日東電工 Apache
三菱重工業 Apache
日産自動車 IBM_HTTP_Server/6.0.2.7 Apache/2.0.47(Unix)
トヨタ自動車
本田技研工業 IBM_HTTP_SERVER
スズキ Apache/2.0.46 (Red Hat)
ニコン Apache
HOYA Apache/2
キヤノン Apache
リコー Sun-ONE-Web-Server/6.1
凸版印刷 Apache
大日本印刷 Apache
任天堂 Apache
伊藤忠商事 Sun-ONE-Web-Server/6.1
丸紅 Apache/2.2.15(Unix) mod_ssl/2.2.15 OpenSSL/0.9.8m
三井物産 Apache
東京エレクトロン Apache
住友商事 Apache/2.0.52 (Red Hat)
三菱商事 Apache
イオン Apache
三菱UFJフィナンシャル・グループ Apache
りそなホールディングス IBM_HTTP_Server
三井住友フィナンシャルグループ IBM_HTTP_Server
横浜銀行 Apache
住友信託銀行
みずほフィナンシャルグループ Apache
オリックス Apache
大和証券グループ本社 httpd
野村ホールディングス
三井住友海上グループホールディングス Apache
損害保険ジャパン Mircosoft-IIS/6.0
東京海上ホールディングス Apache
T&Dホールディングス Apache/2.0.52 (Red Hat)
三井不動産 Apache
三菱地所 Apache
住友不動産 Apache
東日本旅客鉄道
西日本旅客鉄道 Apache/2.0.52 (Red Hat)
東海旅客鉄道 IBM_HTTP_Server
商船三井 Apache
日本電信電話 Apache
KDDI Apache
エヌ・ティ・ティ・ドコモ Apache
東京電力 Apache
中部電力 Apache
関西電力 Apache
東北電力 (Unix)
九州電力 Apache
東京瓦斯 Apache
セコム Sun-ONE-Web-Server/6.1
ヤマダ電機 IBM_HTTP_Server/1.3.6.4 Apache/1.3.7-dev (Win32) PHP/4.3.10
ソフトバンク Apache

この調査をするまではServerなんて誰も表示していないだろうと思ってましたが、結果は意外にもほとんどがServerを表示していました。"Apache"については細かいバージョンを出さなければ問題は無さそうですが、IIS、IBM、SUN のように思い切り名前を出している場合があり、即脆弱性がどーのという話にはなりませんが、あまり好ましくないように感じます。

個人的に笑えたのは以下です。
・ヤマダ電気→IBM_HTTP_Serverのバージョンが古すぎないだろうか?
・日本電産→Zope(unreleased version, python2.3.3, linux2) Zserver/1.1 とある。ここまでOSSの名称を出すのは珍しい。同社はPythonが好きだと思われる。
・東芝→Apache/MAGNIA MAGNIAとは自社で出しているIAサーバのブランド名のようである。自社愛なんだろうか。
・セコム→同社は情報セキュリティ分野にも強い。思いっきり"SUN"と出ていて少しがっかりした。

【番外編】
三菱東京UFJ銀行のHPを個別に確認したところ、、
"MUFG Web Server/1.0"と表示された。
いつバージョンが1.1になるのか目が離せない。
↑ここからも分かるように現状ではサーバ側のソフトによっては、結構自由な値を設定できるようである。

いずれにせよ、、デフォルトのままだとServer名に自社名を出すというのは自信の表れかも知れないが、次期バージョンあたりではIBMさんもMicroSoftさんもOracleさんも(
+東芝さんも)控えた方がいいんじゃないだろうか。


SSL/TLSで使用している暗号を銀行のサイトで確認してみた

Webサイトを閲覧時の暗号通信には通常SSL/TLSが使用される。
(実際にはほぼTLSであり、SSLが使用される事はまずない)


どういった暗号を使用して通信を行うかはクライアントPCとサーバ側のSSL/TLSのHandShakeにより自動的に決定される為、何の暗号が使われているかを意識する事は少ない。実際にどういう暗号が使われているのかを確認する方法としては、FireFoxで見るのが簡単だ。

以下はみずほ銀行のネットバンクをFireFoxで表示させて、暗号モードを確認した例だ。




かなりはしょって表示されるが、AES-256 256bit(高強度の暗号化)と表示された。

その他のサイトはどうなってるのか?個人的に興味があったので日本の銀行系のサイトに対して確認を行った。結果は以下の通り。
(個人向けのインターネットバンキングと思われるサイトを確認してます)

【AES-256だったサイト】
東京三菱UFJ銀行、みずほ銀行、りそな銀行、ゆうちょ銀行、ソニー銀行、楽天銀行

【RC4-128だったサイト】
三井住友銀行、セブン銀行、住信SBI銀行、シティバンク、ジャパンネット銀行、新生銀行



AES-256、もしくはRC4-128に二分される。尚、クライアントPCはWin VISTAである。どちらの暗号がいいのか?それはもちろんAES-256である。


じゃあ、RC4-128だとダメなのか?と言われるとそういうわけでも無く、暗号強度は十分であり、少なくとも盗聴されたとしても解読される事は無いだろう。


しかし、、、近年のサーバ側の機器やソフトウェアはほぼ間違い無くAES-256に対応している事を考えると、上記でRC4-128となっているサイトは
①サーバ側の機器/ソフトが古い
or
②サーバ側の機器/ソフトは最新だが、暗号云々に詳しい人がいない、もしくはさして関心が無い
のいずれかじゃないかなと思う。


私も上記でRC4-128の銀行を使用しており、、、
早くAES-256にして欲しいなと思う今日この頃。。