【プロになるためのWeb技術入門】を読み進める。
はじめに
・Webアプリケーションシステムは複雑化しているため、習得に膨大な時間がかかる。
・一方で、日本のIT技術者は即戦力を求められるため、フレームワークの使い方をメインに学習させられる。
⇒Webアプリケーションシステムは複雑化しているが、日本のIT技術者はうわべだけの学習にとどまっているため、根本の仕組みを理解していない。
⇒世界規模のWebアプリケーションが日本から生まれない原因となっている。
⇒筆者は上記課題を解決するため、本書で第一線のエンジニアとして活躍するための基礎技術を教える。
目次
LESSON0：プロローグ
LESSON1：Webアプリケーションとは何か
LESSON2：Webはどのように発展したか
LESSON3：HTTPを知る
LESSON4：CGIからWebアプリケーションへ
LESSON5：Webアプリケーションの構成要素
LESSON6：Webアプリケーションを効率よく開発するための仕組み
LESSON7：セキュリティを確保するための仕組み
LESSON0
・インターネット上で利用できる「ネット上の銀行取引」「ブログ」「twitter」等は、
インターネット×コンピュータの組み合わせで実現されている。
そのコンピュータ上で動作しているプログラムが「Webアプリケーション」である。
・Webアプリケーションが動作する根本の仕組みを理解できていないと、プログラミングが楽しくならない。
・Webアプリケーションを根本から理解するには「HTML」「ネットワーク」「アプリケーションサーバ」「OS」の知識まで、幅広く必要。
・LESSON1～5は初学者向けLESSON6～7はある程度開発経験のある人向け。
・最も効率よく「技術」を学ぶ方法
⇒技術の歴史や背景を抑える。（何かの問題意識から技術が生まれるため）
LESSON1
アプリケーションは、「デスクトップアプリケーション」「Webアプリケーション」に大別。
■デスクトップアプリケーション（excelやword等）
・主な処理は、手元のPCで行われている
・画面は、OSの機能を利用して表示
・アプリケーションをPCにインストールする必要がある
■Webアプリケーション（ekinetやamazon等）
・主な処理はサーバー上で行われる
・画面はHTMLで表現され、Webブラウザ上で表示される
・アプリケーションをPCにインストール不要
・通常のWebサイトは受動的に利用⇔Webアプリケーションは能動的に利用
⇒最短経路を調べたい、あの商品を買いたい…
LESSON2
■www,webブラウザの歴史
①WWWの誕生
・インターネット：世界中のコンピュータを相互に接続し、通信できるようにしたネットワーク網
・1969年インターネット誕生～20年程は、ごく一部の限られた人のみが利用していた。
⇒コンピュータとネットワーク資源が高価、利用用途がメールやファイル共有など地味で普段縁のない人々は興味がなかったため。
・インターネットの起源は、CERNでの実験成果を全世界の研究者に共有したくて作られた。
（電子メールやファイル転送だと大変だったから。）
⇒ここで、図表や参考文献をテキストファイルのみで表現できるようにしたのが、HTML
⇒ここで文書間の参照を簡単にするために「Hyper Link」の仕組みが考えられた。
⇒「Hyper Link」でネットワーク経由でクモの巣上に参照し合うさまを見て、World-Wide Web（世界に広がる蜘蛛の巣）と名付けられた。
②Webブラウザの進化
・www誕生段階では、画像を表現できるブラウザがなかった。そのため、テキストはブラウザ上で見ながら、別ウィンドウで画像を表示するのが一般的だった。
・1993年にWebブラウザの「Mosaic」が誕生し、無料でだれでも利用できるように公開された。
・「Mosaic」により、Webブラウザ上で文字と画像両方の表示が可能となった。
⇒より多くの人に使われるようになった。「IE」や「Firefox」に発展していった。
・1990年代後半～2000年代前半にかけて、PCの高性能化＋低価格化、通信環境の普及（光ファイバー等）により、現在のようにみんなが利用するようになった。
■WWWの黎明期から変わらない技術
・wwwによるハイパーテキストの公開は、「webサーバ」と「webクライアント」というソフトウェアで実現されている。
⇒クライアント（お客様）、サーバ（仕える人）の認識で良い。
クライアントの要求に従い、サーバがHTMLファイルをクライアントに渡す仕組み。
⇒要求＝リクエスト、応答＝レスポンス
Webサーバ：Apache HTTP Server,Internet Information Servicesなど
Webクライアント：IE,Firefox,Safariなどのwebブラウザ
・クライアントとサーバに分ける理由
不特定多数の人に公開するには、コンテンツを1箇所に集中させるほうが管理（更新）が楽。
Webサーバを利用者が直接操作するのは非現実的であるため、利用者の手元にあるPCをWebクライアントとして利用できるように（webブラウザ）して、遠隔地にあるWebサーバとWebクライアントの間をインターネットで接続して、WWWを実現した。
■URL
・クライアントがサーバにリクエストする際に、どのHTMLを渡せばよいかサーバ側がわからない。
⇒URLで判断する。
http://www.xxx.jp/webtext/index.html
スキーム//ホスト名/パス名
・ホスト名＝ホストコンピュータ・・接続されている他のコンピュータからの要求を受け取り処理した結果を返すコンピュータ
・ホスト名：ローカル名（www） ＋ 親ドメイン名（xxx.jp）
※スキームはhttpのほかにも「https」「mailto」「ftp」「file」などがある。
※親ドメインは指定団体が管理している。（重複しないように）
・パス名：ホスト名で指定されたコンピュータ上のリソースの位置
・URLは、「ドメイン⇒コンピュータ⇒ディレクトリ⇒ファイル名」の形で階層的に位置を指定している。
■HTTP
・HTTPとは通信プロトコルの１つ
・通信プロトコルとは、データ通信の決まり事
・たとえばモールス信号や狼煙での情報やり取りの際に、事前に決めごとをしておかなければ、情報の伝達は不可。その決めごとが通信プロトコル（HTTPなど）
・FTP（ファイル転送専用のプロトコル）やSMTP（メール転送のためのプロトコル）をもとに、HTML転送に適したプロトコルをwww考案当時に発案した。
・いまでもアップデートを重ねて使われ続けている。
■CGI
・CGIの登場により、HTMLのみの静的なページの時代から、動的なページの時代へ移った。
⇒背景：静的なページだけだと作業者の更新作業が大変。ユーザー側も飽きやすい。もっと閲覧数を伸ばしたい。
・CGIとは、Webサーバとプログラムの連携をする仕組み。
⇒「Webサーバがクライアントから受け取ったリクエスト」を「Webサーバ上のプログラム」に渡す。
⇒「Webサーバ上のプログラム」が生成したHTMLをWebサーバへ返し、クライアントへ応答する。
・CGIにより、動的なコンテンツの作成が可能となったり、爆発的に増えていった。（ショッピングサイトや検索サイト等、ユーザーが入力した内容に対する動的コンテンツも可能となった。）
■CGIの問題点
・開発言語の性能の問題：Perlは、手軽にテキスト処理できるが、大規模なアプリケーション開発には不向き。
・性能の問題：WebブラウザからのリクエストのたびにCGIを通してプロセスを起動していたため、数万件数十万件の処理が必要になると、処理に時間がかかり、ページが表示されないという不具合が出るようになった。
■Javaの登場
・CGIの問題点を解決する開発言語Javaの登場
・オブジェクト指向の言語のため、大規模開発に向いている。マルチスレッドで処理が早い。
・マルチスレッド、セキュリティ、ネットワーク通信等、当時重要性が高まっていた技術が標準でサポートされていた。※ただしWebアプリ開発のための言語ではなかった。
・Webアプリケーション開発をサポートするため、Javaの「サーブレット」という機能が提供されるようになった。
・C言語のようにソースコードを直接コンピュータの機械語にコンパイルのではなく、仮想コンピュータの言語にコンパイルして実行するため、windowsでもmacでも動作させることが可能。
■Java サーブレットの問題点
・Javaのコード内にHTMLのコードを埋め込む、というコードの記載方法だったため、
どの部分がHTMLとして出力されるのかコードを見る際にわかりずらかった。
※デザイナーに不親切な見た目。
⇒JSP（Java Server Pages）の誕生により、解決。
⇒JSPでは、逆にHTMLのコード内にJavaのコードを埋め込む記載方法にした。
⇒HTMLで出力される部分がコードで見てわかりやすくなった。（動的に出力したい部分を<% %>で囲んで表現。スクリプトレットと呼ぶ。
■サーブレットやJSPの問題点
・大規模なWebアプリケーション構築（ECサイトや銀行振込サービスetc）の際に、携わる人数が非常に多くなり、各自が勝手にライブラリやクラスを作ってしまい、後々の結合でうまくいかないことが多発。ソフトウェア開発は建築に似ている。犬小屋は一人で作れるが、高層ビルは多くの人のチームワークとしっかりした地盤、優れた重機が必要。
※サーブレットやJSPでは不足。
■Webアプリケーションフレームワークの誕生
・大規模開発を効率よく行うには、「再利用」が大切だと考え、再利用可能な部品をまとめたものが「フレームワーク」。よく利用される処理は「ライブラリ」というプログラム部品として整備されている。
⇒短期間で大規模開発を可能とするため。
LESSON3
■HTTPリクエストの内容
①リクエストライン（HTTPリクエストの1行目）
GET http://www.xxx/xxx/xxx.html HTTP/1.1
メソッド URI HTTPバージョン
・メソッド：リクエストの種類（GET=URIで指定した情報を送ってください）
・URI：URLとほぼ同義
・HTTPバージョン：バージョンによって利用できるメソッド等かわるため、バージョンの記載
②2行目以降
・Accept：受け取れるデータの種類を明示。（text/plain、image/gif など）
画像データを受け取れないクライアントもあるため、その場合無駄に送らないようにするため。
・Accept-Language：Webクライアントが受け取れる自然言語の種類（ja-JPなど）
・User-Agent：利用しているWebブラウザの種類やバージョンを示す。各クライアントに対して適するコンテンツを返せるように。
・Host：リクエストの送信先のホスト名やポート番号
■HTTPレスポンスの内容
①1行目
HTTP/1.1 200 OK
HTTPバージョン ステータス・コード レスポンス・フレーズ
・ステータス・コード：1桁目でおおよそ内容がわかる。
1xx：Informational＝リクエストの処理が継続している。
2xx：Success＝リクエストが成功
3xx：Redirection＝リクエストを完了させるには、さらに動作が必要。
4xx：ClientError＝クライアント側のエラーにより失敗
5xx：ServerError＝サーバ側のエラーにより失敗
（例）
200:OK（成功）
302:Found（リクエストされたリソースが一時的に別のURIに属している。）
401:Unauthorized（ユーザ認証失敗）
403:Forbidden（アクセス権限がないため、サーバにリクエストの実行を拒否された。）
404:Not Found（リクエストURIに一致するリソースがなかった。）
500:Internal Server Error（CGIプログラムなど、サーバ内部のプログラム実行でのエラー）
②メッセージ・ヘッダ
レスポンスに関する付加的な情報が入っている。
②メッセージ・ボディ
HTMLファイルの内容が入っている。
■IPアドレス（住所みたいなもの）
・HTTPリクエストでの、Webサーバのホスト名も、あくまで人間にわかりやすいように表現されているに過ぎない。インターネットに接続されたすべてのコンピュータは「IPアドレス」によって識別されている。人間にとっては数字だけだと思えずらいから、URL(文字列）がある。
例：192.168.0.1
（256×256×256×256=約43億通り存在する）
・特定の団体が管理している。
・私たちはプロバイダが一定数のIPアドレスを保持して振り分けている。
・IPアドレスを指定したら、TCP/IPによって情報が送信される。
⇒小さな情報の単位に分割（パケット）して、送信。
⇒小回りが利いて、どんな通信環境でも送れるように。小さく分けておけば仮に一度送信に障害がおきても、その小さい1つをもう一度送りなおせばよいから。
・インターネット上で唯一のIPアドレス＝グローバルIPアドレス
・インターネット等のほかのネットワークに接続していないネットワーク＝プライベート・ネットワーク
⇒プライベートIPアドレスの振り分けが可能。
プライベートIPアドレスは下記範囲内であれば自由に振り分けてよい。
（プライベートIPアドレス）
10.0.0.0 ~ 10.255.255.255 Aクラス
172.16.0.0 ~ 172.31.255.255 Bクラス
192.168.0.0 ~ 192.168.255.255 C浦須
・IPアドレスだけではなく、ポート番号も指定しなければならない。
⇒ポート番号とは、アプリケーションが応答を待っている場所の番号。65536個のポートのいずれかの場所で、アプリケーションが応答を待っている。
⇒本来、IPアドレス＋ポート番号の指定が必要だが、あらかじめ通信の種類により標準的に使用するポート番号が決められているため、毎回指定する必要がない。
（ポート番号）
20,21:FTP
22:SSH(暗号化されたリモートコンピュータとの汎用通信）
23:Telnet（リモートコンピュータとの汎用通信）
25:SMTP（メール送信）
53:DNS（ホスト名解決）
80:HTTP（Webブラウジング）
POP3:（メール受信）
HTTPS（暗号化されたHTTP）
■DNS（Domain Name System）
・ドメイン名からIPアドレスへの変換を行っている。
・DNSサーバはドメイン名とIPアドレスの対応表を持っている。
・DNSサーバ内のデータ量はとても多く、そのサーバ一つに処理が集中すると危険なため、
ドメイン名に対応したサーバを多数用意して、分散管理している。
.jpや.comなどを「トップレベルドメイン」と呼び、これらを管理するDNSサーバを「ルートサーバ」と呼ぶ。世界に13個ある。
■Webサーバへの要求の伝え方
①GETメソッド
・Webブラウザは、form要素のaction属性で指定されたURLへアクセスする。
・この時、データの受け渡し方を指定するのがmethod属性。
・name属性により、変数に文字列を代入してサーバーへ送信する。
・GETリクエストでは、フォームから渡す情報がURLに記載される。
⇒例：/webtext/do_calc_get.php?arg1=123&arg2=456
?arg1=123&arg2=456の部分をクエリ文字列という。
⇒アプリケーション側でのデータ取り出し例：$arg1 = $_GET{'arg1'];
・URLの中にフォームの入力内容が表示されるため、セキュリティ面が大きな問題。また、文字数を多くできない。
②POSTメソッド
・URLではなく、「メッセージ・ボディ」にフォームの入力内容が記載され、送信するため、
セキュリティ面で安心。文字数が多くても大丈夫。
結果、POSTメソッド使えばよいのでは？
⇒google検索する際に、入力した検索文字列がURLあったほうが、他人に共有するとき便利だったりする。格納場所がメッセージボディだと、ブックマーク機能が使えない。
⇒場合によってGETメソッドのほうが利便性が高い。
⇒日本語はURLに入れると文字化けするので、「パーセントエンコード（16進数の英数文字列）」されてURLに記載される。
GET⇔POST 比較
パラメータ格納場所：URL⇔メッセージボディ
セキュリティ：低い⇔比較的高い
パラメータの長さ：255文字以内制限の可能性あり⇔制限なし
パラメータの保存・再現：しやすい⇔しにくい
副作用：期待される⇔期待されない
LESSON4
■CGIからWebアプリケーションへ
・Cookieとセッションにより、利用者とのやり取りを一連のものとして制御可能。
・Webアプリケーションを作る際には、事前に画面遷移図などを作成して、イメージを決めておく。
⇒お客さんからの仕事の場合、認識齟齬をなるべく減らすため、モックを作成すると良い。
※モックとは、HTMLのみで画面の張りぼて。イメージや画面遷移の関係を確認するための大枠。
・ログイン機能実装の際には、POSTリクエストでサーバに情報を渡す。
⇒機密性が高いため。
【ログイン認証でのHTTP通信内容】
①login.html（POSTメソッドでフォーム内容送信）※クライアント
②do_login.php（フォーム内容の受信＋認証成否により画面遷移変更）※サーバ
③認証成：302 foundで応答（login.htmlとは別の場所にありますよ）
④item_list.php（GETメソッドでリダイレクト）
・HTTP⇔FTP
ステートレスなプロトコル⇔ステートフルなプロトコル
※FTPはやり取りを記憶するが、HTTPはやり取りを記憶しない。
そのためHTTPではログイン保持機能の実装が課題だった。
・ログイン保持機能を実現するcookie
⇒クライアントから送られてきたメールアドレスとパスワードを、サーバー側でcookieにセットする。
⇒一度セットされると、リクエスト内にcookieの情報が追加されるため、ログイン保持が可能。
⇒HTTP通信の内容を参照されると、簡単に情報漏洩する。
⇒そこでセッションが登場。
⇒ログインの度に、サーバ側でセッションIDを発行し、cookieとしてクライアントへレスポンスする。
⇒セッションIDは、ログイン情報など各情報と紐づいている。
⇒セッションIDは、簡単な数字ではなく、多くの桁数で管理されている。
⇒一度ログアウトすると、そのセッションIDは失効し、使えなくなる。2度と使えなくなるので、そのIDが不正に利用されることはない。
LESSON5
■Webアプリケーションの構成要素
・Webアプリケーションのサーバー側は、規模が多ければ多いほど、複数のコンピュータで動作連携していて、複雑になっていく。
・サーバ側は、「Webサーバ」「アプリケーションサーバ」「データベースサーバ」の三層構造となっている。
・データベース操作の基本：CRUD操作（Create,Read,Update,Delete）
【サーバの相互関係】
Webサーバ：全てのクライアントからのリクエストを受け取る
↑
（通信プロトコルは決まっておらず、組み合わせによりWebサーバ側のモジュールを使い分ける。）
↓
アプリケーションサーバ：Webサーバが受け取ったリクエストのうち、動的コンテンツを担当する
↑
（DB製品特有の通信プロトコルでやり取りされる。※SQLにより）
↓
データベースサーバ：テーブル管理を行う
【Webシステム構成】
一般的：Webブラウザ⇔Webサーバ⇔APサーバ⇔DBサーバ 全て1台ずつ。
最小：Webブラウザ⇔Webサーバ/APサーバ/DBサーバ の計2台。
※規模により決める。