PHP セッションの仕組み_PHP チュートリアル
- WBOYオリジナル
- 2016-07-13 10:33:44791ブラウズ
PHP セッションの原則
セッションはサーバー側でユーザーセッションデータを維持するためのメソッドであり、対応するCookieはクライアント側でユーザーデータを維持するためのものであることがわかります。 HTTP プロトコルはステートレス プロトコルであり、サーバーが応答すると、ブラウザーとの接続が失われます。Netscape では、クライアントがページ間でデータを交換できるように、最初にブラウザーに Cookie が導入されました。多くのユーザーのデータはどうなるのでしょうか?
まず第一に、サーバーが識別できるように、各クライアントは一意の識別子を持っている必要があります。一意の識別には、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() の前に実行できるセッション関数は 1 つだけです session_name(): セッション名を読み取るか指定します (たとえば、デフォルトは「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)。ディスク上に多数のファイルがある場合、PHP の IO 効率は確実に低くなります。マニュアル Reiserfs ファイルシステムの使用が推奨されていますが、Reiserfs の作者は妻を殺害し、SuSE も Reiserfs を放棄しました。
実際、セッションを保存するにはさまざまな方法があり、php -i|grep "Registered save handlers" を通じて表示できます。たとえば、Registered save handlers => files user sqlite eaccelerator は、files、users、sqlite、などを通じて保存できます。サーバーに memcached がインストールされている場合は、mmcache のオプションもあります。もちろん、MySQL、PostgreSQL など、他にもたくさんあります。どれも良い選択です。
セッション同期
フロントエンドには多数のサーバーがある可能性があります。ユーザーはサーバー A にログインし、セッション情報を設定し、Web サイトのいくつかのページにアクセスしてサーバー B にジャンプする可能性があります。この時点でサーバー B にセッション情報がない場合は、特別な処理を行っても問題が発生する可能性があります。
セッション同期には色々な種類がありますが、memcachedやMySQLに保存する場合は同じ場所に指定するだけで統一して保存できます。
もう 1 つの方法は、暗号化された Cookie を使用することです。ユーザーはサーバー A に正常にログインし、ユーザーがサーバー B にアクセスしたときに、セッションがあるかどうかを確認します。セッションが有効でない場合は、Cookie が有効かどうかを確認してください。有効な場合は、サーバー B でセッションを再確立します。この方法は、Web サイトに多数のサブチャネルがあり、サーバーが同じコンピュータ ルームにない場合に、均一にログインしたい場合に非常に便利です。
もちろん、負荷分散層でセッションを維持し、訪問者を特定のサーバーにバインドする方法もあります。これらはすべて運用および保守レベルで行われます。 。 もの。セッションがシステムのパフォーマンスに影響を与えると誰もが言うからといって、臆病になる必要はありません。攻撃したり隠したりする余裕がない場合は、それが重要です。ここにはふさわしくありません。