Cookie とセッションの違いの概要

この記事は Cookie とセッションの違いをまとめたものです。一定の参考価値があります。困っている友人は参考にしてください。お役に立てれば幸いです。

HTTP ステートレス プロトコル

HTTP ステートレス プロトコルは、プロトコルがトランザクション処理のためのメモリ機能を持たないことを意味します。ステータスがないということは、後続の処理で以前の情報が必要な場合にその情報を再送信する必要があることを意味し、その結果、接続ごとに転送されるデータ量が増加する可能性があります。一方、事前の情報が必要ない場合、サーバーはより速く応答します。 はじめにクライアントとサーバー間で動的に対話する Web アプリケーションが出現して以来、

HTTP のステートレスな特性がこれらのアプリケーションの実装を深刻に妨げています

結局のところ、対話は過去を結び付ける必要があります。シンプル ショッピング カート プログラムは、ユーザーが以前にどのような製品を選択したかを知る必要もあります。その結果、HTTP 接続状態を維持するための 2 つのテクノロジが 登場しました。1 つは Cookie、もう 1 つは Session です。 HTTP 自体はステートレスな接続プロトコルです。クライアントとサーバー間の対話をサポートするには、さまざまなテクノロジを使用して対話の状態を保存する必要があります。これらのさまざまなテクノロジとは、Cookie とセッションです。 Cookie は、クライアントを通じて状態を維持するためのソリューションです。定義上、Cookie はサーバーからクライアントに送信される特別な情報であり、この情報は テキスト ファイル の形式でクライアントに保存され、その後、クライアントは

にリクエストを送信します。サーバーに毎回これらの特別なメッセージを届けます。より具体的に言うと、ユーザーがブラウザを使用して Cookie をサポートする Web サイトにアクセスすると、ユーザー名を含む個人情報が提供されてサーバーに送信され、サーバーは対応するハイパーバイザーをクライアントに返します。もちろん、この情報は HTTP レスポンスボディ (Response Body) には格納されませんが、 は、 HTTP 応答ヘッダー (Response Header) ; クライアント ブラウザがサーバーから応答を受信すると、ブラウザはその情報を統一された場所に保存します。 Windows オペレーティング システムの場合、[システム ディスク] から開始できます。 ]:Documents and Settings[ユーザー名] 保存された Cookie は Cookies ディレクトリにあり、それ以降、クライアントがサーバーにリクエストを送信すると、対応する Cookie がサーバーに再度送信されます。今回はHTTPリクエストヘッダ(Request Header)にCookie情報を格納します。 斜体のテキスト

開発

Cookieなどの技術の実装により、サーバーはクライアントのブラウザからリクエストを受信した後、リクエストヘッダに格納されているCookieを解析することでクライアント固有の情報を取得し、クライアントに関する情報を動的に生成することができます。リクエスト クライアントに対応するコンテンツ。通常、多くの Web サイトのログイン インターフェースには「私を覚えておいてください」などのオプションが表示されますが、ログインする前にチェックしておくと、次回 Web サイトにアクセスするときに何度も面倒なログインを行う必要がなくなります。この機能は Cookie を通じて実装されます。

Cookie の反対のソリューションは、サーバーを通じて状態を維持する Session です。セッションという単語には多くの意味が含まれているため、ここでセッションの意味を明確にする必要があります。まず第一に、通常は Session を session に変換します。これにより、クライアント ブラウザとサーバーの間の一連の対話型アクションを Session と呼ぶことができます。このセマンティクスから始めて、セッションの継続時間、セッション中に実行される操作などについて説明します。次に、セッションとは、サーバーによってクライアントのために開かれた記憶域と、そこに保存された情報を指します。ステータスを維持するために。このセマンティクスから始めて、セッションにどのコンテンツを保存するか、キー値に基づいてセッションから一致するコンテンツを取得する方法などについて説明します。
Session を使用するには、もちろん最初のステップはセッションを作成することです。では、セッションはいつ作成されるのでしょうか?もちろん、サーバーサイドのプログラムが実行されている間に作成されますが、言語ごとに実装されたアプリケーションによってセッションの作成方法が異なります。Javaの場合は、HttpServletRequestのgetSessionメソッドを呼び出すことによって作成されます（パラメータにtrueを使用） 。セッションを作成するとき、サーバーはセッションに一意のセッション ID を生成し、このセッション ID は後続のリクエストで作成されたセッションを取り戻すために使用されます。セッションの作成後、セッション関連のメソッドを呼び出すことができ、コンテンツが追加されます。セッションに送信すると、これらのコンテンツはサーバーにのみ保存され、セッション ID のみがクライアントに送信されます。クライアントが再度リクエストを送信すると、このセッション ID が取得され、サーバーは対応するセッションをベースに検索します。セッション ID を確認して再度使用してください。このようなプロセスを経て、ユーザーのステータスは維持されます。
要約すると、HTTP 自体はステートレスな接続プロトコルです。クライアントとサーバー間の対話をサポートするには、さまざまなテクノロジを介して対話の状態を保存する必要があります。これらのさまざまなテクノロジは Cookie です。およびセッションは です。

Cookie

保存場所

Cookieデータはお客様のブラウザに保存され、サーバーはその情報を知ることができます;

利用方法

Ifブラウザ では有効期限が設定されていません 、Cookie は メモリ に保存され、ライフ サイクルは ブラウザが閉じられたとき に終了します。このタイプの Cookie は次のとおりです。セッション Cookie と呼ばれます。

