備忘録的な意味合いの強い
web技術の基礎をまとめておくことにした。
そもそもwwwは
欧州原子核研究機構CERN
が、研究成果をメールに頼らず、
いつでも誰でもアクセスできるようにするために発明されたものである。
当時は簡単なHTML文章をただ返す、根本的な機能しか持っておらず、
そこで新たな問題が発生した。
せっかくHTMLを公開しても、
閲覧者が飽きてしまい、アクセスが減るという問題である。
また、コンテンツの更新に莫大な手間がかかり、キリが無いという問題も付随して発生した。
そこで開発されたのがCGIという技術で、
動的コンテンツをweb上で閲覧できるシステムだ。
現在のwebアプリケーションの土台になっている。
最初はC言語やPerlが用いられていたが、やがてそれらを踏襲してJavaが発明され、受け入れられるようになっていく。
ここで新たな問題が発生する。
webアプリケーションの大規模化、複雑化である。
Amazon.comを想像すると分かりやすいが、
従来のアプリケーションとは比較にならないほど複雑で、
かつ規模が大きく、便利なものを、従来のシステムで管理できないことだ。
我々初学者が勉強に一番の時間を割く、
webフレームワークの登場へと、話は展開される。
webフレームワーク登場初期、
一番の問題はログイン状態をいかに保持しておくか、
というものだった。
普段から何気なく使っている。
Cookieの誕生である。
webサーバからwebブラウザへHTTPレスポンスを利用して小さな情報を送る。
名前と値の組み合わせ、これがcookieである。
一方cookieを受け取ったものと異なるサーバーからは、
アクセスを拒否する。
これを利用してログイン状態が管理されている。
しかしセキュリティ上の問題を払拭することができなかった。
簡単な仕組みであるが故に、
第三者からユーザー名、パスワードを知られてしまうと、本人になりすまして買い物したり、
銀行口座をのぞかれてしまう。
これらを解決するために生み出されたのがsession
である。
銀行の窓口を想像すると分かりやすいが、
例えAさんが新規に口座を開設するとして、
その旨を担当員に伝えると、整理券番号Aでお待ち下さいと言われる。
その間にBさんの要件を受け付け、処理をすることができる。
そうこうしている内に新規口座の開設手続きは終わり、
Aさんはスムーズに通帳を受け取ることができる。
ログイン→処理→内容確認→ログアウト
この一連の流れをsession、ここで言う受け付け番号をsessionIDと呼ぶ。
受け付け番号で管理する点、cookieよりもセキュアであると言えるし、
cookieが持つやりとりの機能を再利用することができる。
例えばwordで何か文章を作成するケースを考える。
この場合PCが一台あれば完結するが、
webアプリケーションの場合同様にはいかない。
webサーバーとwebクライアント、少なくとも2台のコンピュータが必要である。
システムも以前より大規模化を迫られる。
大量のデータを保持するにあたって発明されたのが、
おなじみDatabaseである。
初学者にも有名な機能がCRUDである。
create,read,update,deleteを指す言葉であるが、
データベースサーバーを経由することで、
データを抽出しやすくなる。
ここからはアプリケーションサーバーの登場から、
アプリケーションを安全に運用するための仕組みである、
SSHの誕生へと、発展していく。