 |
||||||||||||||
|
||||||||||||||
| 1 2 3 4 次のページ | ||||||||||||||
|
||||||||||||||
| セッションとは | ||||||||||||||
|
HTTPというステートレスなプロトコルを用いるWebアプリケーションにおいて、セッションの位置づけというのは一体どういったものなのでしょうか。 |
||||||||||||||
| HTTPの特性 | ||||||||||||||
|
HTTPは不特定多数の利用者が不定期に来訪するという性質を持つプロトコルです。したがって、サービスを提供する側（サーバ）の数は必ずしも利用者数に対して同数ではありません。 また、HTTPは利用者側から一方的に発生された要求（リクエスト）に対して、サーバ側が応答（レスポンス）を返すというひとつの流れだけで「ひとつの取引」（トランザクション）という括り方になります。逆にサーバ側から利用者側に一方的に応答を求める要求を送るということはありません。 この特性からも考えられるように、通常、何の細工も施されていないWebコンテンツにおいて、不定期に送られてくる一方的なリクエストを待ち受けるサーバは、そのリクエストを送ってきた"主"を特定することができません。また、利用者が複数のページを遷移する場合において、各ページの間を誰がどのような経路で渡り歩いたのかを知り得る術がありません。 |
||||||||||||||
| セッションの概念 | ||||||||||||||
|
Webアプリケーションを実装するにあたり、複数の画面を遷移してひとつの取引（トランザクション）を行うケースは非常に多く見られます。ECサイト上での取引を例に取ると、図1のような流れが一般的ではないでしょうか。  図1：ECサイトの一般的な取引の流れ 画面遷移毎に利用者から送りつけられる要求が複数回におよぶということは、HTTPトランザクションが複数回発生するということです。この場合、Webアプリケーション側では、一番最初に「商品をカートに入れる」ところから始まり「取引完了」までの間、リクエストを送ってくる"主"を何としてでも特定しなければ、他人がカートに放り込んだ商品が自分の手元に送付されてしまうような状況を招きかねません。 こうした問題点を解消するために、セッションという概念が存在します。端的に言えば、セッションとは「リクエストとその"主"を結びつけるためのしくみ」と言うことができます。 例えばあなたが旅行や出張でホテルに宿泊した際、チェックインの際に部屋のキーを受け取り、チェックアウトの際にキーを返し、料金を支払います。ついでにチェックインの時にクロークに預けた荷物を渡してくれます。チェックイン、チェックアウトの時、フロントで取り次いでくれるホテルマンが同じ人である保証はないのに、チェックアウトの時、なぜ速やかに対処してくれるのでしょうか。 言うまでもなく宿泊客の顔…ではなく、あなたがチェックアウト時に渡したキーに付加された「部屋番号」があなたの一意性を保証していて、ホテル側はその部屋番号の人に対して「どう対処すべきか」の情報を管理しています。 これと同じしくみをWebアプリケーションに当てはめて考えた場合、Webサイトの利用者（宿泊客）は「部屋番号」と同様の「一意性を保証するキー」の受け渡しをサーバ（フロント）との間で行なうことにより、サーバ（フロント）側がその要求に対して「どう対処すべきか」を判別することができます。 |
||||||||||||||
|
1 2 3 4 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
