PHPセッション制御の原理は何ですか

#セッション制御とは何ですか?

Cookie とセッションはどちらも、セッション プロセス全体を追跡するための技術的手段です。セッションとは、ブラウザを介したユーザーとサーバー間の呼び出しです。

なぜセッション制御が必要なのでしょうか?

HTTP プロトコルはステートレスであるため、サーバーはユーザーが最後に何をしたかを認識できず、対話型 Web アプリケーションの実装に重大な支障をきたします。 HTTP は追加の手段を使用しません。サーバーはユーザーが何をしたかを知りません。これを行うには、Cookie とセッションを使用する必要があります。サーバーは、Cookie に含まれる情報を設定または読み取り、サーバーとのユーザーのセッションの状態を維持できます。

セッションとクッキーの違いは何ですか?

保存場所、プライバシー ポリシーとセキュリティ、データの種類、有効期間、サーバーの負荷、ブラウザのサポート、クロスドメインのサポート、データ量。

(1) Cookie はクライアント側にあり、セッションはサーバー側にあります

(2) Cookie はローカルであり、自由に変更でき、セッションはより安全です

(3) Cookie は asciII 文字列のみをサポートしており、デコードする必要があります。セッションはすべてのデータ型をサポートします。

(4) Cookie はローカルに保存され、永続的に有効になります。セッションはサーバー上にあります。設定が永続的に有効になると、サーバー上のセッションが蓄積され続けるため、メモリ オーバーフローが発生します。

(5) セッションは一定期間内にサーバーに保存されます。アクセスが増えるとサーバーのパフォーマンスを圧迫するため、サーバーのパフォーマンスを下げることを主に考えている場合は、Cookie を使用することをお勧めします。

(6) Cookie はブラウザのサポートを必要としますが、セッションはサポートしていません。

(7) Cookie はクロスドメインをサポートしますが、セッションはクロスドメインをサポートしません。

(8) ストレージ容量が異なります。

関連する推奨事項: 「PHP チュートリアル 」

1. データ型の違い

アクセスが必要な場合、Unicode 文字を使用する場合、Cookie は ASCII 文字列のみを保存できます。または、バイナリ データを最初にエンコードする必要があります。 Cookie は Java オブジェクトに直接アクセスできません。もう少し複雑な情報を保存するには、Cookie を使用するのが難しくなります。

セッションは、文字列、整数、リスト、マップなどを含むがこれらに限定されない、あらゆる種類のデータにアクセスできます。 Java Beans や Java クラス、オブジェクトなども直接セッションに保存できるため、非常に使いやすくなります。セッションは Java コンテナ クラスとみなすことができます。

2. プライバシー ポリシーの違い

Cookie はクライアントのブラウザに保存され、クライアントに表示されます。クライアント上の一部のプログラムは、Cookie 内のコンテンツをスヌープ、コピー、さらには変更する場合があります。セッションはサーバーに保存され、クライアントに対して透過的であるため、機密情報が漏洩するリスクはありません。

Cookie を選択する場合は、アカウントのパスワードなどの機密情報を Cookie に書き込まないようにすることをお勧めします。 Google や Baidu のように Cookie 情報を暗号化し、サーバーに送信した後に復号化して、その人だけが Cookie 内の情報を読み取ることができるようにするのが最善です。 Session を選択すると、はるかに簡単になりますが、とにかくサーバー上に配置されるため、Session 内のプライバシーは効果的に保護されます。

3. 有効期限の違い

Google を使用したことがある人なら誰でも、Google にログインしていれば、Google ログイン情報は長期間有効であることを知っています。 Google はユーザーのログイン情報を永続的に記録するため、ユーザーはアクセスするたびに再度ログインする必要はありません。この効果を実現するには、Cookie を使用することをお勧めします。 Cookie の有効期限属性を非常に大きな数値に設定するだけです。

セッションは JSESSIONID という名前の Cookie に依存しており、Cookie JSESSIONID のデフォルトの有効期限は -1 であるため、ブラウザが閉じている限りセッションは無効になるため、セッションは永続的な有効性の効果を達成できません。情報。 URL アドレスの書き換えを使用してこれを実現することはできません。また、セッション タイムアウトの設定が長すぎると、サーバーに蓄積されるセッションが増えるほど、メモリ オーバーフローが発生しやすくなります。

