xxxさんの備忘録

xxさんのブログです.xxさんはネカマです.

「プロになるためのWeb技術入門」lesson4-5まで

lesson4


宅配ピザの注文サイトの作成流れ

 

(要求分析フェイズ)
→お客様が何を求めているかを整理する(また業務の流れなどの知識を持つ)

 

①画面構成を考える
→ラフスケッチで作成、5つの画面から作る(ユーザー登録などは省略)
画面遷移図の作成等

 

②画面モックの作成
→「モック」とは模造品を指し、HTMLの画面の張りぼてを作成し、
お客様とイメージ・画面遷移の関係などを確認にするために作成される

 

③ログイン認証機能を作成する

リダイレクト動作のHTTP通信の確認
レスポンス・ラインが「302 Found」で返ってくる。
つまり、最初に要求したURLと異なるURLに遷移することを「リダイレクト」と呼ぶ。

 

●コラム
PHPエンジンはWebサーバーのプログラムに対して「モジュール」という形で組み込まれている。

 

ログイン状態の記録
・HTTP通信ではログイン(状態)を記録できない。

cf)FTPによる通信の場合、
前回のリクエスト結果を踏まえて次のリクエストを実行する。
このようなやり取りを「ステートフル・プロトコル」と呼ぶ。

HTTPの場合、FTPのようなリクエストのやり取りが必要なく、
一回のやり取りのみで済んでしまう。
このようなやり取りを「ステートレス・プロトコル」と呼ぶ。

FTPの問題点
FTPは通信手順が多いためオーバーヘッド(本来の処理を行うために余計に処理がかかってしまうこと)が大きい。
・アクセスのために認証を必要とすること
このため、「認証が不要」、「オーバーヘッドが少なく」実装が簡単なFTPに代わるプロトコルとして
HTTPが開発された。

 

 

HTTPでの状態の表現方法
Cookie(クッキー)はHTTPの仕様を拡張してWebアプリケーションとWebブラウザの間で
情報の交換できるようにしたものである。

 

WebサーバからCookie(ex:user=xxx; pass=xxxx)を受け取ったWebブラウザは次に同じWebサーバにアクセスする際に
受け取ったCookieをそのままHTTPリクエストヘッダに入れて送る。
Webアプリケーション側ではリクエストヘッダに入っている
Cookieを調べることでアクセスしてきた相手がどのような相手か知ることができる。

 

 

4.6安全に状態を保存するための技術-セッション-

Cookieにまつわる問題点
Cokkieを利用した情報のやり取りは、HTTPのリクエスト・ヘッダやレスポンス・ヘッダを利用して行われる。
PC上に保存されたCookieをのぞくことも容易なため、セキュリティ面に危険性がある。
そこで考えられた方法がセッションである。

 

 

セッションIDに関して
セッションIDはWebサーバにリクエストを発行したWebクライアントに識別できるもの(一意なものを指定する)
HTTPにおけるセッションIDの受け渡し方法
Cookieの中に情報そのものを格納するかセッションIDだけ格納するのかが違いである。

 

 

Webサーバによる認証機能

・本書にも載っているような認証方式をフォーム認証(HTMLで画面を作成していることから)と呼ぶ。ほかの認証方式として「Basic認証」がある。
この認証方式の特徴はパスワードが平文で送信される/ログアウトのような処理ができないなどがある。
Basic認証は平文で送信されるため、SSLの暗号化通信、パスワードを直接やり取りしないDigest認証を使用するほうが安全である)


Lesson5

 

Webアプリケーションの構成要素
・Webサーバ
アプリケーションサーバ
・データベースサーバ
が存在する

 

 

●コラム
複数のコンピュータをつなげて1つシステムを構成しているものを「ノード(Node)」と呼ぶ。
「同一ノード上で動かす」ー複数のプロセスを同じコンピュータ上で動かすことを指す
「異なるノードで動かす」ー異なるコンピュータ上で動かすことを指す。

 

5.1 webサーバとwebクライアントの時代


・クライアントサイドではwebクライアントと呼ばれるノード上でwebブラウザというソフトウェアが動作している
・サーバサイドではwebサーバと呼ばれるノード上でwebサーバというソフトウェアが動作している。

 

