Webアプリケーション通信

Webアプリケーションは，クライアント（Webブラウザ）から送られてくるリクエストを受け取って動作します。

通信(リクエスト・レスポンス）の仕組みとしては、次の方法が行われます。

１、通信型
・プル（pull）型
Webアプリケーション(ブラウズなど）がHTTPリクエストを行い、レスポンスを受ける。
サーバーから情報を「引き出す」ことによって動作するのでプルと呼ばれる

・プッシュ（push）型
Webアプリケーションが，サーバ側主導でレスポンスを受ける。
サーバーがクライアント側に情報を「押し込む」動作になるのでプッシュと呼ばれる

・ポーリング（polling）
定期的（例えば1秒間隔）でリクエストを行い、サーバーからレスポンス（最新情報を得る）を受ける

Webアプリケーションでは、サーバーの情報が更新されていてもいなくても，定期的にサーバーにアクセスする必要があります。
その場合，ユーザーが多くなってくると，サーバーへのアクセス数が非常に多くなってしまい、負荷が高くなってサーバダウンを考慮しなければなりません。
したがって、ポーリングで情報取得するより、プッシュ型で情報取得を考慮する必要があります。

その方法として、以下の方法があります。

第2回 Comet---プッシュ型のWebアプリケーションを作る

http://itpro.nikkeibp.co.jp/article/COLUMN/20080220/294242/

Cometではポーリングが発生しなくなります。
したがって，サーバーへのアクセス数を減らすことができます。
また，サーバーに書き込みがあったタイミングで情報が送られてくるので，リアルタイム性も向上することになります。

２、セッション
（１）HTTP
Webアクセスに使うHTTPには「セッション」という概念がない。
そこで、サイト側が主導権を取って，Webブラウザとの間で情報をやりとりすることで，複数ページにまたがる一連のWebアクセスを「セッション」として扱うようになっている。
さらにWebサイトは，確立したセッションの処理の進行状態を管理する。

参考ＵＲＬ：http://itpro.nikkeibp.co.jp/article/COLUMN/20081010/316684/

(2) セッション管理
Webアプリケーションで、ログインからログアウトまでが，一つのセッションとなります。
Webアプリは複数Webページにまたがっても，ユーザーを識別して，前のWebアクセスの処理結果を引き継いで処理を続ける。その陰では，複数のWebアクセスを関連付け，処理の進行状態を管理するセッション管理のしくみが働いている。
「ログイン」を必要とするサイトはセッション管理を行います。
セッション管理は、システム上で一意となるセッションIDをユーザーのブラウザとWebアプリケーション(または、サーバ）で共有することによって、Webアプリケーションがユーザーを特定することが可能となる。
共有する仕組みは、Cookieを利用するものと、GET／POSTパラメータなどを利用するものとで大きく2つに分けられる。
いずれの仕組みもWebアプリケーション側がセッションIDを発行してユーザーへの送信を行い、ユーザーが以降のアクセスでそのセッションIDを毎回Webアプリケーションへ送信する形となる。

参考ＵＲＬ：http://www.atmarkit.co.jp/ait/articles/0810/21/news133_2.html

セッションIDの管理は不備(セッションハイジャック)のないようにしっかり管理をする必要があります。

対策として、以下があります。
・推測困難なセッション ID を利用する
・セッション ID を URL に含めない
・HTTPS 通信で利用する Cookie には secure 属性を付与する
　⇒HTTPS 通信時のみ Cookie の値を Webサーバーに送信する
・ログイン後にセッションを新規に開始する
・クラインアント、サーバ間のセッションＩＤを都度更新する


参考ＵＲＬ：http://www.websec-room.com/2013/03/09/497

また、2度押し対策も検討する必要がある。