Cookie の有効期限 がブラウザ で設定されている場合、Cookie は ハードディスク に保存されます。ブラウザを閉じた後も、Cookie データは ## まで存在します。 # 有効期限。 を過ぎると消えます。

ストレージ

単一の Cookie

によって保存されるデータは 4KB を超えることはできません。サーバーはクライアント ブラウザに最大 20 Cookie を保存でき、ブラウザは最大 20 Cookie を保存できます。最大 300 個の Cookie を保存します
;Cookie は、テキストの形式で文字列タイプのみを保存できます

アプリケーション シナリオ

Cookie テクノロジには 4 つのコンポーネントがあります。応答レポート 記事に Cookie ヘッダー行がある; HTTP リクエスト メッセージに Cookie ヘッダー行がある; Cookie ファイルはクライアント システムに保持され、ユーザーのブラウザによって管理される; Web にあるバックエンド データベースsite

ユーザーが Web サイトにログインしているかどうかを確認し、次回ログイン時に自動ログイン (またはパスワードを記憶) できるようにします。

Cookie を削除すると、ログインするたびに関連するログイン情報を再度入力する必要があります。

最終ログイン時刻とその他の情報を保存します。最後に表示したページを保存する 閲覧回数アクセス

Cookie に path パラメーターが設定されている場合、同じ Web サイト上の異なるパスにある Cookie は相互にアクセスできません。

欠点

サイズが限られており、ユーザーはCookieを操作(無効化)できるため、機能が制限され、セキュリティが低下し、一部の状態はクライアントに保存できません。アクセスするたびにCookieを送信する必要があります。 Cookie データにはパスの概念があり、Cookie が特定のパスにのみ属するように制限できます。 ＃＃＃＃＃＃他の＃＃＃＃＃＃＃＃＃＃＃＃

データ リクエストの Cookie を運ぶ

Cookie データは、同じオリジンからの http リクエストで常に (必要でない場合でも)、つまり Cookie で運ばれます。ブラウザとサーバーの間でやり取りされます ;
新しいページがリクエストされるたびに Cookie が送信されるため、帯域幅が無駄になります。さらに、Cookie はスコープを指定する必要があり、ドメインをまたいで呼び出すことはできません。

セッション

ストレージの場所

セッション データは サーバーに配置されます。クライアントは情報を知りませんが、セッションは特別な方法 (memcache) で永続的に管理できます。 、redis);

使用法

セッションが作成され、セッションの一貫性の問題が発生した場合

セッションは、一定期間内にサーバーに保存されます。アクセスが増加したときサーバーのパフォーマンスを低下させるには、Cookie を使用する必要があります。
プログラムがクライアントのリクエストに対してセッションを作成する必要がある場合、サーバーは最初に チェックを行います。 client's requestセッション識別子 (セッション ID と呼ばれる) が含まれているかどうか 。含まれている場合は、このクライアントに対して以前にセッションが作成されていることを意味し、サーバーはセッション ID に従ってこのセッションを渡します。 を使用して取得します ( が取得できない場合は、新しい が作成されます)。クライアント リクエストにセッション ID が含まれていない場合は、クライアント用にセッションが作成され、このセッションに関連付けられたセッション ID が生成されます。セッション ID の値は、繰り返しが少なく、偽造するパターンが簡単に見つからない文字列である必要があります。. このセッション IDこの応答で保存するためにクライアントに返されます。このセッション ID を保存する方法には Cookie を使用できるため、対話プロセス中にブラウザーはルールに従ってこの ID をサーバーに自動的に送信できます。 通常は Cookie を使用してセッション ID をクライアントに保存します。対話中に、ブラウザはルールに従ってセッション ID をサーバーに送信します。ユーザーが Cookie を無効にしている場合は、URL の書き換えを使用する必要があります。これは、response.encodeURL(url)

を通じて実現できます。encodeURL の API の最後は、ブラウザーが Cookie をサポートしている場合、URL は何も処理しません。ブラウザがサポートしていない場合 Cookie がサポートされている場合、URL が書き換えられ、SessionID がアクセス アドレスに接続されます。

ストレージ

セッション

サイズ制限なしセッションに保存されるのは
オブジェクトです。セッションはハッシュテーブルに似たデータ構造を通じて保存されます。 、任意のタイプのオブジェクトをサポートできます (セッションには複数のオブジェクトを含めることができます)アプリケーション シナリオ

セッションは、各ユーザーのプライベート情報を保存するために使用されます。変数の値はサーバー側に保存され、さまざまな顧客に保存されます。これらは SessionID によって区別されます。

オンライン モールのショッピング カート
1. ユーザーのログイン情報を保存
2. 同じユーザーの別のページで使用できるように特定のデータをセッションに入力します
ユーザーの不正なログインを防止する
4. アクセス

セッションはパスを区別できません。同じユーザーが Web サイトにアクセスしている間、どこからでもすべてのセッションにアクセスできます。

欠点

セッションで保存するものが増えるほど、より多くのサーバー メモリが占​​有されます。多数のオンライン ユーザーがいる Web サイトの場合、サーバーのメモリ負荷は比較的大きくなり、Cookie ( sessionID は Cookie に保存されます)、Cookie を無効にすると URL 書き換えを使用する必要がありますが、これは安全ではありません。セッション変数の作成は非常に任意であり、いつでも呼び出すことができます。開発者が正確な処理を行う必要はありません。したがって、過剰なセッション変数を使用すると、コードが読み取れなくなり、保守が困難になります。

以上がCookie とセッションの違いの概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。