1. クッキー
1. クッキーとは何ですか?
1. Cookie は実際には小さなテキスト情報です。key=value形式の文字列です。クライアントはサーバーを要求し、サーバーがユーザーのステータスを記録する必要がある場合、その応答を使用してクライアントのブラウザーに Cookie を発行します。クライアントは Cookie を保存します。
2. ブラウザが Web サイトを再度リクエストすると、ブラウザはリクエストされた URL を Cookie とともにサーバーに送信します。サーバーは Cookie をチェックしてユーザーのステータスを識別します。サーバーは必要に応じて Cookie の内容を変更することもできます。
3.Cookie はユーザーの ID のみを保存します文字列の文字列で表されるユーザー ID など、サーバーはセッションを通じてユーザー情報を保存し、ユーザー ID を使用して対応するユーザー情報を検索します。
4. Cookie は、クライアント (ブラウザ) がデータを保存するためのメカニズムです。キーと値のペア構造には、プログラマがカスタマイズした ID 情報とキー情報を保存できます。5. Cookie はブラウザによって提供されるタイプです
。プログラマーがデータをローカルに保存できるため、クライアント側でのデータの永続性が高まります。
2. セッションCookieとパーシステントCookie
1. セッション Cookie (メモリ Cookie) :
有効期限が設定されていない場合、Cookie の有効期間はブラウザ セッション中であることを意味し、ブラウザ ウィンドウを閉じると Cookie は消えます。ブラウザーのセッションを存続期間とするこの種の Cookie は、セッション Cookie と呼ばれます。セッション Cookie は通常、ハードディスクには保存されず、メモリに保存されますが、もちろん、この動作は仕様で指定されていません。
2.永続 Cookie (ハードディスク Cookie) :
有効期限が設定されている場合、ブラウザは Cookie をハードディスクに保存します。ブラウザを閉じて再度開いても、これらの Cookie は設定された有効期限を超えるまで有効です。 。ハード ドライブに保存された Cookie は、異なるブラウザ プロセス間で共有できます。これらは永続的な Cookie と呼ばれます。
3. Cookie はドメイン名を越えることはできません
Bilibili にアクセスしたときに生成される Cookie は、CSDN の Cookie には反映されません。
4. Cookie の仕組み
ブラウザに保存される Cookie は、サーバーの応答「ヘッダー」の set-cookie フィールドから取得されます。各 set-cookie フィールドには、Cookie などのキーと値のペアが含まれます。ブラウザは応答を取得した後、コンテンツをset-cookie はローカルに設定され、set-cookie はプログラマ自身によってサーバー内で構築および入力されます。
注:
1. Cookie の変更と削除
- Cookie を変更する場合は、変更の目的を達成するために、同じ名前の Cookie を使用して元の Cookie を上書きする必要があります。
- Cookie を変更または削除する場合、名前、パス、ドメインなど、value と maxAge を除く、新しく作成された Cookie のすべての属性が元の Cookie とまったく同じである必要があります。そうしないと、ブラウザはそれを 2 つの異なる Cookie とみなし、上書きしないため、変更や削除ができなくなります。
- クライアントから Cookie を読み取る場合、maxAge を含む他の属性は読み取ることができないため、送信されません。ブラウザが Cookie を送信するときは、name 属性と value 属性のみが送信されます。maxAge 属性は、Cookie の有効期限が切れているかどうかを判断するためにブラウザによってのみ使用されます。
2. ドメイン名の設定
- ドメイン パラメータはドット (「.」) で始める必要があります。また、名前が同じでドメインが異なる Cookie は、2 つの異なる Cookie になります。まったく異なるドメイン名を持つ 2 つの Web サイトで Cookie を共有したい場合は、ドメイン属性が 2 つのドメイン名である 2 つの Cookie を生成し、クライアントに出力できます。
3. Cookie へのアクセスを許可するパスを設定します。
- 「/」に設定すると、すべてのパスで Cookie の使用が許可されます。path 属性は記号「/」で終わる必要があります。
4. Cookie のセキュリティ属性を構成する
- secure 属性は Cookie の内容を暗号化しないため、絶対的なセキュリティは保証できません。高いセキュリティが必要な場合は、Cookie の内容をプログラム内で暗号化および復号化して漏洩を防ぐ必要があります。
- HTTP などの安全でないプロトコルで Cookie を送信したくない場合は、Cookie の secure 属性を true に設定できます。ブラウザは、そのような Cookie を HTTPS や SSL などの安全なプロトコルでのみ送信します。
二、Session
1.セッションとは
1. セッションは顧客のステータスを記録するためのもう 1 つのメカニズムですが、違いは次のとおりです。Cookieはクライアントのブラウザに保存されます，そしてセッションはサーバーに保存されます。クライアントのブラウザがサーバーにアクセスすると、サーバーはクライアントの情報をセッションとしてサーバーに記録します。
2. セッションはサーバー側で実行され、クライアントが初めてサーバーにアクセスするときにユーザーのログイン情報を保存し、ユーザーが他のインターフェイスにアクセスするときに、セッションを使用してユーザーのログイン状態を判断し、促す。
3. セッションはサーバーがデータを保存するメカニズムであり、主にキーと値のペア構造が使用されます。アイデンティティ関連情報を保存する。
2. セッションの動作原理
Session が getSession() または getSession(true) を呼び出すと、最下層は自動的に Set-Cookie メソッドを実装します。つまり、
セッションは JSESSIONID を保存するための Cookie を生成します。
[getSession() または getSession(true) は key=value クッキーのキーと値のペアを返します]
注意：
1、getSession(Boolean)
- パラメーターが true の場合、リクエストに SessionId があるかどうか、および SessionId が正当であるかどうかがチェックされます。
1. SessionId がある場合、SessionId に従って対応する HttpServlet オブジェクトを見つけ (ハッシュ テーブルを確認します)、サーバー側でハッシュ テーブルの形式で複数のセッションを編成します; 2. SessionId がない場合、サーバーは
SessionId を生成し、同時に HttpServlet オブジェクトを作成し、このキーと値のペアのセットをサーバーが管理するセッションのハッシュ テーブルに挿入します。Set-cookie を介して応答で sessionId をクライアントに返します。- パラメーターが false の場合、リクエストに SessionId があるかどうか、およびそれが正当であるかどうかもチェックされます。SessionId がある場合は、対応する HttpServlet オブジェクトを直接見つけて、情報のあらゆる側面をクエリします。SessionId がない場合、直接返される値は null です
2.セッションIDの保存方法
- 1. Cookie を使用して保存 (デフォルトのメカニズム); 2. URL 書き換え; 3. フォームの隠しフィールド
3. セッションのライフサイクルと有効期間の設定
- セッションはサーバー側に保存されます。アクセス速度を高めるために、サーバーは通常、セッションをメモリに置きます。各ユーザーは独立したセッションを持ちます。セッションの内容が複雑すぎると、多数のクライアントがサーバーにアクセスしたときにメモリ オーバーフローが発生する可能性があります。したがって、セッション内の情報はできる限り簡潔にする必要があります。
- サーバーにアクセスするユーザーが増えるにつれて、セッションも増えます。メモリのオーバーフローを防ぐために、サーバーは長期間アクティブでなかったセッションをメモリから削除します。今回はセッションタイムアウトです。タイムアウト期間が経過してもサーバーにアクセスされなかった場合、セッションは自動的に期限切れになります。
- 注: <session-timeout> パラメータの単位は分ですが、setMaxInactiveInterval(int s) の単位は秒です。
疑問：SessionとCookieの関係について
回答：Cookieはクライアント側に保存されており、Session自体を呼び出す際にCookieが使用されます（動作原理）。
3. Cookieとセッションの違い
1. Cookie データはクライアントのブラウザに保存され、セッション データはサーバーに保存されます。
2. Cookie は安全性が低く、ローカルに保存された Cookie を他人が解析して Cookie のなりすましを行う可能性があるため、セキュリティを考慮するとセッションを使用する必要があります。
3. セッションは一定期間内にサーバーに保存されます。アクセス数が増加するとサーバーのパフォーマンスを圧迫しますので、サーバーパフォーマンスの低下を考慮してCookieを使用する必要があります。
4. 1 つの Cookie によって保存されるデータは 4K を超えることはできず、多くのブラウザでは、サイトで保存できる Cookie は 20 個までに制限されています。
5. ログイン情報などの重要な情報はセッションとして保存することを検討できますが、その他の情報を保持する必要がある場合は、Cookie に保存することができます。
3. レディス
1.Redisとは何ですか
Redis (Remote Dictionary Server)、つまりリモート辞書サービスは、ANSI C 言語で書かれたオープンソースで、ネットワークをサポートし、メモリベースまたは永続的なログタイプの Key-Value データベースであり、複数の API を提供します。言語。
2. Redis を使用する理由 (Session を Redis と組み合わせて使用する理由)
実際のプロジェクトでは、特定のサーバーへの過剰な負荷を防ぎ、システムのパフォーマンスの問題やダウンタイムを回避するために、複数のサーバーにデプロイする必要があります。
例1. 例 (セッションと Cookie のみを使用)
ログイン システムの場合、ユーザーは主に nginx プロキシ サーバー リクエスト システムにアクセスします。
ユーザーの最初のリクエストがサーバー A に割り当てられている場合、作成された Session オブジェクトは A のメモリ内にあり、ユーザーに返される Cookie は JSESSIONID=abc123 です。ユーザーが 2 回目に Cookie を使用してセッションを見つけるようリクエストするときは、 abc123 の値です。再度実行する必要はありません。 ログインしましたが、2 番目のリクエストはサーバー B に割り当てられ、B のメモリに abc123 がありません。リクエストは失敗し、ユーザーはパスワードを再度入力する必要があります。ログインするのに時間がかかり、ユーザーエクスペリエンスは非常に悪いです。
例2. 例えば（redisを利用してセッション共有を実現する場合）
redisに参加した後、ユーザーが初めてリクエストしたセッションはRedisに保存され、2回目のリクエストがサーバーBに届いても、対応するセッションはredisから見つけることができます。
PS: Redisは各サーバーを置き換えるだけでセッションを保存して共有を実現しているような気がします。
Session を Redis と組み合わせて使用する必要がある理由
- データ分散保存
セッションデータはメモリ上に保存されるため、複数のWebサーバーで構成されるクラスタがある場合、セッションデータが各サーバーに分散してしまい、セッションデータを共有できなくなります。Redis の主な機能は分散データ ストレージをサポートすることなので、この問題を解決し、複数の Web サーバーでセッション データを共有できます。- 高性能
Redis は、大量の読み取りおよび書き込みリクエストを処理できる高性能のインメモリ データベースであり、セッション データの読み取りおよび書き込み速度が大幅に向上し、Web アプリケーションのパフォーマンスが向上します。- 永続ストレージのサポート
Redis は、サーバーのダウンタイムやシャットダウンによってセッション データが失われないように、ディスクへのデータの永続化をサポートしています。このようにして、ユーザー データのセキュリティと信頼性を最大限に保証できます。- 高い同時実行性のサポート
Redis の高い同時実行パフォーマンスにより、多数のユーザーが Web アプリケーションに同時にアクセスできるようになり、同時ユーザー数の処理能力が向上し、Web アプリケーションのボトルネックのリスクが軽減されます。- 強力なスケーラビリティ
Redis は豊富なデータ構造と機能をサポートしており、必要に応じてセッション管理機能を拡張およびカスタマイズできるため、セッション管理がより柔軟かつ効率的になります。
3. 簡単な拡張
3.1 キャッシュペネトレーションとは何ですか? の解き方？
キャッシュとデータベースの両方を指しますデータなしこれにより、すべてのリクエストがデータベースに送信されます。短期間に大量のリクエストが発生したため、データベースが崩壊しました。
解決策:
1. キャッシュまたはデータベースから取得できないデータは key-null に設定できます。2.
ブルーム フィルターは、すべての可能なデータをハッシュします。大きなビットマップに移動します (存在すると言われても信じられませんが、実際には存在しない可能性がありますが、存在しないと言われるのであれば、存在しないはずです)
3.2 キャッシュの内訳とは何ですか? の解き方？
同じデータが高い同時実行性でクエリされますが、redis 内のデータの有効期限が切れています。その結果、リクエストがデータベースに送信され、キャッシュの故障が発生します。
解決策:
1. ホットスポット データを期限切れにしないように設定します。2
. ミューテックスを使用します。分散ケースで分散ロックを使用する
3.3 キャッシュアバランシェとは何ですか? の解き方？
広い領域で同時にキャッシュに障害が発生すると、後続のリクエストがデータベースに送信され、データベースが短期間に大量のデータ リクエストを処理することになります。解決策: キャッシュされたデータの有効期限はランダムに設定され
ます
。大量のデータが同時に期限切れになるのを防ぐため。
3.4 Redis クエリはなぜ速いのですか?
Redis はシングルスレッド プログラムですが、純粋なメモリ データベースであるため、メモリのみを操作し (mysql はハードディスク操作です)、非同期ノンブロッキング IO (シングル スレッド + 多重化 IO モデル) を使用します。
3.5 多重化 IO とは何ですか?
リクエストが redis にアクセスする場合、redis がこのリクエストのデータをフェッチしている間、リクエストのエントリはブロックされません。つまり、redis がデータをフェッチしてからこれらに応答するまで、リクエストは引き続き受信できます。一つずつリクエストします。
多重化: 複数のソケット接続、多重化: 1 つのスレッドの多重化
マルチ I/O 多重化テクノロジーにより、単一のスレッドで複数の接続要求を効率的に処理できます (ネットワーク IO の時間消費を最小限に抑えます)。
3.6 シングルスレッドのクエリ速度が非常に速いのはなぜですか?
まず、シングル スレッドがマルチスレッドよりも高速であることは確かに不可能ですが、シングル スレッド モードではデータの同時実行セキュリティが回避されます (マルチスレッドのデータ同時実行セキュリティにより、さまざまなロックが発生します)。このとき、単一スレッドの利点が生まれます。データの同時実行性のセキュリティを考慮する必要がなく、頻繁なスレッドのスケジューリングやコンテキストの切り替えも必要ありません。
3.7 コンテキストとは何ですか?
スレッドが実行されるたびに、メイン メモリから作業メモリにデータを読み取る必要があります。スレッドがブロックされている場合, 作業メモリ内のデータをスレッド コンテキストに入れる必要があります. 実際, スレッド コンテキストはストレージ構造です. スレッドが起動されると, スレッドはコンテキストの内容を読み取ります, これは と呼ばれますコンテキストの切り替え。
3.8 メインメモリとワーキングメモリとは何ですか?
メイン メモリ(メイン メモリ) は、コンピュータ内のデータの保存とアクセスに使用されるハードウェア デバイスで、通常はランダム アクセス メモリ (RAM) を指します。これはコンピュータの起動時にアクティブ化され、コンピュータがシャットダウンされるまで実行されます。メイン メモリは通常、プログラムとデータが保存される場所であるため、プログラム レベル メモリ (プログラマブル メモリ) とも呼ばれます。メイン メモリでは、データはそれぞれ固有のアドレスを持つメモリ セルに保存されます。
作業メモリ(Working Memory) は通常、スレッド (Thread) の実行によって使用されるキャッシュ領域を指し、スレッドのローカル メモリ (Thread Local Memory) とも呼ばれます。各スレッドには独自のワーキングメモリがあり、スレッドのワーキングメモリにはスレッド専用の変数コピー（Copy）が格納されており、ワーキングメモリ内の変数コピーは操作後にメインメモリに書き戻されます。共有データは複数のスレッド間でアクセスできます。スレッドが共有変数にアクセスしたい場合、まず変数をメイン メモリから独自の作業メモリにコピーし、次に変数を操作し、最後に変数の値を書き戻します。メインメモリに保存されます。
複数のスレッドはそれぞれの作業メモリに格納されているデータを見ることができず、これらのデータはそれぞれの作業メモリとメイン メモリの間でのみ転送されることに注意してください。したがって、スレッド間のデータの一貫性を確保するために、Java は synchronized キーワードや Lock インターフェースなどのいくつかの同期メカニズムを提供します。スレッドが共有データにアクセスする必要がある場合、他のスレッドが一時的にアクセスできないようにするために、最初にロックを取得する必要があります。続行する前にデータを変更してください。これらの同期メカニズムにより、複数のスレッド間でのデータの可視性と一貫性が確保され、同時アクセス時のデータ競合やエラーが回避されます。
read (read): メインメモリ変数に作用し、メインメモリからスレッドのワーキングメモリに変数値を転送します。そのため、後続のロードアクションは、
load (load): ワークメモリの変数に作用し、それを使用します。読み取り操作を転送します。メインメモリから取得した変数値は、作業メモリ内の変数コピーに配置されます。
use (use): 作業メモリに作用し、作業メモリ内の変数値を実行エンジンに渡す変数。この操作は、仮想マシンが変数の値を使用する必要があるバイトコード命令に遭遇するたびに実行されます。 。
Assign (割り当て): 作業メモリの変数に作用し、実行エンジンから受け取った値を作業メモリの変数に割り当てます。また、仮想マシンが変数に値を割り当てるバイトコード命令を検出するたびにこの操作を実行します。 。
store (ストレージ): 作業メモリの変数に作用し、後続の書き込み操作のために作業メモリ内の変数の値をメイン メモリに転送します。
write (書き込み): メイン メモリ内の変数に作用し、作業メモリ内の変数の値からメイン メモリ内の変数にストア操作を転送します。
=====================================
この記事は以下の記事を参照しており、その説明はさらに詳しくなります。詳細:
Cookieとセッションの違いCookieとセッション（面接時に必要
）
【nodejs勉強記】ユーザーログイン関連： Cookie、セッションの使い方とメリット・デメリットredis
、Redis詳細解説（全編）Redis詳細解説