4. サーバープレッシャーの違い

セッションはサーバー側に保存され、各ユーザーがセッションを生成します。同時にアクセスするユーザーが多い場合、大量のセッションが生成され、大量のメモリを消費します。したがって、Google、Baidu、Sina などの同時訪問数が非常に多い Web サイトでは、Session を使用してユーザー セッションを追跡する可能性は低いです。

Cookie はクライアント側に保存され、サーバーのリソースを占有しません。同時に読んでいるユーザーが多い場合は、Cookie が良い選択です。 Google、Baidu、Sina にとっては、Cookie が唯一の選択肢かもしれません。

5. ブラウザのサポートの違い

Cookie はクライアントのブラウザでサポートされている必要があります。クライアントが Cookie を無効にしている場合、または Cookie をサポートしていない場合、セッション追跡は無効になります。 WAP 上のアプリケーションに関しては、通常の Cookie は役に立ちません。

クライアントのブラウザが Cookie をサポートしていない場合は、セッションと URL アドレスの書き換えを使用する必要があります。セッション プログラムを使用するすべての URL を書き換える必要があることに注意してください。書き換えないと、セッション トラッキングが無効になります。 WAP アプリケーションの場合、セッション URL アドレスの書き換えが唯一のオプションとなる場合があります。

クライアントが Cookie をサポートしている場合、Cookie をこのブラウザ ウィンドウとサブウィンドウで有効に設定する (有効期限を –1 に設定する) ことも、すべてのブラウザ ウィンドウで有効になるように設定する (有効期限を -1 に設定する) こともできます。有効期限を 0 より大きい整数に設定します)。ただし、Session は、このリーダー ウィンドウとそのサブウィンドウ内でのみ有効です。 2 つのブラウザ ウィンドウが互いに独立している場合、それらは 2 つの異なるセッションを使用します。 (IE8 での異なるウィンドウでのセッションに関連)

6. クロスドメイン サポートの違い

Cookie はクロスドメイン アクセスをサポートします。たとえば、ドメイン属性が「.biaodianfu」に設定されている場合.com"、次に " サフィックス「.biaodianfu.com」を持つすべてのドメイン名がこの Cookie にアクセスできます。クロスドメイン Cookie は現在、Google、Baidu、Sina などのインターネットで一般的に使用されています。セッションはクロスドメイン名アクセスをサポートしません。セッションは、それが存在するドメイン名内でのみ有効です。

Cookie のみを使用したり、Session のみを使用したりすると、期待した効果が得られない可能性があります。現時点では、Cookie とセッションを同時に使用するようにしてください。 Cookie とセッションの組み合わせは、実際のプロジェクトにおいて多くの予期せぬ効果をもたらします。

7. 保存されるデータの量は異なります

1 つの Cookie によって保存されるデータは 4K を超えることはできず、多くのブラウザーでは、サイトで保存できる Cookie は 20 個までに制限されています。

セッションと Cookie の使用シナリオ?

ログイン情報などの重要な情報は SESSION として保存し、その他の情報を保持する必要がある場合は COOKIE に配置できます。

Cookie はどのように機能しますか?

1. Cookie は 2 種類に分類されます

(1) ファイル形式でハードディスク領域に保存される永続的な Cookie ([パスワードを記憶する] と [自動ログイン]) (Web サイトの機能は永続的な Cookie です)

(2) ブラウザのメモリを占有する一時的な Cookie があります

2. Cookie は、クライアント上で状態を維持するソリューションを使用します。クライアント上のセッション状態のストレージメカニズム。これは、サーバーによってローカル マシンに保存された小さなテキスト、またはメモリ内のデータであり、リクエストごとに同じサーバーに送信されます。

Cookie の仕組み:

Cookie の仕組み 。HTTP プロトコルの基本的な基礎が必要です。

