PHP セッションと cookie_PHP チュートリアル
- WBOYオリジナル
- 2016-07-14 10:10:151056ブラウズ
PHP セッションの原則
Session はユーザーのセッションデータをサーバー側で保持するためのメソッドであり、対応する Cookie はクライアント側でユーザーのデータを保持するためのものです。 HTTP プロトコルはステートレス プロトコルであり、サーバーが応答すると、ブラウザーに Cookie が導入され、ページ間でデータが交換されます。
まず、クライアントとサーバーは 1 対 1 の関係を確立し、サーバーがクライアントを識別できるようにします。一意の識別には、Cookie または GET で指定する 2 つの方法を使用することをお勧めします。 PHP のデフォルト設定では、セッションの使用時に「PHPSESSID」という名前の Cookie が作成されます (php.ini の session.name 値を変更することで指定できます)。クライアントが Cookie を無効にしている場合は、セッション ID を渡すように指定することもできます。サーバー経由 (php.ini の session.use_trans_sid などのパラメーターを変更)。
クライアントはセッション ID をサーバーに渡し、サーバーは読み取り時にセッション ID に基づいて対応するファイルを見つけます。保存時には、ファイルの内容がシリアル化されてから書き込まれます。
これは事実です。サーバーがセッションをサポートしていない場合、またはセッションをカスタマイズしたい場合は、PHP の uniqid を使用して重複しないセッション ID を生成し、セッションのコンテンツを保存する場所を見つけることができます。セッションを MySQL データベースに保存することもできます。
いわゆるセッションは、実際にはクライアント側のセッションIDとサーバー側のセッションファイルです。新しいセッションを作成するときに、サーバーにCookieを生成してセッションファイルを準備するように指示します。そうしないと、セッションのコンテンツはどうなりますか。セッションを読み取るときに、セッション ID に基づいてセッション ファイルを迅速に逆シリアル化するようにサーバーに指示します。
セッションはシステムパフォーマンスに影響します
トラフィック量が多い Web サイトでは、セッションがシステムのパフォーマンスに影響します。パフォーマンスに影響を与える理由の 1 つは、同じディレクトリに 10,000 個を超えるファイルがある場合、ファイルの配置に非常に時間がかかります。セッションディレクトリのハッシュ化。php.ini で session.save_path = "2;/path/to/session/dir" を変更すると、セッションは 2 レベルのサブディレクトリに保存され、各ディレクトリには 16 個のサブディレクトリ [0~f] が含まれます。 , しかし、PHPsessionはディレクトリの作成をサポートしていないようです。事前にそれらのディレクトリを作成する必要があります。
もう 1 つの問題は、小さなファイルの効率です。一般的に、セッション データはそれほど大きくありません (1 ～ 2K)。 memcache および mysql データベースをキャッシュすることで効率が向上します。
セッション同期
フロントエンドには多数のサーバーがある可能性があります。ユーザーはサーバー A にログインし、セッション情報を設定し、Web サイトのいくつかのページにアクセスしてサーバー B にジャンプする可能性があります。この時点でサーバー B にセッション情報がない場合は、特別な加工は行っておりませんが、加工すると不具合が発生する可能性がございます。
セッション同期には色々な種類がありますが、memcachedやMySQLに保存する場合は同じ場所に指定するだけで統一して保存できます。
(NFS は、Network File System、つまり、Network File System の略語です。Network File System は、FreeBSD によってサポートされるファイル システムの 1 つで、NFS とも呼ばれます。NFS を使用すると、システムはネットワーク上の他のユーザーとディレクトリやファイルを共有できます。 NFS を使用すると、ユーザーとプログラムはリモート システム上のファイルにローカル ファイルであるかのようにアクセスできます
もう 1 つの方法は、暗号化された Cookie を使用することです。ユーザーはサーバー A に正常にログインし、ユーザーがサーバー B にアクセスしたときに、セッションがあるかどうかを確認します。セッションが有効でない場合は、Cookie が有効かどうかを確認してください。有効な場合は、サーバー B でセッションを再確立します。この方法は、Web サイトに多数のサブチャネルがあり、サーバーが同じコンピュータ ルームにない場合に、均一にログインしたい場合に非常に便利です。
もちろん、負荷分散層でセッションを維持し、訪問者を特定のサーバーにバインドする方法もあります。訪問者はすべてそのサーバー上で行われ、セッションの同期は必要ありません。
session_start();
if(isset($_SESSION['test_sess'])){
$_SESSION['test_sess']++;
}その他{
$_SESSION['test_sess'] = 0;
}
echo$_SESSION['test_sess'];
?>;
サーバーへの最初のリクエスト:
GET/test.php HTTP/1.1
受け入れる:*/*
リファラー:http://localhost/
受け入れ言語:zh-cn
Accept-Encoding:gzip、deflate
ユーザーエージェント: Mozilla/4.0 (互換性; MSIE6.0; Windows NT 5.1; SV1; Maxthon; .NET CLR 1.1.4322)
ホスト:ローカルホスト
接続:キープアライブ
サーバーが初めて戻ります:
HTTP/1.1200 OK
日付:2005 年 8 月 26 日金曜日 07:44:22 GMT
サーバー:Apache/2.0.54 (Win32) SVN/1.2.1 PHP/5.0.4 DAV/2
X-Powered-By:PHP/5.0.4
Set-Cookie:PHPSESSID=bmmc3mfc94ncdr15ujitjogma3; パス=/
有効期限: 1981 年 11 月 19 日木曜日 08:52:00 GMT
キャッシュ制御: no-store、no-cache、must-revalidate、post-check=0、pre-check=0
プラグマ:キャッシュなし
コンテンツの長さ:1
キープアライブ:タイムアウト=15、最大=99
接続:キープアライブ
コンテンツタイプ: text/html;
コンテンツ言語:オフサーバーへの 2 番目のリクエスト:
GET/test.php HTTP/1.1
受け入れる:*/*
リファラー:http://localhost/
受け入れ言語:zh-cn
Accept-Encoding:gzip、deflate
ユーザーエージェント: Mozilla/4.0 (互換性; MSIE6.0; Windows NT 5.1; SV1; Maxthon; .NET CLR 1.1.4322)
ホスト:ローカルホスト
接続:キープアライブ
クッキー: PHPSESSID=bmmc3mfc94ncdr15ujitjogma3
サーバーが 2 回目に戻ります:
HTTP/1.1200OK
日付:2005 年 8 月 26 日金曜日 07:44:23 GMT
サーバー:Apache/2.0.54 (Win32) SVN/1.2.1 PHP/5.0.4 DAV/2
X-Powered-By:PHP/5.0.4
Set-Cookie:PHPSESSID=bmmc3mfc94ncdr15ujitjogma3; パス=/
有効期限: 1981 年 11 月 19 日木曜日 08:52:00 GMT
キャッシュ制御: no-store、no-cache、must-revalidate、post-check=0、pre-check=0
プラグマ:キャッシュなし
コンテンツの長さ:1
キープアライブ:タイムアウト=15、最大=98
接続:キープアライブ
コンテンツタイプ: charset=utf-8
コンテンツ言語:オフ
これらの出力を注意深く比較すると、2 番目のリクエストには最初のリクエストよりも多くの出力が含まれています。
Cookie:PHPSESSID=bmmc3mfc94ncdr15ujitjogma3
このヘッダーは Cookie 情報をサーバーに送信し、PHPSESSID という名前の Cookie があり、その内容が bmmc3mfc94ncdr15ujitjogma3 であることをサーバーに伝えます。
このクッキーはどこから来たのですか?初めてサーバーから返された情報を見てください:
Set-Cookie:PHPSESSID=bmmc3mfc94ncdr15ujitjogma3; パス=/
これは、クライアントのブラウザに Cookie を書き込むサーバーです。名前は PHPSESSID で、値は実際にはいわゆる session_id です。
引き続きサーバーへの 2 番目のリクエストを確認すると、Cookie PHPSESSID が依然としてサーバーに送信されています
次の結論が導き出されます:
1. セッションが使用されている限り、セッションは Cookie を通じてクライアントのブラウザーに送信されます。
2. サーバーにリクエストが行われるたびに、ローカルブラウザはリクエスト情報にCookieを添付しますクッキー
Cookie は、ユーザーを追跡および識別するためにリモート ブラウザーにデータを保存するメカニズムです。
PHP は http プロトコルのヘッダー情報で Cookie を送信するため、他の情報がブラウザーに出力される前に setcookie() 関数を呼び出す必要があります。
原則
a. サーバーは、応答とともに http Set-Cookie ヘッダーを送信することで、クライアントに Cookie を設定します (複数の Cookie には複数のヘッダーが必要です)。
b. クライアントは自動的に http Cookie ヘッダーをサーバーに送信し、サーバーはそれを受信して読み取ります。
HTTP/1.x 200 OK
X-Powered-By: PHP/5.2.1
Set-Cookie:TestCookie=どこかからのパス=/
有効期限: 2007 年 11 月 19 日(木) 18:52:00 GMT
キャッシュ制御: no-store、no-cache、must-revalidate、post-check=0、pre-check=0
プラグマ: キャッシュなし
コンテンツタイプ: text/html
この行を受け取った後、Cookie機能を実装します
Set-Cookie: TestCookie=どこかからの何かのパス=/
ブラウザはクライアントのディスク上に Cookie ファイルを作成します。
以下も同じ効果:
setcookie('TestCookie','どこかからの何か','/');
header('Set-Cookie:TestCookie=どこかからのもの; path=/')
よくある質問の解決策:
1) setcookie() を使用するとエラー メッセージが表示されます。 setcookie() を呼び出す前に出力またはスペースがあることが原因である可能性があります。
2) $_COOKIE は、magic_quotes_gpc の影響を受け、自動的にエスケープされる可能性があります。
3) 使用する場合、ユーザーがCookieをサポートしているかどうかをテストする必要があります。
以下では、セッションとCookieを分析する例としてユーザーログインを使用します
HTTP プロトコルはステートレス プロトコルです。サーバーがユーザーのリクエストに応答すると、PHP はどのようにしてセッションを実装しますか。
ユーザーが初めてサーバーにアクセスする場合、セッション情報がないため、ユーザーはフォームを通じてユーザー名、パスワード、確認コードなどの情報をサーバーに送信し、サーバーは確認する前にデータを前処理します。ユーザーの正当性。データベースでの検証後、ユーザーは正当であることがわかり、サーバーは Set-Cookie: PHPSESSID=bmmc3mfc94ncdr15ujitjogma3; を含む情報をブラウザーに提供し、ブラウザーはその情報をローカル ファイルに書き込みます (PHPSESSID は一意です)。識別子。同時に、サーバーはシリアル化されたセッション情報を指定されたファイルに保存します。ユーザーが再度リクエストすると、ブラウザは対応する Cookie 内の PHPSESSID をサーバーに送信し、サーバーは PHPSESSID を取得し、セッション ファイル内で検証します。検証が成功すると、直接ログインします。このようにして、異なるユーザー ページ間で同様の方法でデータを渡すことができます。セッション内の値はキーと値です。
セッションはシステムパフォーマンスに影響します
トラフィック量が多い Web サイトでは、セッションがシステムのパフォーマンスに影響します。パフォーマンスに影響を与える理由の 1 つは、同じディレクトリに 10,000 個を超えるファイルがある場合、ファイルの配置に非常に時間がかかります。セッションディレクトリのハッシュ化。php.ini で session.save_path = "2;/path/to/session/dir" を変更すると、セッションは 2 レベルのサブディレクトリに保存され、各ディレクトリには 16 個のサブディレクトリ [0~f] が含まれます。 , しかし、PHPsessionはディレクトリの作成をサポートしていないようです。事前にそれらのディレクトリを作成する必要があります。
もう 1 つの問題は、小さなファイルの効率です。一般的に、セッション データはそれほど大きくありません (1 ～ 2K)。 memcache および mysql データベースをキャッシュすることで効率が向上します。
セッション同期
フロントエンドには多数のサーバーがある可能性があります。ユーザーはサーバー A にログインし、セッション情報を設定し、Web サイトのいくつかのページにアクセスしてサーバー B にジャンプする可能性があります。この時点でサーバー B にセッション情報がない場合は、特別な加工は行っておりませんが、加工すると不具合が発生する可能性がございます。
セッション同期には色々な種類がありますが、memcachedやMySQLに保存する場合は同じ場所に指定するだけで統一して保存できます。
(NFS は、Network File System、つまり、Network File System の略語です。Network File System は、FreeBSD によってサポートされるファイル システムの 1 つで、NFS とも呼ばれます。NFS を使用すると、システムはネットワーク上の他のユーザーとディレクトリやファイルを共有できます。 NFS を使用すると、ユーザーとプログラムはリモート システム上のファイルにローカル ファイルであるかのようにアクセスできます
もう 1 つの方法は、暗号化された Cookie を使用することです。ユーザーはサーバー A に正常にログインし、ユーザーがサーバー B にアクセスしたときに、セッションがあるかどうかを確認します。セッションが有効でない場合は、Cookie が有効かどうかを確認してください。有効な場合は、サーバー B でセッションを再確立します。この方法は、Web サイトに多数のサブチャネルがあり、サーバーが同じコンピュータ ルームにない場合に、均一にログインしたい場合に非常に便利です。
もう 1 つの方法は、負荷分散層でセッションを維持し、訪問者を特定のサーバーにバインドすることです。他のすべての訪問がそのサーバー上にある必要はありません。