プロになるためのweb技術入門殴り書きメモ

プロになるためのweb技術入門をささっと読んだ時の殴り書きメモ。

殴り書きメモ

■Lesson3

受信した情報がどのようなプロトコルで、どのアプリケーションが処理すべきかTCP/IPだけでは判断できない。
そこでポートが出てくる。80番ポートならHTTPプロトコルでのリクエストだとわかる。

アプリケーション側は待ち受けポートとしてTCP/IPからの情報をまつ。

GETリクエストの利点としてURLベースの行動に特化している
・お気に入り登録ができる（
・サイトの紹介ができる
など

■Lesson4

Cookie
サーバからクライアントに送る状態維持の情報
サーバからcookieを受け取ったクライアントは次にまたそのサーバーに
リクエストする際はリクエストヘッダにcookieを持たせる。
だいたい、ログイン時のサーバーからのレスポンスヘッダに入っている

セッション
ステートレスなHTTP通信において、独立したリクエストの間で情報を保持するための仕組み。
同クライアントからの異なるリクエストを、１連の関連するリクエストとして認識して扱える仕組み。
ある処理の一連の流れ
ログイン→注文→注文確認→ログアウト、みたいな
セッションIDは銀行で言う整理券

通常セッション情報はメモリ管理なので、増えるとメモリを圧迫していく
なので一定期間を過ぎたらセッションを自動削除する（セッションタイムアウト）
APサーバーは大体セッションを利用した時間を記憶している。
セッションはHTTPの仕組みを利用してサーバー側が実現しているので、クライアント側からはどうこうできない。
ユーザにログアウトを強制できないので、タイムアウトがあるとはいえ、ある程度メモリを圧迫することは把握しておかないといけない

Cookie自体にユーザ状態を持たせるのではなく、整理券であるセッションIDを格納し、
サーバー側でそのセッションIDをもとにクライアントの状態を復元するなどして状態保持をすることがほとんど

セッションは一連の操作を実現する仕様（概念）であり、cookieはそれを実現するための一つの実装

ログインの一連の流れ
１、ユーザー名、パスワードで状態チェック（クライアントからサーバ）
２、セッションIDを発行、セッション情報にログイン中のユーザー情報を記録（サーバ処理）
３、cookieにセッションIDを格納してレスポンス（サーバーからクライアント）
４、セッションIDを格納したクッキーを渡す（クライアントからサーバ）
５、セッションIDからログイン中ユーザーを識別（ユーザー固有の状態を持ったレスポンスを返す）
６、マイページ表示など

■Lesson5

複数のコンピュータを組み合わせて１つのシステムを作る場合、各コンピュータをノードという

複数プロセスを同じコンピュータでうごかく＝同一ノード上で動かす
複数プロセスを異なるコンピュータ（サーバ）で動かす＝異なるノード上で動かす

webサーバーとAPサーバーは異なるプロセスで動いている
連携方法は色々あるが、一般的にはAPサーバー側が連携用モジュールを用意しており、それをwebサーバーに組み込むことで連携をしている。

Apache（webサーバー）とTomcat(APサーバー)の場合、mod_jkと呼ばれるモジュールがあり、それをApacheの拡張機能として組み込み連携している

流れとしては
apacheに届いたHTTPリクエストをmod_jkがTomcatへ転送、それをTomcatがその上で動作するwebアプリケーション（JSPやSprintとか）に渡す。
webアプリケーションはリクエストの基づいて処理を行い、結果をTomcat(APサーバ)へ返し、Tomcatはリクエストの時とは逆のルートで、mod_jkに返し、ApacheがクライアントへHTTPレスポンスを返す。

ApachとTomcat間の通信はHTTPではなく、ajp13というTomcat独自のプロトコル。