CGIの時代
最終的にwebサーバの中でPerlPHPのプログラムを直接実行できるようになる


●コラム
ソフトウェア/プログラム/アプリケーション/サーバ
以下はすべてソフトウェアを指し示すものである。


a)プログラム
コンピューターが行う処理の手順を示したもの。
ソースコードそのものを示して「プログラム」と呼ぶこともある。

 

b)アプリケーション
pc上で動作して人に提供する物が主。

 

c)サーバ
サーバは特定の機能に特化したソフトウェアでそれ単体ではシステムを成さない。
今後紹介されるDBサーバがサーバと呼ばれるソフトウェアの代表例である。

cf.プロセスーこれらはコンピュータ上で動作しているソフトウェアを指す際に使われる。

 

 


5.2 データベースサーバの登場
●データベース管理システムの登場
・大量の情報を間違いなく記録し、また情報の検索や集計を人間の手で行うよりも早く処理するために作られた。
このようにコンピュータ上で扱う情報の集合を「データベース」と呼ぶ

そこで、データベースの実現と取り扱いに特化したソフトウェアが開発され、広く利用されるようになった。
それらが「データベース管理システム(DBMS)」である。

 

●コラム
DB,DBMS,RDBMSの三種類の呼び方をする。厳密な違いに関しては以下になる。

 

a)DB
コンピュータで扱う情報の集合のこと
DBMS」との混同が多い。

 

b)DBMS
データベース管理システム、データベースを構築し使うためのソフトウェア

 

c)RDBMS
リレーショナル・データベースを扱うDBMS

 

 


●データベースに対する操作

a)Create 生成
新しい情報をデータベースに登録することを指す。

 

b)Read 読み取り
データベースに登録されている情報を読み取ることを指す。
合致する条件を抽出するような検索処理も含まれる

 

c)Update 更新
データベースに登録されている情報を更新することを指す。
読み取りと同じく合致する条件を抽出し、更新日時の書き換えなどを行うこともある。

 

d)Delete 削除
データベースに登録されている情報を削除することを指す。

これら四種類を「CRUD操作」と呼ぶ。


●データベースによる情報操作の管理
DBは「テーブル(表)」とテーブルの列「カラム」、情報の入った「レコード」から構成されている。

 

●コラム「データベース設計はITシステムの要」
ーどのように「表」と「列」を分けるかを「データベース設計」といい、
データベースを利用するシステムでは初期の段階で必要となる作業である。

・重複した情報を排除することを「正規化」と呼ぶ。
・データベース設計を適切に行えるかが、システムの使いやすさや汎用性に大きく影響を及ぼすことがある。
以上は「データベース設計」の重要な部分ではあるが、今回は割愛する。

 

 

・データベースから情報を抽出する
→必要な情報をSQLでデータベースへ伝える。

a)「何を」
SELECT文で指定している箇所

b)「どこから」
SELECT文で指定した個所をどこから取り出すのかを指定している。

c)どのように
条件をどのように取り出すのかそれらの条件を指定する部分

 

 

・データベースとクライアントの関係
データベースクライアント→人間がSQLを書き発行するのに向いている。
Webアプリケーション→人間ではなくWebアプリケーションのプログラムがSQLを発行している。
ex)「商品一覧」の画面を表示する際にDBから商品の一覧を取得するほうがデグレ等の不安がない。


・データベースサーバの分離
小規模)データベースサーバ上でDBMSを起動させる

大規模)Webサーバを動作させるコンピュータとデータベースを起動させるコンピュータを別々に用意し、各プロセスをそれぞれのコンピュータ上で起動させる。(負荷が小さくなる/既存システムとの結合)

 

・Webアプリケーションとデータベースの通信
webアプリケーションとDBはデータベース固有の通信プロトコルを使用し通信している。

 

●代表的なDB
Oracle Database
ーシェアが大きい。歴史がある

・Micrsoft SQLserver
マイクロソフトが開発。winにしか基本的には使えない

PostgreSQL
オープンソースとして公開されているデータベース。

MySQL
ーPostgreと同じくオープンソースGPLと商用二つの形態がある。

 

 


・5.3アプリケーションサーバ(APサーバ)の登場
概要:Javaの利用が広まった。ServretやJSPといった技術を利用してWebアプリケーションを開発するようになった。
JSPやServretはどこで動いているのか

