ホームページ  >  記事  >  バックエンド開発  >  PHPにおけるCookieとSessionの類似点と相違点の比較分析、cookie_PHPの比較分析チュートリアル

PHPにおけるCookieとSessionの類似点と相違点の比較分析、cookie_PHPの比較分析チュートリアル

WBOY
WBOYオリジナル
2016-07-12 08:58:46747ブラウズ

phpにおけるCookieとセッションの類似点と相違点の比較分析、およびCookieの比較分析

誰もがCookieとセッションをより深く理解し、開発作業での柔軟な使用にインスピレーションをもたらします。

1. クッキーの仕組み

Cookie は、サーバーによってローカル マシンに保存される小さなテキストであり、リクエストごとに同じサーバーに送信されます。 IETF RFC 2965 HTTP 状態管理メカニズムは、一般的な Cookie 仕様です。 Web サーバーは、HTTP ヘッダーを使用してクライアントに Cookie を送信し、ブラウザはこれらの Cookie を解析し、同じサーバーへのリクエストに自動的にバインドします。

具体的には、Cookieの仕組みはクライアント側で状態を保持するソリューションを採用しています。これは、ユーザー側でセッション状態を保存するメカニズムです。ユーザーはクライアント側で Cookie サポートを有効にする必要があります。 Cookie の役割は、HTTP プロトコルのステートレスな欠陥を解決するための取り組みです。
オーソドックスな Cookie の配布は、HTTP プロトコルを拡張することによって実現され、サーバーは HTTP 応答ヘッダーに特別な命令行を追加し、その命令に従って対応する Cookie を生成するようブラウザに指示します。ただし、JavaScript などの純粋なクライアント側スクリプトも Cookie を生成する可能性があります。 Cookie の使用は、特定の原則に従ってブラウザによってバックグラウンドでサーバーに自動的に送信されます。ブラウザは、保存されているすべての Cookie をチェックします。宣言された Cookie のスコープが、要求されるリソースの場所以上である場合、Cookie は要求されたリソースの HTTP 要求ヘッダーに添付され、サーバーに送信されます。

Cookie の内容には主に、名前、値、有効期限、パスドメインが含まれます。パスとドメインを合わせて Cookie のスコープを形成します。有効期限が設定されていない場合、この Cookie の有効期間はブラウザ セッション中にあり、ブラウザ ウィンドウを閉じると Cookie は消えます。ブラウザーのセッション中に保持されるこのタイプの Cookie は、セッション Cookie と呼ばれます。セッション Cookie は通常、ハードディスクではなくメモリに保存されます。もちろん、この動作は仕様で指定されていません。有効期限が設定されている場合、ブラウザは Cookie をハードディスクに保存します。ブラウザを閉じて再度開いた場合でも、設定された有効期限が経過するまでこれらの Cookie は有効です。ハード ドライブに保存された Cookie は、2 つの IE ウィンドウなど、異なるブラウザ プロセス間で共有できます。ブラウザーが異なれば、メモリに保存された Cookie を処理する方法も異なります。

セッションメカニズムは、サーバー側で状態を維持するソリューションを使用します。同時に、サーバー側で状態を維持するソリューションではクライアント側でも ID を保存する必要があるため、セッション メカニズムでは ID を保存するという目的を達成するために Cookie メカニズムを使用する必要があることもわかりました。セッションは、グローバル変数を管理する便利な方法を提供します。

セッションはユーザーごとに保存されます。セッション ID は、クライアントが Cookie を無効にすると、ユーザーのブラウザを通じてサーバーに返されます。 , この値は、get によってサーバーに返されるように設定することもできます。

セキュリティの観点: セッションを使用するサイトにアクセスしてマシン上に Cookie を作成する場合、顧客が保存した情報が勝手に読み取られることがないため、サーバー側のセッション メカニズムをより安全にすることをお勧めします。

2. セッションの仕組み