・webサーバーがHTMLファイルや画像、動画等の静的コンテンツのみで構成させるページを持ち
・動的コンテンツはAPサーバーが担う
・なので、サーバーサイドでは最低二つのプロセスが連携している。
・じゃあ動的コンテンツは直接APサーバーにリクエストがいくのかというとそうではない
・クライアント的にリクエスト内容によって要求先のプロセスが異なるのは困る
・なので、すべてのリクエストは一旦webサーバーに送る。
・設定ファイルで振り分けるリクエストを決めている。
・Tomcatだとworkers.propertiesファイル
・Apacheだとhttpd.conf
・http.confのJkMountでTomcatに送るパスを指定している
・ApacheとTomcatを別のノードにするなら、workers.propertiesにTomcatのIPを設定すればいい
・別のノードにできるので、Apache : Tomcatをn : n の構成で作れる
・でもあまり分離することはないとのこと（中小規模の場合）
・分離しすぎると複雑化して運用が大変
・実はほとんどのAPサーバーはwebサーバーとして動作させることもできる
・構成もシンプルで敷居が低くなるが、Apacheほどの機能性はない
・APサーバはwebサーバ機能意外にも、セッション管理、トランザクション管理、データベース接続管理等がある

webサーバーは全てのリクエストを一旦受け取るので、リクエスト回数は多いが、
処理としては静的コンテンツを返すだけなので、軽い。

一方APサーバーは動的コンテンツのリクエストを捌くので、webサーバーほとリクエスト回数は多くないが、
一つ一つの処理は重くなる傾向にある。

Lesson6

webアプリケーションのレイヤーパターン

プレゼンテーション層（コントローラ、ビュー）
システム利用者とアプリケーションのインターフェースとなるレイヤ
↓
ビジネスロジック層（モデル）
アプリケーションが実現すべき固有の処理を実行するレイヤ。
↓
データアクセス層（モデル）
ビジネスロジック層とデータベースの仲介を担うレイヤ

データアクセス層の実現方法としてDAO（Data Access object）がある
データアクセスをDAOクラスに切り分けて、再利用性と保守性を向上させる
DAOは大体テーブルごとに作られる

Lesson7

・SQLインジェクション
フォームなどの入力インターフェースにSQLを入れてデータベースを（開発者の意図しないものに）書き換える行為。
ユーザ名にtest, パスワードにpasswordを入力してログインできるとした場合、

select * from user where user_name='test' and password='password'

このようなSQLになる。

そこで、パスワードの入力欄に「'password' of 'or '1'='1'」と入力すると、

select * from user where user_name='test' and password='password' or '1' = '1'

というSQLになり、ログインできてしまう。
これはpasswordというパスワードを知らなくてもログインできる、つまり第三者でもログインできるのでまずい。

防ぐ方法としては
・入力値チェック
・プリアードステートメントの利用
がある

・クロスサイトスクリプティング
 SQLインジェクションと似ていて、HTMLの中に悪意あるJavascriptを埋め込んで、予期しないデータを表示させたりする行為。
Javascriptインジェクションともいう

防ぐ方法としては「サニタイジング」がある。
HTMLに影響を与える文字列（特殊文字）を文字参照に置き換え、無害化する。

・セッションハイジャック
クライアントとサーバ間でのやりとりで利用されているセッションIDを盗むこと。
セッションが乗っ取って、利用者になりすましたりする。

対策として、
・クロスサイトスクリプティング対策
・通信経路の暗号化（SSL）
・セッションタイムアウトの値を変える
・セッションIDをランダム化する

・クロスサイトリクエストフォージェリ（CSRF）
ユーザを攻撃用の（HTMLが埋め込まれた）サイトに誘導、（ユーザが訪れようとしているサイトにリンクを埋め込むなど）
サイトが読み込まれると同時にJavascriptが実行され、
ユーザに意図しないリクエスト（掲示板への書き込みだったり、商品の購入だったり）が行われる。

まとめ

本当にただの殴り書きになってしまった。
間違っている部分もあると思うので、都度修正していこうと思う。

Lesson7のセキュリティに関しては別記事でしっかりまとめていきたい。

おわり。