ex)Tomcatを使った例
Tomcatは、オープンソースアプリケーションサーバ

 

大まかな流れ
1)ApacheへHTTPリクエストが届く
2)mod_jk(連携モジュール)がTomcatへ転送する(ajp13というTomcat独自のプロトコルで通信している)
3)Webアプリケーションサーバに届く
アプリケーションサーバは逆ルートで返す(3)~(1)に向かうような)


・WebサーバとAPサーバの分担
HTTPリクエストを一度Webサーバが受け取り、URLのパスによってはAPサーバに投げる。
これらをApacheTomcatの連携では、設定ファイルを書き明示的に示す。
cf)
localhost127.0.0.1(自分自身を示す)

・WebサーバとAPサーバの連携メリット
WebサーバとAPサーバを異なるノードに配置するメリットとして、

軽い処理で回数の多い静的コンテンツへのリクエストはWebサーバへ
回数が少なく処理の重い動的コンテンツはAPサーバへと
異なる性格のリクエストを分けることができる。
(APサーバを複数立てることも可能。)

 

 

●APサーバが提供する機能

a)セッション機能
JavaのAPサーバではセッションIDの管理をAPサーバが行うこともできる。

 

b)トランザクション
業務上まとめて実行すべきである一連の処理を「トランザクション」と呼ぶ。
また、処理が失敗した際には巻き戻すための「ロールバック」という処理もある。

 

c)DB接続管理
データベースの接続/切断処理を個々の処理の中で行うのではなく、システム全体で一括して管理することが一般的になっている。
APサーバではデータベースの接続を管理する機能を提供し、開発者がDBの接続状態を気にしなくてもいいようにしている。
また、Webアプリケーションの必要に応じて接続を使いまわすことでDBアクセスを高速化する仕組み「コネクション・プーリング」といったものもある

 

d)Webアプリケーションの管理とシステムの可用性・性能向上
何かの原因でAPサーバがダウンした際のために、複数のAPサーバを用意させておきダウンしたサーバの肩代わりをさせることでシステムの可用性を高める方法がある。
そのために、「セッション・レプリケーション」というAPサーバ同士が連携してセッションの状態を共有する必要がある。
これらにかかわるような機能を提供しているAPサーバも存在する。

 

 

5.4 Webシステムの三層構造
・最小構成のWebシステム
サーバサイドは一台のコンピューターの中でAPサーバとDBサーバのみ機能させる。
Webサーバ部分は、APサーバが提供する機能を利用している。

 

ex)小規模なシステムやWeb開発環境、テスト環境として利用されることが多い

・一般的な構成

①それぞれのサーバを別々のノード上に配置する。
それぞれのコンピュータの持つリソースを各サーバの役割へ最大限振り分けることができる。
ex)利用者が多く、扱うデータ数も多いショッピングサイト

 

②また扱うデータが多い割に利用者がそれほど多くないシステムではDBサーバのみを異なるノードへ分離して
WebサーバとAPサーバを同じノードへ配置することもある。
利用者が多くないものの扱う企業全体にかかわるデータを扱う場合などがある。
そのため、DBに大きなリソースを必要とする場合が想定される。
ex)利用者が限られる企業内の業務システムなど

 

 

ソフトウェア上のサーバサイドでは「Webサーバ」、「APサーバ」、「DBサーバ」の3つの構成要素が必ず登場する。
このようにWebシステムを構成するソフトウェアを大きく3つに分けて連携させる構成を「三層構成」と呼ぶ。

 

 

●現代のWebシステムを支えるオープンソースOSS
プロプライエタリ・ソフトウェア」ー購入(ソフトウェアを利用する権利を購入している)・ソースは非公開
オープンソース」ー無償利用・人類の共通財産という思想に基づきソースコードの一般公開(※無保証)

 

 

オープンソースのライセンス
cf 「コピーレフト」(考え方)
ー「GPL」はコピーレフトの考え方を最も厳格に実現しているライセンスである。
GPLではソースコードの開示を義務づけ、コピーレフトに従って派生物にもソースコード開示が義務とされる。
(これを緩めたものに「準コピーレフト」型と呼ばれるライセンスであり「LGPL」「MPL」などがある)