PHPセッションケースの詳細説明

今回は、PHP セッションの場合について詳しく説明します。PHP セッションを使用する際の 注意事項 は何ですか?実際のケースを見てみましょう。

Cookie とセッションは、Web 開発の初心者が混同しやすい 2 つの概念であり、この 2 つを明確にすると、Web インタラクションをより深く理解するのに役立ちます。個人的には、セッションと Cookie の主な違いは次のとおりだと思います:

cookie

情報はクライアントに保存される

クライアントは特定の実装に責任を負う

データのサイズと量は一般に制限される

データは簡単に盗まれたり改ざんされたり

セッション

データはサーバー側に保存される

具体的な実装はサーバーが責任を負う

原則としてデータのサイズや量は無制限

高いセキュリティと信頼性が高い

狭義のセッションとは、Webセッションを指します。広義のセッションIDとセッション内の関連データは、通信する当事者間の対話型セッションを指します。たとえば、

ユーザー ログインはセッション インタラクション、ATM からのお金の引き出しはセッション インタラクションなどです。

セッションの詳細

セッションの主な機能は、セッションを識別し、セッション中のデータを保存することです。以下はセッションの詳細です。

Access

PHP は、$_SESSION

スーパーグローバル変数を介してセッション内のすべてのデータを取得して保存します。 $_SESSION は、簡単に割り当てて読み取ることができる配列です。例:

有効期限

PHP が時間内にガベージ コレクションを実行するかどうかに応じて、セッションのタイムアウト後にデフォルト セッションのデータが削除される場合があります。 PHP が実行するガベージ コレクションの係数はリクエストの数であるため、次のような結果が得られます。 1. トラフィックの少ないサイトのセッション データはタイムアウト後も長時間削除されません。 2. トラフィックの多いサイトはセッション ガベージ コレクションを頻繁に実行します。 3. ガベージの実行 ガベージ コレクションが実行されている場合、コレクションがユーザーの要求を実行する前にシステムの遅延が発生する可能性があります。より良い解決策は、PHP のデフォルトのガベージ コレクションを無効にし、cron タスクで session_gc 関数を定期的に実行することです。これにより、セッションの適時性が確保されるだけでなく、パフォーマンスとユーザー エクスペリエンスも向上します。

セッション内のデータを手動で削除するには、unset を使用して単一のデータ項目を削除するか、session_destroy 関数を使用してすべてのデータを強制的に削除します。

ストレージメディアとシリアル化

セッション内のデータは、デフォルトでファイルの形式でディスクに保存されます。セッションが開かれると、

ファイルの内容が読み取られ、それが逆シリアル化されて、$_SESSION に書き込まれます。配列。トラフィックの多いサイトでは、セッション ファイルが保存されるディレクトリに多数の小さなファイルが含まれるため、ファイル システムに大きな IO 負荷がかかります。

セッションモジュールのハンドラーは、データベース、redis/memcache、その他のメディアにデータを保存するなど、データの保存方法を指定できます。 PHP の組み込みハンドラーには、ファイル (デフォルト)、redis、memcache が含まれます。ユーザーは、session_set_save_handler を通じて独自のハンドラーを登録できます。

session に保存されるデータは、

strings などの基本型である場合もあれば、配列やオブジェクトなどの複雑な型である場合もあります。セッション設定の Serialize_handler は、シリアル化および逆シリアル化のハンドラーを設定するために使用されます。ハンドラーがデータをシリアル化した後、データは保存のために save_handler に渡されます。シリアル化から、リソースなどの型はセッションに保存できないし、保存すべきではないことがわかります。 DB 接続ハンドルをセッションに保存し、10 分後に取り出して使用するという考えは、できるだけ早く破棄する必要があります。

セッション設定名

httpはステートレスプロトコルであるため、クライアントはリクエスト時にサーバーがセッションを区別できるようにセッションIDを伝える必要があります。セッション ID を識別するデフォルトの名前は PHPSESSID です。 session_name を使用して他の名前を設定できます。たとえば、攻撃者がバックエンドが PHP 言語システムであると推測できないようにするには、セッション ID の名前を JSESSIONID に設定して攻撃者を混乱させることができます。

セッションは自動的に開かれます

現在の主流の PHP バージョンは、デフォルトではセッションを自動的に開きません。たとえば、訪問者がページを閲覧するだけで終了する場合、セッションが自動的に開かれると、一連の初期化操作の後にセッション ID がクライアントに送信され、次回訪問時にユーザーを識別できるようになります。 1 回限りの訪問者、またはシステムにログインしていないユーザーの場合、これらの操作は追加のオーバーヘッドをもたらすだけです。

セッションが自動的に開かれないことの欠点は、セッションを使用する前にセッションが開いていることを確認する必要があることです。そうしないと、空のデータが取得される可能性があります。デフォルトのセッション名が変更された場合は、session_start の前に session_name を呼び出して、現在使用されているセッション名を示す必要があります。

分散セッション

トラフィックが多いサイトでは、バックエンドでサービスを提供する複数の PHP サーバーが存在することがよくあります。ユーザーの複数のリクエストが同じサーバーに到達せず、サーバーのセッション データが共有されない場合、ユーザーは繰り返しログインする必要がある場合があります。この問題は、フロントエンドでリクエストを分散するか、バックエンドで分散共有セッションをセットアップすることで解決できます。

セッション データをファイルの形式で保存するシステムでは、ディレクトリを共有ディレクトリとして指定でき、すべてのサーバー セッションはこのディレクトリに保存されます。セッションを redis/memcache/db などに保存するシステムでは、同じディレクトリへの接続により、セッション サーバーがセッション共有を実現できます。セッション共有を使用して構築されたシステムでは、フロントエンド ロード バランサーはリクエストを任意のサーバーに分散できます。

この記事の事例を読んだ後は、この方法を習得したと思います。さらに興味深い情報については、php 中国語 Web サイトの他の関連記事に注目してください。

推奨読書:

PHP+ajaxを使用してニュースデータを取得するケースの詳細説明

制御可能な同時非同期操作を実装するphpのcurlバッチ処理ケースの詳細な説明

以上がPHPセッションケースの詳細説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。