前提
- 教材書籍を読んで学んだことの整理として、内容をかいつまんだメモです。
- 7/9から
毎日少しずつ更新中。→週2程度に変更 - 基本的に自分で理解したこととしてまとめているため、書籍に記載されている通りの表現ではない場合が多々あります。投稿者の心の声や感想が漏れている箇所もあります。
- 章ごとの該当ページを下部の参考にまとめています
- 間違いなどあればご指摘いただけると嬉しいです🙇♀️🙇♀️
これを始めたきっかけ
投稿時の投稿者の情報
エンジニア未経験でWeb制作からキャリアをスタートし、1年半ほどでWeb開発のエンジニアに転職。
Web開発の仕事をする中でこの業界のことを何にも知らないことを痛感。
「Webとは」「Webアプリケーションってどんなものか」「背景の大まかな仕組み」
といった基本的なイメージ（概念？）も弱々な状態で、他にも知らないことだらけではあるが、まずはこれらを大まかに理解しようと下記の書籍を読もうと思った。
教材にした書籍
『プロになるためのWeb技術入門 -なぜ、あなたはWebシステムを開発できないのか-』
小森裕介 著 / 技術評論社
https://gihyo.jp/book/2010/978-4-7741-4235-7
※以下、本記事内では「参考書籍」と呼びます。
内容
参考書籍の目次（前書きや後書きなどは除く）
- 「Webアプリケーション」とは何か
- Webはどのように発展したか
- HTTPを知る
- CGIからWebアプリケーションへ
- Webアプリケーションの構成要素
- Webアプリケーションを効率よく開発するための仕組み
- セキュリティを確保するための仕組み
1. 「Webアプリケーション」とは何か
本題に入る前に、
「アプリケーション」とは何か？とうまく説明できる自信がなかったのでさくっと定義を調べる。
簡単な言葉でまとめるとこうなりそう。
アプリケーション（アプリ）とは、
ユーザーがいろんな作業を実行できるようにするプログラムのこと。
シンプルで安心した。
LINEとかExcelとかGmailとか、普段何気なく使っているものは全部アプリだ。
ただ種類がいくつかあって、そのうちの一つが「Webアプリケーション」だ。
ほかの種類のアプリとの違いなど見ていくよ。
アプリの種類
教材の中では、「処理の主体」「画面の表示」「インストール（の必要性）」という観点でWebアプリケーションとデスクトップアプリケーションの違いを比較していた。
| 処理の主体 | 画面の表示 | インストール | |
|---|---|---|---|
| Webアプリ | サーバー | Webブラウザ上 | 不要 |
| デスクトップアプリ | 手元のPC | OS上 | 必要 |
（疑問）
上記の観点で考えると、ゲームの場合はこんな感じで分けられるのだろうか。
（ゲームは詳しくないのでかなり自分の独断と偏見）
- ブラウザ上で動くもの、インストール不要 → Webアプリ
- 端末にインストールして動くもの → デスクトップ（モバイル）アプリ
- PS4など専用のハード上で動くもの → ゲームアプリ？？（該当する名称が単純にわからない）
2. Webはどのように発展したか
Webが生まれた背景と歴史について。
新しいものが生まれては取って代わり、の時代。
技術を理解する上で歴史を知ることは良いステップだと思った。
今後出てくる技術たちも現状の課題がもとになって生まれてくるのだろうなと。
2.1. WWWの誕生と普及
WWWとWebブラウザの原型「NCSA Mosaic」の登場により、インターネットが普及。
おかげで一般の人が様々な情報をインターネット上に公開できるようになったよ。
WWWの誕生
- 1969年、インターネットの原型が生まれる
- アメリカの国防総省が研究・調査目的のために構築したネットワーク（ARPANET）が原型になった
- 最初の20年ほどは大学や研究機関の関係者などごく一部の人だけが使うものだった
- 用途は電子メールやファイル共有など（一般の人は使わないよね）
- 当時はコンピュータやネットワーク資源が高価だった
- ということもありコンピュータに縁がない人たちからの興味はほぼゼロ
- 1989年に大きなきっかけが！
-
WWW（World-Wide Web） が世界で初めて提案された
- 欧州原子核機構（CERN）で研究成果を全世界の研究者間で共有したい！という話に
- しかし当時の主要な情報共有手段の電子メールやファイル転送では使い勝手悪いよね〜と試行錯誤が重ねられていた
- 天才現る。CERNのティム・バーナーズ=リー博士が、研究成果を統一された形式「HTML（Hyper Text Markup Language）」で表現することを考える
- HTMLの画期的なところ
- 文書間の参照を「Hyper Link（ハイパーリンク）」の形式で記述することで、参照先の文章を瞬時に閲覧できる
- それまでは手作業で参照しないといけなかった（超つらいじゃん）
- 参考文献や論文などの資料をネットワーク経由で簡単に閲覧できるようになった
- ネットワーク上でリンクされたハイパーリンクのつながりが蜘蛛の巣(= web)のように見えることから、「World-Wide Web」と名付けられた
-
WWW（World-Wide Web） が世界で初めて提案された
ほへ〜そうだったのね。
当時の研究者界隈はさぞ白熱したことでしょう。
Webブラウザの祖先NCSA Mosaicの開発により一般人にも普及
- WWWは登場後もしばらくは研究者の間でひっそりと使われていた
- ていうのも現代ようなのグラフィカルなWebページとはほど遠く、文字のみの表現の世界
- 画像は別ウィンドウで表示されていた
- 1993年にまたもや革命が！
- イリノイ工科大学の米国立スーパーコンピュータ応用研究所(National Center for Supercomputing Applications, NCSA)のマーク・アンドリーセンらが、NCSA MosaicというWebブラウザを開発
- Mosaicでは文字と画像を混在させて表示できるようになった
- しかも誰でも無料で利用できるものだったため、WWWの利用が大きく広がった
- それまでより豊かな表現が可能になったことで、一般の人々も興味を持つように
- 1990年代後半〜2000年代前半で現在のようなインターネットが一気に普及
- パーソナルコンピュータの高性能化・低価格化
- （日本国内では）ADSLや光ファイバーの普及で高速ネットワークが安価に利用できるように
- Mosaicをベースに現在のChromeやFirefoxなどのWebブラウザが開発されていった
2.2 Webを支える技術の発明
WWWの黎明期に発明され、今でもWebの基礎になっている技術たち
- WebサーバとWebクライアント
- これが分かれていないと利用者がサーバを直接操作しないといけない
- URL（Uniform Resource Locator）
- インターネット上のコンテンツを一意に指定するための仕組み
- スキーム/ホスト/パス
- HTTP（Hyper Text Transfer Protocol）
- WebサーバとWebクライアントが通信をするための共通のプロトコルが必要になり、HTML考案者のバーナーズ=リー博士が、当時すでにあったFTPやSMTPを参考に考案した
バーナーズ=リー博士天才かよ。
こういうのを考えつく方々の思考回路を知りたい。
2.3 CGIの誕生
現在のWebアプリケーションが登場するきっかけになった、地味にすごい技術
- インターネットの普及に伴い、企業や一般の人々がWebを利用するようになって新たな問題発生
- 「常に新たなコンテンツを提供したい」
- でもコンテンツを更新を人間がやるのってさすがに。。
- 当時のWebサーバは「予め用意された情報を公開する」機能のみ
- CGI（Common Gateway Interface）の誕生により、動的コンテンツが可能に！
- 「コンピュータがコンテンツにちょっとした変化をしてくれたらな〜」
- そのためにはWebサーバとコンテンツ生成プログラムの連携が必要、という感じで生まれた
- クライアントからリクエスト受け取り、プログラムへ渡す（Webサーバ）→リクエストからHTMLを生成し、Webサーバに返す（プログラム）→HTMLをクライアントに返す（Webサーバ）
- ここで利用されたプログラムがPerlや、大規模であればC言語
- CGIの登場により
- ブラウザから入力を受け取って処理するアプリの作成が可能に
- 検索サイト、掲示板システム、ECサイトなどが実現できるように
静的コンテンツから動的コンテンツへのきっかけはCGIだったのか！
言語かと思ってたけど規約なんだね。
2.4 サーブレットの登場
例によってまた新たな問題が浮上し、新たな技術が生まれる
- 当時の問題点
- Webアプリケーションに求められる機能が大規模かつ複雑になり、開発主言語Perlでは限界
- アクセスが多いサイトでは処理が追いつかなくなった
- ブラウザからリクエストが届くたびにCGIを通してプロセス起動していた
- Java登場！
- サン・マイクロシステムズのJames Goslingが開発
- オブジェクト指向の機能のサポート→大規模システムの開発がしやすい
- 当時広く使われていたC言語に文法が似ていた
- サーブレットの提供
- CGI経由で起動されるPerlやC言語のJava版
- 要はHTMLなどのコンテンツを作成するプログラム
- CGIの上位互換的な存在
- Webサーバと同じプロセスの中で動く（毎回新たなプロセス起動しなくてよい）
- ゆえに速くなった
Javaすげぇじゃん！となり、Java/サーブレットはどんどん普及。
しかし時代は（？）繰り返す。
例によってまた新たな問題が浮上し、新参者に取って代わられる。
とにかくJavaの功績は、大規模なWebアプリケーションを開発しやすくしたことっぽい。
JavaVMによりプラットフォーム（Windows, Mac, Linuxなど）の依存性がなかったりとか（C言語とかは依存性あった）。
Webコンテナの登場とか。
（疑問）
このWebコンテナってdockerとかに繋がってくるのだろうか？？
あれも仮想的な技術だし。
2.5 JSP（Java Server Pages）の誕生
例によって新参者登場です。
動的なコンテンツの提供も広がってきた時の問題を改善するために、今度はJSP（Java Server Pages）という技術が考え出された。
JSPでは、動的に出力したい部分を<% %>で囲んだ中にJavaプログラムを記述することができる。
例えば1,000円の消費税込み価格を表示させる簡単なプログラムで比較してみよう。
※消費税10%の世界線とする
▼サーブレットの場合： Javaコードの中にHTMLを埋め込む
out.printIn("<p>1000円の税込み価格 =" + (1000 * 1.1) + "円</p>")
この例は単純だが、複雑なデザインを実現しようとすると可読性が低下する。
▼JSPの場合: HTMLの中にJavaコードを埋め込む
<p>1000円の税込み価格 = <% out.printIn(1000 * 1.1); %> 円</p>
JSPの方が出力されるHTMLに近い形で書ける。
プログラム担当者はJavaコード、デザイン担当者はHTML、という形で分担できるように。
と色々な技術の登場のおかげで、簡単なWebアプリケーションを作るのは楽になっていった。
2.6 Webアプリケーションフレームワークの時代
とはいえ、Webアプリケーションはどんどん大規模なものに。
サーブレットやJSPだけではまだまだ大変だった。
大規模なWebアプリケーションを効率よく開発するために、「再利用」という考え方が出てくる。
これによりライブラリの整備、フレームワークの開発が進められた。
最近のWeb開発っぽくなってきましたね！！
3. HTTPを知る
WebアプリケーションはインターフェースにHTMLを使用していることが大きな特徴。
HTMLの送受信に使われているHTTPについて、この章の理解をまとめてみる。
WebアプリケーションにおけるHTTPの重要性
HTTPはWebサーバとWebクライアントの通信の根幹。
デスクトップアプリケーションと異なる点の一つ。
WebブラウザとWebサーバの通信
覗いてみる
- メソッド
- URI
- Request Headers: リクエストの付加情報
- Accept: データの種類
text/plainimage/pngなど - Accept-Language: クライアントが受け取る自然言語（人間用）の種類
- User-Agent: 利用しているブラウザの種類やバージョン
- Host: リクエストの送信先ホスト名やポート番号
- Accept: データの種類
代表的なステータスコード
| ステータスコード | 意味 | 説明 |
|---|---|---|
| 200 | OK | リクエストが正常に完了したことを表す |
| 302 | Found | リクエストされたリソースが一時的に別のURIに属していることを表す。リダイレクトで利用される |
| 401 | Unauthorized | ユーザ認証に失敗したことを表す |
| 403 | Forbidden | アクセス権限がないため、サーバにリクエストの実行を拒否されたことを表す |
| 404 | Not Found | リクエストURIに一致するリソースを見つけられなかったことを表す。入力したURLが誤っていた時もこれ |
| 500 | Internal Server Error | サーバ内部のプログラム（CGIなど）実行においてエラーが発生したことを表す |
HTTP通信の登場人物
- IPアドレス
-
192.168.0.1などの4組の数字で表される - インターネットに接続されたすべてのコンピュータはIPアドレスによって識別される
- IPv4, IPv6
-
- DNS(Domain Name System)
- ホスト名をIPアドレスに変換し、宛先のコンピュータを探す
- TCP/IP(Transmission Control Protocol/Internet Protocol)
- IPアドレスをもとに情報を届ける
- 情報をパケットに分割して送受信
- 1970年代にアメリカ国防高等研究局の研究が発端
- ポート番号
- 受信する情報について、プロトコル/処理するアプリケーションにより待ち受けポートが異なる
- よく使われるプロトコルでは標準で使用するポートが取り決められている
- HTTPプロトコルの場合80番ポート
GETリクエストとPOSTリクエスト
ざっくりな比較
| GET | POST | |
|---|---|---|
| パラメータ格納場所 | URL | メッセージ・ボディ |
| セキュリティ観点 | 低い | 比較的高い |
| パラメータの長さ制限 | URLが255文字以内* | なし |
| パラメータの保存・再現 | しやすい | しにくい |
| 副作用が発生しないこと | 期待される | 期待されない |
ざっくりユースケース
- Googleなどの検索欄: GET
- 検索結果の保存（ブックマーク）や共有ができる
- ログイン処理や決済処理: POST
- 機密情報
- クエリ文字列に収まりきらない大量の情報を送信
4. CGIからWebアプリケーションへ
いよいよWebアプリケーションの基本的な仕組みを見るよ。
状態を保持するためのCookieやセッションについて自分の理解をまとめてみる。
Stateful(ステートフル)とStateless(ステートレス)
買い物をするWebアプリなどではログインをすることが一般的。
例）ログインページ→マイページ
ページ間でこのログイン状態をどう記憶するか？
HTTPプロトコル誕生の背景を見てみる。
当時既存のFTPプロトコルは認証処理や転送方法の指定、データ転送のコネクションの確立など通信手順が多く、オーバーヘッドが大きかった。アカウントも必要。
通信手順が簡単なプロトコルとして設計されたのでした。
-
FTP
- まず認証！他にもいろいろ
→オーバーヘッドが大きい - 認証したリクエスト結果を踏まえて次のリクエストを実行
→リクエストに状態をもつ（=ステートフル）
- まず認証！他にもいろいろ
-
HTTP
- 認証不要
→オーバーヘッド少ない - 1度のリクエストで済む
→状態が存在しない（=ステートレス)
- 認証不要
状態はどうやって持たせる？GETでパラメータ持たせるのはなんか違う..
そこでCookie登場！
Cookie
HTTPの仕様を拡張してWebブラウザに状態を持たせることができるようにした技術。
言葉の意味としてはWebサーバからWebクライアントへ送られる短いメッセージのこと。
Cookieの問題点
リクエストヘッダなどから普通に覗けてしまう
ユーザ名やパスワードをCookieで保存することはセキュリティ的にNG
セッション
そこで登場するのがセッションで、HTTPリクエストの処理の流れのことを指す。
WebサーバとWebクライアントの間では、情報が管理されているID（セッションID）をやり取りする。
これならCookieに格納しても比較的安全（絶対安全というわけではないらしい）で、たくさんの情報量をやり取りできる。
Webアプリでの例
- ログイン→セッションIDがCookieに格納される
- ログイン後の他の画面→同じセッションIDを持っている
- ログアウト→セッション情報が破棄される（セッションIDは無効になる）
5.Webアプリケーションの構成要素
システムの構成を歴史のおさらいとともにざっと見ていくよ。
コンピュータのことを「ノード」
5.1 WebサーバとWebクライアントの時代
- WWW黎明期
- WebクライアントとWebサーバの単純な構成がほとんど
- CGI時代
- Webサーバ側のコンピュータ（ノード）では、WebサーバとWebアプリケーション（CGIで呼び出される）の2種類のソフトウェアが動作
- もともとはPerlインタプリタなどのプロセスを介していたが、Webサーバの中でプログラムを直接実行できるようになっていった
5.２ データベースサーバの登場
5.3 アプリケーションサーバの登場
To be continued
毎日ちょこちょこ更新中
参考
※1: 参考書籍P.7~12 「Webアプリケーション」とは何か
※2: 参考書籍P.12~42 Webはどのように発展したか
※3: 参考書籍P.43~84 HTTPを知る
※4: 参考書籍P.85~１２4 CGIからWebアプリケーションへ
※５: 参考書籍P.125~166 Webアプリケーションの構成要素