Cookieとセッションの
HTTPプロトコルはステートレスプロトコルです。つまり、サーバーがクライアントからリクエストを受信するたびに、それは新しいリクエストであり、サーバーはクライアントの履歴リクエストレコードを知りません。セッションとCookieの主な目的は、 HTTPのステートレスな性質。
セッションは、
クライアントがサーバーに要求するものです。サーバーは、この要求のためのメモリ空間を開きます。このオブジェクトはセッションオブジェクトであり、ストレージ構造はConcurrentHashMapです。セッションはHTTPのステートレスな性質を補うものであり、サーバーはセッションを使用して、同じセッション中のクライアントの操作レコードを保存できます。
セッションは、同じセッション
サーバーが初めてリクエストを受信したかどうかを判断し、セッションスペースを開き（Sessionオブジェクトを作成）、同時にsessionIdを生成し、Set-Cookie：JSESSIONID = XXXXXXXコマンドを応答ヘッダーを通じてクライアントに送信する方法Cookieの設定を要求する応答を送信します。応答を受信した後、クライアントはローカルクライアントでJSESSIONID = XXXXXXXの Cookieメッセージを設定し、Cookieの有効期限はブラウザセッションの終了です。
次に、クライアントが同じWebサイトにリクエストを送信するたびに、リクエストヘッダーがcookie情報（sessionIdを含む）を送信し、サーバーはリクエストヘッダーのcookie情報を読み取り、JSESSIONIDという名前の値を取得します。リクエストされたセッションID。
セッションの短所セッションメカニズムには短所があります。たとえば、Aサーバーはセッションを保存します。つまり、負荷分散後、Aのアクセス量が一定期間急増した場合、アクセスのためにBに転送されますが、BサーバーはAのセッションを保存しません。セッションの失敗につながります。
Cookieとは何ですか？
HTTPプロトコルのCookieには、Web CookieとブラウザーCookieが含まれ、サーバーからWebブラウザーに送信される小さなデータです。サーバーからブラウザに送信されたCookieは、ブラウザに保存され、次のリクエストとともにサーバーに送信されます。通常は、2つのリクエストが同じブラウザからのものかどうか、たとえばユーザーがログインしたままかどうかを判断するために使用されます。
HTTP Cookieメカニズムは、ステートレスHTTPプロトコルの補足および改善です。
クッキーは主に次の3つの目的で使用されます
セッション管理
ログイン、ショッピングカート、ゲームのスコア、またはサーバーが覚えておくべきその他のこと
ユーザー設定、テーマ、その他の設定をパーソナライズ
記録を追跡し、ユーザーの行動を分析する
Cookieはかつて一般的なクライアントストレージに使用されていました。クライアントにデータを保存する唯一の方法であるため、これは合法ですが、現在は最新のストレージAPIを使用することが推奨されています。Cookieはリクエストごとに送信されるため、パフォーマンスが低下する可能性があります（特にモバイルデータ接続の場合）。
Cookieの作成
サーバーは、クライアントからHTTPリクエストを受信すると、Set-Cookieヘッダーを応答とともに送信できます。通常、Cookieはブラウザーによって保存され、HTTPヘッダーと共にサーバーに送信されます。
Set-CookieおよびCookieヘッダー
Set-Cookie HTTP応答ヘッダーは、サーバーからユーザーエージェントにCookieを送信します。Cookieを送信する例を以下に示します
このヘッダーは、Cookieを保存するようにクライアントに指示します
これで、サーバーへの新しいリクエストごとに、ブラウザーはCookieヘッダーを使用して、以前に保存されたすべてのCookieをサーバーに送り返します。
Cookieには、セッションCookieと永続Cookieの2種類があります。Cookieに有効期限が含まれていない場合、セッションCookieと見なされます。セッションCookieはメモリに保存され、ディスクに書き込まれることはありません。ブラウザを閉じると、Cookieは永久に失われます。Cookieに有効期限が含まれている場合、永続的なCookieと見なされます。Cookieは、有効期限で指定された日付にディスクから削除されます。
CookieにはSecureタグとHttpOnlyタグもあり、これらは以下の順序で導入されます
セッションCookie
上記の例では、セッションCookieが作成されます。セッションCookieには特性があります。Cookieは、ExpiresまたはMax-Age命令を指定していないため、クライアントが閉じられると削除されます。
ただし、Webブラウザーはセッションの復元を使用する場合があります。これにより、ブラウザーが閉じられなかったかのように、ほとんどのセッションCookieが永続的に保持されます。
永続的なCookie
永続的なCookieは、クライアントが閉じたときに期限切れにならず、特定の日付（Expires）または特定の期間（Max-Age）で期限切れになります。たとえば、Set-Cookie：id = a3fWa; Expires = Wed、21 Oct 2015 07:28:00 GMT; Cookie Secure
のコードをコピーし、
HttpOnlyマーク付きの
安全なCookieを暗号化してHTTPSプロトコル経由でサーバーに送信する必要があります。安全であっても、機密情報は本質的に安全ではなく、このフラグは実際の保護を提供しないため、Cookieに保存しないでください。
HttpOnlyの役割
セッションCookieにHttpOnly属性がないと、***がプログラム（JSスクリプト、アプレットなど）を介してユーザーのCookie情報を取得するため、ユーザーのCookie情報が漏洩し、クロスサイトスクリプティングの***脅威が増大します。
HttpOnlyは、MicrosoftがCookieに対して作成した拡張機能です。この値は、クライアントスクリプトを介してCookieにアクセスできるかどうかを指定します。
CookieでHttpOnly属性がtrueに設定されていない場合、Cookieが盗まれる可能性があります。盗まれたCookieには、ASP.NETセッションIDやフォーム認証チケットなど、サイトのユーザーを識別する機密情報が含まれている可能性があります。等 Cookie
の
ドメインおよびパス識別子は、Cookieのスコープ、つまりCookieの送信先のURLを定義します。
ドメインIDは、Cookieを受け入れることができるホストを指定します。指定しない場合、デフォルトは現在のホスト（サブドメインなし）です。ドメインが指定されている場合、通常はサブドメイン名が含まれています。
たとえば、Domain = mozilla.orgと設定した場合、Cookieはサブドメイン（developer.mozilla.orgなど）にも含まれます。
たとえば、
Path = / docs を設定すると、次のアドレスが一致します。
/ docs
/ docs / Web /
/ docs / Web /
JSON WebトークンとセッションCookieのHTTP 比較
JSON Webトークン（JWTと略される）とセッションの両方がWebサイトのユーザー認証を提供できますが、同じものではありません。
以下は、JWTとセッションの違いの研究です。
JWTとセッションCookieの類似点JWTとセッションCookieについて説明する前に、それらの類似点を理解する必要があります。
これらは、ユーザーの認証に使用できます。また、別のページをクリックしたとき、およびWebサイトやアプリケーションにログインした後のユーザーの認証にも使用できます。
両方がない場合は、ページを切り替えるたびにログインする必要があります。HTTPはステートレスプロトコルだからです。つまり、Webページにアクセスしてから同じサイトの別のページをクリックすると、サーバーのメモリには以前の操作が記憶されません。
したがって、ログインしてアクセス権のある別のページにアクセスすると、HTTPはログインしたばかりの情報を記録しないため、再度ログインします。
JWTとセッションCookieは、異なるページ間の切り替えを処理し、ユーザーのログイン情報を保存するために使用されるメカニズムです。
つまり、これら2つのテクノロジーを使用してログインステータスを保存し、パスワードで保護されたWebサイトを閲覧できるようにします。この問題は、新しいリクエストが生成されるたびにユーザーデータを認証することで解決されます。
では、JWTとセッションCookieの類似点は何ですか？つまり、異なるリクエストを送信する間のログインステータスを記録および確認するためのサポートを提供できます。
セッションCookieとはセッションCookieは
セッションCookieとも呼ばれ、ユーザーのログインステータスはサーバーのメモリに保存されます。ユーザーがログインすると、サーバーによってセッションが安全に作成されます。
サーバーは、リクエストごとにセッションCookieからSessionIdを読み取ります。サーバー側のデータと読み取られたSessionIdが同じ場合、サーバーはブラウザに応答を送信し、ユーザーがログインできるようにします。Json Web Token 
とは何ですか？
Json Web Tokenの略称はJWTで、通常Jsonトークンと呼ばれます。これは、Jsonオブジェクトとして情報を安全に送信するためにRFC 7519で定義された形式です。JWTに格納されている情報はデジタル署名されているため、信頼して理解することができます。JWTは、HMACアルゴリズムまたはRSA / ECDSA公開鍵/秘密鍵を使用して署名できます。
JWTの使用は、主に次の2つの点で使用されます。
認証（承認）：これはJWTを使用する最も一般的なケースです。ユーザーがログインすると、後続の各リクエストにはJWTが含まれ、ユーザーはトークンで許可されたルート、サービス、リソースにアクセスできます。シングルサインオンは、オーバーヘッドが低いため、今日広く使用されているJWTの機能です。
情報交換：JWTは情報を安全に転送する方法です。公開鍵と秘密鍵を使用して、JWTに署名して認証します。さらに、署名はヘッドとペイロードを使用して計算されるため、コンテンツが改ざんされていないかどうかも確認できます。
JWTフォーマット
以下では、JWTの構成とフォーマットについて説明します。
JWTは主に3つの部分で構成され、各部分は分割されています。
ヘッダー
ペイロードの
署名
したがって、非常に単純なJWT構成は次のようになります。
次に、異なる部分について個別に説明します。
ヘッダ
ヘッダーはJWTのヘッダーであり、通常は2つの部分で構成されます。トークンのタイプ（つまり、JWT）と、HMAC SHA256やRSAなどの使用される署名アルゴリズムです。
たとえば
{
"alg"： "HS256"、
"typ"： "JWT"
}
コードをコピーし
てタイプと署名アルゴリズムを指定した後、JsonブロックはBase64Urlによってエンコードされ、JWTの最初の部分を形成します。
ペイロード
トークンの2番目の部分は、ステートメントを含むペイロードです。ステートメントは、エンティティ（通常はユーザー）およびその他のデータに関するステートメントです。宣言には、登録済み、パブリック、プライベートの3つのタイプがあります。
登録済みステートメント：推奨される事前定義済みステートメントのセットが含まれ、主に
ISS発行者iss（発行者）発行者exp（有効期限）有効期限サブ（件名）サブジェクトaud（聴衆）聴衆nbf（Not Before）有効時間iat（発行時刻）発行時刻jti（JWT ID）番号
パブリックステートメント：パブリックステートメント。任意の情報を追加できます。通常、ユーザー関連情報やその他のビジネスに必要な情報を追加できますが、機密情報を追加することはお勧めしません。この部分はクライアントで解読できるためです。
プライベートステートメント：登録ステートメントやパブリックステートメントではなく、それらを使用することに同意した当事者間で情報を共有するように設計されたカスタムステートメント。
たとえば
{
"sub"： "1234567890"、
"name"： "John Doe"、
"admin"：true
}
コード
をコピーし、ペイロードJsonブロックをBase64UrlエンコードしてJWTの2番目の部分を形成します。
署名
JWTの3番目の部分はビザ情報で、3つの部分で構成されています
ヘッダー（base64以降）
ペイロード（base64以降）
シークレットたとえば
、署名するにはHMAC SHA256アルゴリズムが必要です
HMACSHA256（
base64UrlEncode（header）+ "。" +
Base64UrlEncode（payload）、
secret）
コード
署名をコピーして、このプロセスでメッセージが変更されていないことを確認し、秘密鍵で署名されたトークンについては、JWTの送信も確認できます真のアイデンティティ
すべてをまとめる次に
、ドットで区切られた3つのBase64-URL文字列部分をまとめてみましょうこの文字列は、HTMLおよびHTTP環境でこれらの文字列を簡単に渡すことができます。
これは、ヘッダーとペイロードをエンコードし、署名を使用して署名する完全なJWTの例です
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQは、
コードをコピーし
、あなた自身のテストを書きたいならば、あなたは公式サイトjwt.io/#debugger-i ... JWTを訪問することができます
JWTとセッションCookieの違いJWTとセッションCookieはどちらも安全なユーザー認証を提供しますが、次の違いがあります。
暗号署名
JWTには暗号化された署名がありますが、セッションCookieにはありません。
JSONはステートレスです。
宣言はサーバーのメモリではなくクライアントに格納されるため、JWTはステートレスです。
認証は、リクエストがサーバーデータベースまたは同様の場所を経由する必要がある場合ではなく、ローカルで実行できます。これは、サイトやアプリケーションのデータベースと通信する必要がなく、プロセスで多くのリソースを消費することなく、ユーザーを複数回認証できることを意味します。
スケーラビリティ
セッションCookieはサーバーメモリに保存されます。つまり、Webサイトまたはアプリケーションが非常に大きい場合、多くのリソースを消費します。JWTはステートレスであるため、多くの場合、サーバーリソースを節約できます。したがって、JWTはセッションCookieよりもスケーラブルです。
JWTはクロスドメイン認証をサポートしています
セッションCookieは、単一ノードのドメインまたはそのサブドメインでのみ使用できます。3番目のノードを介してアクセスしようとすると、アクセスが禁止されます。あなたのサイトが他のサイトとの安全な接続を確立したい場合、これは問題です。
JWTを使用すると、この問題を解決できます。JWTを使用すると、複数のノードを介してユーザー認証を実行できます。これは、クロスドメイン認証と呼ばれます。
JWTとセッションCookieの選択
上記でJWTとCookieの違いについて説明しましたが、一般的に言えば、選択についてより深く理解できると思います。
ユーザーのログインとサイトデータベースに保存されている一部の情報へのアクセスのみが必要な中小規模のWebサイトの場合、通常はセッションCookieで十分です。
エンタープライズレベルのサイト、アプリケーション、または近くのサイトがあり、多数のリクエスト、特にサードパーティまたは多数のサードパーティ（異なるドメインにあるAPIを含む）を処理する必要がある場合は、JWTの方が明らかに適しています。
ポストスクリプト
は2日前のインタビュー中にこの質問をしたので、要約する記事を書き、インタビューの質問、Cookieの無効化、セッションの使用方法を尋ねました。Baiduをオンラインで確認したところ、これがPHPのインタビューの質問であることがわかりました...
しかし、それでも、Cookieを無効にする方法、セッション
Cookieが無効になっている場合でも、サーバーはsessionIdをCookieとしてブラウザーに送信しますが、ブラウザーはこのCookie（つまり、sessionId）を保存しなくなります。
セッションを継続して使用する場合は、URL書き換えを使用して達成する必要があります。www.cnblogs.com/ Renyi-Fan / p ...を参照してください。
関連参照：
www.cnblogs.com/Renyi-Fan/p…
blog.csdn.net/qq_28296925…
www.cnblogs.com/-ROCKS/p/61…
www.allaboutcookies.org/manage-cook…
www.jianshu.com/p/4a124a10f…
tools.ietf.org/html/rfc751…
jwt.io/introductio…
wp-rocket.me/blog/browse…
wp-rocket.me/blog/differ…