PHP の SESSION 原則と大規模 Web サイトに適用する際の注意点を分析する

PHP SESSION 原則
セッションはサーバー側でユーザーのセッション データを維持するためのメソッドであり、対応する Cookie はクライアント側でユーザー データを維持するためのものであることがわかります。 HTTP プロトコルはステートレス プロトコルであり、サーバーが応答すると、ブラウザーとの接続が失われます。Netscape では、クライアントがページ間でデータを交換できるように、最初にブラウザーに Cookie が導入されました。多くのユーザーのデータはどうなるのでしょうか?

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

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

これは事実なので、サーバーがセッションをサポートしていない場合、またはセッションをカスタマイズしたい場合は、PHP の uniqid を使用して重複しないセッション 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 はセッション ディレクトリのハッシュをサポートしています。php.ini で session.save_path = "2;/path/to/session/dir" を変更すると、セッションは 2 レベルのサブディレクトリに保存されます。各ディレクトリには 16 個のサブディレクトリがあります。サブディレクトリ [ 0~f] ですが、PHP セッションはディレクトリの作成をサポートしていないようなので、事前にディレクトリを作成する必要があります。

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

実際、セッションを保存するには多くの方法があり、php -i|grep "登録済み保存ハンドラー" を通じて表示できます。たとえば、登録済み保存ハンドラー => ファイル ユーザー sqlite eaccelerator は、ファイル、ユーザー、sqlite、サーバーに memcached がインストールされており、mmcache のオプションがある場合。もちろん、MySQL、PostgreSQL など、他にもたくさんあります。どれも良い選択です。

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

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

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