PHPにおけるセッションの実装原理と大規模Webサイトへの適用時に注意すべき課題を分析

PHP SESSION 原則
セッションはサーバー側でユーザーセッションデータを維持する方法であり、対応するクッキーは ユーザーデータをクライアント側に保持します。 HTTP プロトコルはステートレス プロトコルであり、サーバーが応答すると、ブラウザとの接続が失われます。 クライアントはデータをページ間で交換できるのですが、サーバーはどのようにして多くのユーザーのセッション データを記憶しているのでしょうか?

まず、クライアントとサーバーの間に 1 対 1 の接続を確立する必要があります。 サーバーがクライアントを識別できるように、各クライアントには一意の識別子が必要です。一意の識別には、Cookie または GET による指定の 2 つの方法を使用することをお勧めします。 PHP のデフォルト設定ではセッションが使用されます 「PHPSESSID」という名前の Cookie が作成されます (php.ini の session.name 値を変更することで指定できます)。クライアントが Cookie を無効にすると、 GET で取得するセッションを指定することもできます。 ID はサーバーに送信されます (php.ini の session.use_trans_sid などのパラメーターを変更します)。

サーバー側の session.save_path ディレクトリを確認すると、sess_vv9lpgf0nmkurgvkba1vbvj915 に似たファイルが多数見つかります。 実際には、セッションID「vv9lpgf0nmkurgvkba1vbvj915」に対応するデータです。真実はここにあります、クライアントはセッションします ID はサーバーに渡され、サーバーはセッションに従って ID を渡します。 ID で対応するファイルを検索します。読み取り時には、ファイルの内容を逆シリアル化してセッション値を取得し、最初にシリアル化してから書き込みます。

これが事実です このように、サーバーがセッションをサポートしていない場合、またはセッションをカスタマイズしたい場合は、PHP の uniqid を通じて繰り返されないセッションを DIY で生成できます。 id を取得し、セッションのコンテンツを保存する場所を見つけることもできます。flickr を使用してセッションを MySQL データベースに保存することもできます。

セッションを使用する前に session_start() を実行する必要があるのはなぜですか?
上へ 原理を理解すると、いわゆるセッションは実際にはクライアント側のセッション ID とサーバー側のセッションです。 ファイルを作成する前に session_start() を実行すると、サーバーに Cookie を植えてセッション ファイルを準備するように指示されます。 セッションのコンテンツを保存する方法。セッションを読み取る前に session_start() を実行すると、サーバーにセッションを迅速に追跡するよう指示します。 id はセッション ファイルを逆シリアル化します。

session_start()、session_name() の前に実行できるセッション関数は 1 つだけです。セッション名を読み取るか指定します (たとえば、デフォルトは「PHPSESSID」)。もちろん、これは session_start の前に実行する必要があります。

セッションはシステムパフォーマンスに影響します
セッション トラフィック量が多い Web サイトでは、システムのパフォーマンスが実際に影響を受けます。パフォーマンスに影響を与える理由の 1 つは、同じディレクトリ内に 10,000 個を超えるファイルがある場合、ファイルの配置に非常に時間がかかることです。 セッションディレクトリのハッシュは、php.ini の session.save_path = を変更できます。 "2;/path/to/session/dir" の場合、セッションは 2 レベルのサブディレクトリに保存され、各ディレクトリには 16 個のサブディレクトリ [0~f] がありますが、PHP は セッションはディレクトリの作成をサポートしていません。事前にこれらのディレクトリを作成する必要があります。

もう 1 つの問題は、一般に、小さなファイルの効率です。 セッション データはそれほど大きくはなりません (1 ～ 2K)。ディスク上に多数の 1 ～ 2K ファイルがある場合、IO 効率は確実に非常に悪くなります。PHP マニュアルでは Reiserfs ファイル システムの使用を推奨しています。 システムですが、Reiserfsの作者は妻を殺し、SuSEもReiserfsを放棄しました。

実際には他にもたくさんあります セッションの保存方法は、php -i|grep "Registered save handlers" (Registered save など) で確認できます。 ハンドラー => ファイル ユーザー sqlite eaccelerator は、ファイル、ユーザー、sqlite、および eaccelerator を介して保存できます。サーバーが memcached でインストールされている場合は、mmcache も存在します。 オプション。もちろん、MySQL、PostgreSQL など、他にもたくさんあります。どれも良い選択です。

セッション同期
ユーザーはサーバー A にログインし、セッション情報を設定し、Web サイトのいくつかのページにアクセスしてサーバー B にジャンプする可能性があります。サーバー B にセッションがない場合は、今回は、情報を特別に加工しないと問題が発生する可能性があります。
セッション同期には色々な種類がありますが、memcachedやMySQLに保存する場合は同じ場所に指定するだけで統一して保存できます。

もう 1 つの方法は、暗号化された Cookie を使用することです。ユーザーがサーバー A に正常にログインすると、ユーザーがサーバー B にアクセスしたときに、暗号化された Cookie が存在するかどうかを確認します。 セッションが存在する場合は、もちろん問題ありません。存在しない場合は、Cookie が有効であるかどうかを確認し、有効な場合はサーバー B でセッションを再確立します。この方法は実際には非常に効果的です これは、Web サイトに多数のサブチャネルがあり、サーバーが同じコンピュータ ルームになく、セッションが同期できず、均一にログインしたい場合に非常に便利です。

もちろん別の方法もあります 負荷分散層でセッションを維持し、訪問者を特定のサーバーにバインドします。訪問者はすべてそのサーバー上で行われるため、セッションの同期は必要ありません。これらはすべて運用および保守レベルで行われます。これを言ってください セッションはシステムのパフォーマンスに影響を与えると誰もが言うので、問題を攻撃したり隠したりする余裕がない場合は、セッションを使用することを躊躇しないでください。 、あなたはここにはふさわしくありません。