セッション管理が必要な理由は、HTTPプロトコルには状態を保持する機能がないため

大前提

Webデータのやり取り
Webサーバ側とクライアント側(ユーザエージェント／Webブラウザ)とで、HTTPプロトコル(インターネットプロトコルの一種)を介して行なわれる

HTTPプロトコル(HTTP通信)
・ブラウザからの要求（リクエスト）とサーバからの応答（レスポンス）を1つの単位として通信が完結する形となっている
・１回のリクエスト（要求）とレスポンス（応答）の間に、「接続→通信→切断」という一連の処理が行われる仕組みとなっている
・つまり、ページを移動するたびに同じ処理(リクエストによってページのデータがレスポンスされ、受信が終わったら通信を切断)が繰り返し行われることになる(同期通信)
・通常複数の通信間の関連性を管理することは出来ない

セッション管理の必要性
・HTTPプロトコルには、状態を保持する機能がない
・ユーザー（ブラウザ）が連続的に複数回のアクセス（Webページの表示）を試みても、サーバ側はそれを特定のユーザーの連続したアクセスと認識せず、複数のユーザーが複数回アクセスしたものとして認識してしまう

セッションがないとどうなるの？
例えば、認証が行なわれているサイトでは、クライアントがページを移動するたびに、(通信は都度切断されているため)認証を求められてしまうことになる

セッション管理機能とは？

セッション管理
・クッキーなどであたかも1セッションが連続しているように見せかけている
・具体的には、Webサイトに、特定のユーザーからの状態（アクセス履歴や、入力したデータなどの情報）を保持した上で、次にそのユーザーがアクセスしたときに、特定ユーザーからのアクセスであることをサーバ側が認識している

セッション管理機能の仕組み
・クライアント側に保存させておきたくない情報(セッションデータ)をサーバー側で保存(クライアント側には、セッションIDと呼ばれるランダム文字列のみを保存)
・サーバー・クライアント間では、このセッションIDのみをやりとりする
・具体的には、セッションIDを介してサーバー側に保存させておいたセッションデータを読み込む

クッキーとの違い
・CookieはRFC(プロトコルやファイルフォーマットの公開形式)にて明示的に定められている一つの「仕様」であり「実装」
・一方、セッションはあくまで「概念」であり、実装ではない
・具体的には、セッションを実現する手段の一つとして「Cookieを利用する方法」や、「input type hiddenを用いる方法」などがある
・さらに言えば、セッションIDの受け渡し手段の一つが「Cookieを利用する方法」となっている

セッション処理の流れ

1.アクセスがあったユーザーに対してサーバ側から、予測困難な特定のセッションIDを割り振る
・初回アクセス時のユーザーへ対して、サーバ側からユーザーに対して自動的に識別コードを割り振る
・その識別コード(セッションID)を使用してユーザーを特定する

2.割り振ったセッションIDに対する情報をサーバへ保存
・割り振ったセッションIDに対する情報をサーバに保存する

3.ユーザーがそれぞれ個別のセッションID(クッキー)をサーバーへ送る
・ユーザー（ブラウザ）は、そのWebサイトへアクセスする度に、毎回必ずセッションIDを送信する必要がある

4.セッションIDにマッチする情報をサーバから読み込む
・セッションID(クッキー)にマッチする(紐づいた)情報(セッションデータ)を、サーバから読み込む。該当がなければそのクッキーは無視

5.セッションデータを$_SESSION変数に格納
・セッションデータ(サーバから読み込んだ情報)を$_SESSION変数に格納する

※PHPでセッションを使えば自動的にクッキーも使っている
・セッションIDを保存するデフォルトのCookie名は、php.iniの設定により変更可能

セッションIDを(共有するために)受渡す方法は3種類ある

「クライアント側のブラウザ」と「サーバ側のWebアプリケーション」でセッションIDを共有する3つの方法
・方法A.Cookieへ書き込んで渡す
・方法B.URLパラメータとして付与
・方法C.hiddenで送信