セッション メカニズムはサーバー側のメカニズムであり、サーバーは情報を保存するためにハッシュ テーブルに似た構造を使用します (またはハッシュ テーブルを使用する場合もあります)。

プログラムがクライアントのリクエストに対してセッションを作成する必要がある場合、サーバーはまずクライアントのリクエストにセッション識別子 (セッション ID と呼ばれます) が含まれているかどうかを確認します。含まれている場合は、そのセッションが以前にこのクライアントに対して作成されたことを意味します。 、サーバーはセッション ID に従ってこのセッションを取得します (取得できない場合は、新しいセッションが作成されます)。クライアントのリクエストにセッション ID が含まれていない場合は、クライアントのセッションが作成され、セッションが関連付けられます。このセッション ID が生成される場合、セッション ID の値は、繰り返されず、模倣するパターンが見つけにくい文字列である必要があります。このセッション ID は、保存のためにこの応答でクライアントに返されます。

Cookie を使用してこのセッション ID を保存できるため、対話プロセス中に、ブラウザーはルールに従ってこの ID をサーバーに自動的に表示できます。通常、この Cookie の名前は SEEESIONID に似ています。ただし、Cookie は人為的に無効にすることができるため、Cookie が無効になっている場合でもセッション ID をサーバーに戻す他のメカニズムが必要です。
頻繁に使用される手法は URL 書き換えと呼ばれ、URL パスの末尾にセッション ID を直接追加します。フォーム隠しフィールドと呼ばれる手法もあります。つまり、サーバーは自動的にフォームを変更し、非表示フィールドを追加して、フォームの送信時にセッション ID をサーバーに返すことができるようにします。

Cookie とセッションは両方ともセッション追跡を実行できますが、完了の原則は異なります。通常は両方でニーズを満たすことができますが、Cookie が使用できない場合や、Session が使用できない場合があります。

以下は両者の特徴と該当する状況の比較です。

1. さまざまなアクセス方法

Cookie は ASCII 文字列のみを保存できます。Unicode 文字またはバイナリ データにアクセスする必要がある場合は、最初にそれらをエンコードする必要があります。 Cookie は Java オブジェクトに直接アクセスできません。もう少し複雑な情報を保存するには、Cookie を使用するのが難しくなります。
セッションは、文字列、整数、リスト、マップなどを含むがこれらに限定されない、あらゆるタイプのデータにアクセスできます。 Java Beans や Java クラス、オブジェクトなども直接セッションに保存できるため、非常に使いやすくなります。セッションは Java コンテナ クラスとみなすことができます。

2. プライバシーポリシーの違い

Cookie はクライアントのブラウザに保存され、クライアントから見えるようになります。クライアント上の一部のプログラムは、Cookie 内のコンテンツをスヌープ、コピー、さらには変更することがあります。セッションはサーバーに保存され、クライアントに対して透過的であるため、機密情報が漏洩するリスクはありません。
Cookie を選択する場合は、アカウントのパスワードなどの機密情報を Cookie に書き込まないようにすることをお勧めします。 Google や Baidu のように Cookie 情報を暗号化し、サーバーに送信した後に復号化して、その人だけが Cookie 内の情報を読み取ることができるようにするのが最善です。 Session を選択すると、サーバー上に配置されるため、Session 内のプライバシーを効果的に保護できます。

3.有効期限の違い

Google を使用したことのある人なら誰でも、Google にログインしていれば、Google ログイン情報は長期間有効であることを知っています。ユーザーはアクセスするたびに再度ログインする必要はなく、Google はユーザーのログイン情報を永続的に記録します。この効果を実現するには、Cookie を使用することをお勧めします。 Cookie の有効期限属性を非常に大きな数値に設定するだけです。

セッションは JSESSIONID という名前の Cookie に依存しており、Cookie JSESSIONID のデフォルトの有効期限は -1 であるため、ブラウザが閉じている限りセッションは無効になるため、セッションは情報の永続的な有効性の効果を実現できません。これは、URL 書き換えを使用して実現することはできません。また、セッション タイムアウトの設定が長すぎると、サーバーに蓄積されるセッションが増えるほど、メモリ オーバーフローが発生しやすくなります。