Cookie は、RFC2109 (廃止され、RFC2965 に置き換えられました) で最初に説明されました。各クライアントは最大 300 個の Cookie を保持でき、各ドメイン名は最大 20 個の Cookie を保持できます (実際、現在、ほとんどのブラウザでは、これ (たとえば、Firefox は 50)、各 Cookie のサイズは最大 4K ですが、ブラウザーごとに独自の実装があります。 Cookieを使用する場合、最も重要なことはCookieのサイズを制御すること、無駄な情報を入れないこと、過剰な情報を入れないことです。

どのようなサーバー テクノロジが使用されているかに関係なく、返された HTTP 応答に次の形式のヘッダーが含まれている限り、サーバーは Cookie の設定を必要としているとみなされます:

Set-cookie:name=name;expires=date;path=path;domain=domain

ブラウザこれに応答して、Cookie ファイルが作成され、保存されます (メモリ Cookie の場合もあります)。今後ユーザーがリクエストを行うたびに、ブラウザは現在の Cookie の有効期限が切れているかどうかを判断する必要があります (判断された場合)。パス属性の Cookie 情報があれば、リクエスト ヘッダーに追加され、次の形式でサーバーに送り返されます。

Cookie: name="zj"; Path="/linkage"

サーバーはそれを分析し、それに応じて処理します。もちろん、直接無視することも選択できます。

Cookie のメカニズム Cookie は、サーバーによってローカル マシンに保存され、リクエストごとに同じサーバーに送信される小さなテキストです。 IETF RFC 2965 HTTP 状態管理メカニズムは、一般的な Cookie 仕様です。 Web サーバーは、HTTP ヘッダーを使用してクライアントに Cookie を送信します。クライアント端末では、ブラウザがこれらの Cookie を解析し、ローカル ファイルに保存します。これらの Cookie は、同じサーバーへのリクエストに自動的にバインドされます。

具体的には、Cookie メカニズムはクライアント側で状態を維持するソリューションを採用しています。これはユーザー側のセッション状態の保存メカニズムであり、ユーザーはクライアント側で Cookie サポートを有効にする必要があります。 Cookie の役割は、HTTP プロトコルのステートレスな欠陥を解決するための取り組みです。

オーソドックスな Cookie の配布は、HTTP プロトコルを拡張することで実現され、サーバーは HTTP 応答ヘッダーに特別な命令行を追加し、その命令に従って対応する Cookie を生成するようブラウザに指示します。ただし、JavaScript などの純粋なクライアント側スクリプトも Cookie を生成する可能性があります。 Cookie の使用は、特定の原則に従ってブラウザによってバックグラウンドでサーバーに自動的に送信されます。ブラウザは、保存されているすべての Cookie をチェックします。宣言された Cookie のスコープが、リクエストされるリソースの場所以上である場合、Cookie はリクエストされたリソースの HTTP リクエスト ヘッダーに添付され、サーバーに送信されます。

Cookie の内容には主に、名前、値、有効期限、パス、ドメインが含まれます。パスとドメインを合わせて Cookie のスコープを形成します。有効期限が設定されていない場合、この Cookie の有効期間はブラウザ セッション中であることを意味し、ブラウザ ウィンドウを閉じると Cookie は消えます。ブラウザーのセッション中に保持されるこのタイプの Cookie は、セッション Cookie と呼ばれます。セッション Cookie は通常、ハードディスクではなくメモリに保存されますが、もちろん、この動作は仕様で指定されていません。有効期限が設定されている場合、ブラウザは Cookie をハード ディスクに保存します。ブラウザを閉じて再度開いても、設定された有効期限を超えるまでこれらの Cookie は有効です。ハード ドライブに保存された Cookie は、2 つの IE ウィンドウなど、異なるブラウザ プロセス間で共有できます。ブラウザが異なれば、メモリに保存された Cookie の処理方法も異なります。

セッション メカニズムは、サーバー側で状態を維持するソリューションを使用します。同時に、サーバー側で状態を維持するソリューションではクライアント側でも ID を保存する必要があるため、セッション メカニズムでは ID を保存するという目的を達成するために Cookie メカニズムを使用する必要があることもわかりました。 Session は、グローバル変数を管理する便利な方法を提供します。

セッションはユーザーごとに作成されます。変数の値はサーバーに保存されます。セッション ID は、どのユーザーのセッション変数であるかを区別するために使用されます。この値は、アクセス時にユーザーのブラウザを通じてサーバーに返されます。クライアントが Cookie を無効にすると、この値が get によってサーバーに返されるように設定されることもあります。

セキュリティの観点: セッションを使用するサイトにアクセスしてマシン上に Cookie を作成する場合、サーバー側のセッション メカニズムをより安全にすることをお勧めします。これは、クライアントのセッション メカニズムが恣意的に読み取られることがないためです。保存されたデータの情報。

セッションはどのように機能しますか?

(1) デフォルトでは、すべてのユーザー情報はサーバーのハードディスクに保存されます。ただし、me​​mcache を使用してこのデータをメモリに置くことができます。

(2) クライアントがサーバーにリクエストを送信し、サーバーにセッションの生成を要求すると、サーバーはまずクライアントの Cookie に session_id があるかどうか、および有効期限が切れているかどうかを確認します。そのような session_id がある場合、サーバーは Cookie 内の session_id に基づいてサーバーのセッションを取得します。そのような session_id が存在しない場合、サーバーはセッション ID を再作成します。 PHPSESSID は暗号化された文字列であり、その生成は特定の規則に従って実行されます。同じクライアントが session_start を 2 回開始すると、session_id は異なります。

(3) サーバー側で状態を維持するソリューションでは、クライアント側でも ID を保存する必要があるため、セッション メカニズムは Cookie メカニズムを使用して ID を保存するという目的を達成します。 ##(4) セッションの生成 session_id は cookie に設定されていますが、ユーザーが cookie を無効にするとセッションは使用できなくなりますか? Cookie を無効にした後もセッションはもちろん使用できますが、セッション ID は URL の末尾でルートしたり、フォームの形式でサーバーに送信したりするなど、他の方法でも取得できます。これにより、サーバーはクライアントのステータスを理解できるようになります。

セッションの原理をもう一度見てみましょう:

(1) グローバルに一意識別子 (sessionid) を生成します;

(2) データ ストレージ スペースを開きます。通常、対応するデータ構造はメモリ上に作成されますが、この場合、システムの電源がオフになるとすべてのセッションデータが失われ、電子商取引 Web サイトの場合、この種の事故は重大な結果をもたらします。ただし、ファイルに書き込んだり、データベースに保存したりすることもできます。これにより、I/O オーバーヘッドは増加しますが、セッションはある程度の永続性を実現でき、セッション共有がより容易になります;

( 3) セッションのグローバルに一意識別子をクライアントに送信します。

セッション メカニズム

セッション メカニズムはサーバー側のメカニズムであり、サーバーはハッシュ テーブルに似た構造を使用します (またはハッシュ テーブルを使用する場合もあります)。情報。

プログラムがクライアントのリクエストに対してセッションを作成する必要がある場合、サーバーはまずクライアントのリクエストにセッション識別子 (セッション ID と呼ばれる) が既に含まれているかどうかを確認します。含まれている場合は、以前に作成されたことを意味します。このクライアントはセッションを作成しました。サーバーはセッション ID に従ってセッションを取得します (取得できない場合は、新しいセッションを作成します)。クライアント リクエストにセッション ID が含まれていない場合、セッションはクライアント用に作成され、これを使用したセッションが生成されます。セッションに関連付けられたセッション ID。セッション ID の値は、繰り返されず、偽造するパターンが簡単に見つからない文字列である必要があります。このセッション ID は、に返されます。この応答のストレージ用のクライアント。

このセッション ID を保存する方法では Cookie を使用できるため、対話プロセス中に、ブラウザーはルールに従ってこの ID をサーバーに自動的に表示できます。通常、この Cookie の名前は SEEESIONID に似ています。ただし、Cookie は人為的に無効にすることができるため、Cookie が無効になっている場合でもセッション ID をサーバーに戻す他のメカニズムが必要です。

頻繁に使用される手法は URL 書き換えと呼ばれるもので、URL パスの末尾にセッション ID を直接追加します。フォーム隠しフィールドと呼ばれる手法もあります。つまり、サーバーは自動的にフォームを変更し、非表示フィールドを追加して、フォームの送信時にセッション ID をサーバーに返すことができるようにします。

Cookie と Session はどちらもセッション追跡を実行できますが、実装原理は異なります。通常は両方でニーズを満たすことができますが、Cookie が使用できない場合や、Session が使用できない場合があります。以下に両者の特徴と適用場面を比較します。

以上がPHPセッション制御の原理は何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。