方法A.Cookieへ書き込んで渡す

最も一般的な方法
・ クッキーは、Webサイトにアクセスする度にブラウザから自動で送信されるため、別のユーザーが同じURL（例えば、 http://php.w4c.work/ など）にアクセスをした場合でも、Webアプリケーション側で各ユーザーに合わせた情報を表示することができる
・Webアプリケーションで特別な処理は不要
・非常に便利
・また、外部サイトからの遷移でもセッション管理を行うことが可能となる
※クライアントがCookieを受け入れない可能性は ある

1.Webサイトは、Webブラウザに送るHTTPレスポンスの拡張ヘッダーへ、セッションIDを書き込んだCookieを付けて送信
・Cookieを受けとったWebブラウザは、そのCookieを保存

2.次回以降、WebブラウザがWebサイトへアクセスする際、HTTPリクエストの拡張ヘッダーにCookieを付けて送信(ブラウザは自動でCookieを送信する仕組みを持っている)
・Webサイトは、受け取ったCookieに含まれるセッションIDを見て、セッションの識別を行う
※Cookieは、Webサイトが指定した有効期限までの間、Webブラウザが保存し続ける
※この間Webブラウザは、いつWebサイトへアクセスしても同じCookieを送ることになる

方法B.URLパラメータとして付与

セッションIDをURLへ直接埋め込む
GETパラメータ利用
・Webサイトが「処理をリクエストする実行ボタンのリンク」にセッションIDを付けて送る
・WebブラウザがセッションID付きのURLで処理をリクエスト
・セッションIDがWebブラウザのアドレス・バーに表示されることになるため、セキュリティ上問題がある

自動的に「相対URIにセッションIDを含むよう変換」するには？
・構築オプション--enable-trans-sidをconfigureに指定
・session.use_trans_sidを有効にする

PHPの設定パラメータ「session.use_trans_sid」設定値により、大きく2種類に分かれる
α．PHPの設定パラメータ「session.use_trans_sid」が１に指定されている場合
・ハイパーリンクの相対URLに、URL Rewriting機能により自動的にセッションIDが追加され、次のファイルにセッションIDが引き渡される

β．PHPの設定パラメータ「session.use_trans_sid」が0に指定されている場合
・ハイパーリンクのURLに、定数SIDを記述し、セッションIDを次のファイルに引き渡す
<a href="next.php?<?=SID?>">次ページ</a>
定数SIDには、セッション名=セッションIDが代入され、次のように置換される
<a href="next.php?PHPSESSID=a1b2c3d4e5d">次ページ</a>

定義済み定数 SID
・"name=ID" 形式でセッション名とセッション ID を格納している定数
・セッション ID がセッションクッキーに適切にセットされている場合には空文字列が入る
・これは session_id() が返す ID と同一になる
・セッションが開始している状態で利用すると、クライアントが適当な セッションクッキーを送信しなかった場合、この定数が session_name=session_id の形式となる
・送信された場合には、この定数には、空の文字列が入る
・このため、この定数を無条件に URL に埋め込むことが可能
※Cookieが使用できない場合、定数SIDには、セッション名=セッションIDが自動的に展開される

方法C.hiddenで送信

Webページのフォーム・データに埋め込む(input type hidden利用)
・フォームの＜hidden（ヒドゥン）＞を利用してセッションIDをやりとりする
・Webアクセスでフォーム・データの一部としてセッションIDを送信
・画面遷移をする際には必ず（リンクをクリックするときなどでも）セッションIDを送信する必要があり、安全にセッションIDを送信するための仕組みを組み込む必要がある

1.Webサイトがフォーム・データにセッションIDを埋め込んで送る
2.Webブラウザが入力フォームのパラメータとしてセッションIDを送る

1.データベースに格納
2.ファイルに格納
3.メモリ上に格納