PHPセッション制御の原理は何ですか-PHPの問題-php.cn

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

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) デフォルトでは、すべてのユーザー情報はサーバーのハードディスクに保存されます。ただし、memcache を使用してこのデータをメモリに置くことができます。

(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 サイトの他の関連記事を参照してください。