4. サーバーの圧力の違い

セッションはサーバー側に保存され、各ユーザーがセッションを生成します。同時にアクセスするユーザーが多い場合、大量のセッションが生成され、大量のメモリを消費します。したがって、Google、Baidu、Sina などの同時訪問数が非常に多い Web サイトでは、Session を使用してユーザー セッションを追跡する可能性は低いです。

Cookieはクライアント側に保存され、サーバーのリソースを占有しません。同時に読んでいるユーザーが多い場合は、Cookie が良い選択です。 Google、Baidu、Sina にとっては、Cookie が唯一の選択肢かもしれません。

5. さまざまなブラウザのサポート

Cookie はクライアントのブラウザでサポートされている必要があります。クライアントが Cookie を無効にしている場合、または Cookie をサポートしていない場合、セッション追跡は無効になります。 WAP 上のアプリケーションに関しては、通常の Cookie は役に立ちません。

クライアントのブラウザが Cookie をサポートしていない場合は、セッションと URL アドレスの書き換えを使用する必要があります。セッション プログラムを使用するすべての URL を書き換える必要があることに注意してください。書き換えないと、セッション トラッキングが無効になります。 WAP アプリケーションの場合、セッション + URL アドレスの書き換えが唯一のオプションとなる場合があります。

クライアントが Cookie をサポートしている場合、Cookie はこのブラウザ ウィンドウとサブウィンドウで有効になるように設定できます (有効期限を -1 に設定します)。または、すべてのブラウザ ウィンドウで有効になるように設定できます (有効期限を設定します) 0 より大きい特定の整数まで)。ただし、Session は、このリーダー ウィンドウとそのサブウィンドウ内でのみ有効です。 2 つのブラウザ ウィンドウが互いに独立している場合、それらは 2 つの異なるセッションを使用します。 (セッションはIE8では別のウィンドウに関連しています)

6. クロスドメインサポートの違い

Cookie はクロスドメイン アクセスをサポートします。たとえば、ドメイン属性が「.biaodianfu.com」に設定されている場合、サフィックス「.biaodianfu.com」を持つすべてのドメイン名が Cookie にアクセスできます。クロスドメイン Cookie は現在、Google、Baidu、Sina などのインターネットで一般的に使用されています。セッションはクロスドメイン名アクセスをサポートしません。セッションは、それが存在するドメイン名内でのみ有効です。
Cookie だけを使用したり、Session だけを使用したりすると、期待した効果が得られない場合があります。現時点では、Cookie とセッションを同時に使用するようにしてください。 Cookie とセッションの組み合わせは、実際のプロジェクトにおいて多くの予期せぬ効果をもたらします。

上記はphpにおけるCookieとSessionの違いと比較です。皆様の学習に役立つことを願っています。

興味がありそうな記事:

  • PHPセッションとCookieの使い方
  • 「PHPプログラミングを最速で理解する方法」講義4: 日付、フォーム受信、セッション、Cookie
  • Cookieの使用方法とCookieの詳細な説明PHP5 のセッション
  • PHP のセッションと Cookie を深く理解する
  • PHP でセッションと Cookie を同時に使用してユーザーのログイン情報を保存する方法
  • PHP でセッション値と Cookie を設定する例を学習します
  • PHP のソリューションを考えるCookie が使用できなくなる原因となる Cookie とセッションの競合
  • PHP における Cookie とセッションの違いの分析例
  • PHP セッション制御: セッションと Cookie の詳細な説明
  • PHP で無効なセッションと Cookie の解決策を考える

www.bkjia.com本当http://www.bkjia.com/PHPjc/1101298.html技術記事 PHP における Cookie とセッションの類似点と相違点の比較分析、および Cookie の比較分析は、誰もが Cookie とセッションをより深く理解し、自身の開発作業で柔軟に使用するためのインスピレーションを提供します。 ...
声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。