アプリケーションをステートレスに保つ方法

これは複雑な質問かもしれませんが、私は無国籍の理解を深めようとしています。

私が読んだことに基づいて、Webアプリケーションはステートレスである必要があります。つまり、各リクエストは独立したトランザクションとして扱われます。そのため、セッションとCookieは両方ともステートフルであるため、回避する必要があります。より良い方法はトークンを使用することです。トークンはサーバーに何も保存されないためステートレスです。

だから私は理解しようとしている、私のセッションのために保持されているデータ（ショッピングカートのアイテムなど）があるとき、Webアプリケーションはどのようにステートレスになりますか？これらは実際にどこかにデータベースに保存され、その後定期的にパージされますか？クッキーの代わりにトークンを使用している場合、これはどのように機能しますか？

そして、関連する質問として、主要なWebサイト（Amazon、Google、Facebook、Twitterなど）は実際には無国籍ですか？トークンまたはCookie（または両方）を使用していますか？

「Webアプリケーションはステートレスである必要があります」とは、「Webアプリケーションはステートを持つ非常に正当な理由がない限り、ステートレスであるべきです」と理解する必要があります。「ショッピングカート」は設計上、ステートフルな機能であり、それを否定することは非常に非生産的です。ショッピングカートパターンのポイントは、リクエスト間でアプリケーションの状態を保持することです。

ショッピングカートを実装するステートレスウェブサイトとして私が想像できる代替手段は、ショッピングカートを完全にクライアント側に保ち、AJAX呼び出しで製品情報を取得し、それを一度にサーバーに送信する単一ページのアプリケーションですユーザーがチェックアウトを行います。しかし、ユーザーが複数のブラウザータブを使用することを許可せず、誤ってタブを閉じたときに状態を保持しないため、実際に誰かがそれを行うのを見たことはありません。確かに、localstorageを使用するなどの回避策がありますが、サーバーではなくクライアントだけで状態を再度取得できます。

ページビュー間でデータを保持する必要があるWebアプリケーションがある場合は、通常、セッションを導入することでそれを行います。リクエストが属するセッションは、Cookieまたはすべてのリンクに追加するURLパラメーターによって識別できます。CookieはURLをより便利に保ち、ユーザーがセッションIDを含むURLを誤って共有することを防ぐため、優先されるべきです。しかし、フォールバックとしてURLトークンを持つことは、Cookieを無効にするユーザーにとっても重要です。ほとんどのWeb開発フレームワークには、すぐに使用できるセッション処理システムがあります。

サーバー側では、セッション情報は通常データベースに保存されます。サーバー側のメモリ内キャッシュはオプションです。応答時間を大幅に改善できますが、異なるサーバー間でセッションを転送することはできません。そのため、フォールバックとして永続的なデータベースが必要になります。

主要なWebサイト（Amazon、Google、Facebook、Twitterなど）は実際には無国籍ですか？トークンまたはCookie（または両方）を使用していますか？

ログインできますか？その後、タブを閉じてサイトを再訪しても、まだログインしていますか？もしそうなら、彼らはセッション間であなたのアイデンティティを保持するためにクッキーを使用しています。

Webアプリケーションがステートレスであるべきなのは事実です。ただし、セッション変数、Cookie、およびトークンは、すべてクライアント（Webブラウザー）に保存されている場合、これに違反しません。これらは、リクエスト内のパラメータにすることができます。

簡単なモデルを次に示します。

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

これは、Software Engineering Stack Exchangeで機能します。入力中のこの回答は、Webブラウザの状態の一部です。それが唯一の場所である限り、私以外の誰もアクセスできません。しかしPost your Answer、ブラウザがヒットするとすぐに、Webサーバーに送信します。Webサーバーは、自身の状態を使用せずに投稿を処理します。ブラウザとデータベースから私が誰であるかを学びます。投稿の確認とデータベースへの追加が完了すると、Webサーバーはすぐに自分のことを忘れます。

それがステートレスの意味です。サーバーは、これを記憶する責任はありません。それは仕事ではありません。

これには多くの利点があります。Webサーバーでメモリリークが発生した場合、メモリフットプリントが増大することはないため、検出可能です。Webサーバーがクラッシュした場合、私の身元はそれと一緒に行きません。Webサーバーはセッション間で状態を割り当てないため、サービス拒否攻撃を試みると、Webサーバー状態リソースを使用できません。これはすべて、Webサーバーを安定させることを目的としています。こうすることで、実行を開始すると、実行を継続します。

確かに、データベース内のリソースを消費していますが、これらのリソースは、データベースを野生の羊毛状のWebから保護するために頼ることができる安定したもの、つまり、ステートレスでビジネスルールを適用するWebサーバーによって、最初に許容範囲に対してチェックされています。

Webアプリケーションはステートレスである必要があります

ナンセンス。Web 要求はステートレスである必要があります。より正確には、Webリクエストはステートレスです。

しかし、アプリケーション全体がステートレスであるべきだと言うのは、まったくナンセンスです。

各リクエストは独立したトランザクションとして扱われます。

はい、正確に。またはより正確に、はい、必然的に。HTTPでは、各リクエストは本質的に他のすべてのリクエストから独立しています。HTTPに「ステートフルネス」を追加するには、「ステートフル」リクエストごとに「ステート」を明示的に識別、保存、取得する必要があります。そして、これには手間がかかり、パフォーマンスが低下し、複雑さが増します。

そして、これらの理由により、ステートレスである可能性のある各リクエストはステートレスである必要があります。

そのため、セッションとCookieは両方ともステートフルであるため、回避する必要があります。より良いアプローチは、トークンを使用することです

いくつかのこと：トークンはセッションストレージにも結び付けることができます。Cookie をセッションストレージに関連付ける必要はありません。トークンはしばしばクッキーに保存されます。また、セッションは単に仕事に適したツールであることがあります。

つまり、少なくとも時々、セッションとCookieはトークンと同じくらい「良い」ということです！

サーバーに何も保存されていないため、[トークン]はステートレスです。

まあ、それだけです。それが、「無国籍」という教義の本当の意味です。明確にするために、それはサーバーに「何も」を格納することではなく、サーバーにセッション状態を格納しないことです。

たとえば、Gmailの受信トレイは状態です。そして、サーバーに保存する方が良いでしょう！しかし、それはセッション状態ではありません。

したがって、小さな識別子を取得して自分が誰であるかなどを把握できるサーバーを使用する代わりに、ステートレスアプリケーションは、すべての血なまぐさい要求で自分が誰であり、何をしているのかを思い出させたいと思います。アプリケーションの状態はまだ存在し、クライアントはそれを保持する責任があります。

今、その状態が小さい場合、おそらく大丈夫です。場合によっては非常に良いです。

そして、もちろん、ステートフルになることを単に期待するものがあります...

セッションのために保持されているデータ（ショッピングカート内のアイテムなど）がある場合、Webアプリケーションはどのようにステートレスになりますか？これらは実際にどこかにデータベースに保存され、その後定期的にパージされますか？

2つのオプション。セッションがあるか、拒否されています！

...しかし、真剣に。通常、カートをCookieに保存することはありません。ショッピングカートのようなものは、「従来の」セッションに格納されるCartか、サーバーが後続のリクエストにプルするために使用する何らかのIDを持つオブジェクトとして格納されます。.. uhh ... ... err ... セッションのようなもの。

真剣に言うと、2つの通信エージェントが会話内のメッセージをコンテキスト化できる場合、「ステートフルネス」と呼ばれるものはかなりの程度になります。そして、従来から理解されているセッションは、これが発生するメカニズムと呼ばれるものです。

トークンを使用するか「セッション」を使用するかに関係なく、サーバーが処理するリクエストごとに、リクエストを処理するためにそのリクエストをコンテキスト化する必要があるか、しないかを主張します。コンテキストが不要な場合は、フェッチしないでください。コンテキストが必要な場合は、近くに置いた方が良いでしょう！

そして、関連する質問として、主要なWebサイト（Amazon、Google、Facebook、Twitterなど）は実際には無国籍ですか？トークンまたはCookie（または両方）を使用していますか？

おそらく両方。しかし、一般的に言えば、彼らはまさにあなたがすることをします：彼らは大規模な「セッション」データベースの「状態」レコードを識別するためにクッキーを設定します。

可能であれば、集中ストレージでの不必要な競合を避けるために、基本的なIDクレームを短命の「トークン」に押し込むと思われます。しかし、これらのサービスの多くが「他のすべての場所からログアウトする」ことを許可しているという事実は、トークンを使用している場合、少なくとも半伝統的なセッションモデルによって「サポート」されていることを示す良い指標です。 。

ステートフル性は必ずしも悪いことではありませんが、ステートフルアプリとステートレスアプリの違いを理解する必要があります。つまり、ステートフルアプリは現在のセッションに関する情報を保持しますが、ステートレスアプリは保持しません。ユーザーアカウントの一部として永続的に保存される情報は、セッションに保存される場合とされない場合がありますが、ユーザーアカウントに関連する情報を保存するだけでは、アプリケーションはステートフルになりません。ステートフルネスでは、サーバーが、クライアントブラウザーが維持しているものを超えて、現在のユーザーのセッションに関する情報を維持する必要があります。たとえば、クライアントは認証を行い、JSESSIONID Cookieを受け取り、リクエストごとにサーバーに送信します。サーバーがこのJSESSIONIDに基づいてアプリケーションのセッションスコープにデータの格納を開始すると、ステートフルになります。

無国籍

ステートレスとは、サーバーとクライアントがユーザーセッションに関する現在の情報を保持していないことを意味します。クライアントとサーバーは、何らかの形式のトークンを使用してリクエスト間の認証を提供できますが、他の現在の情報は保存されません。このようなソリューションの一般的な使用例は、ほとんどのユーザー（新しい消費者）が情報を消費するがサイトに戻る情報を生成しないニュースサイトです。このような場合、サイトは現在のユーザーセッションに関する情報を保持する必要はありません。サイトは引き続きCookieを使用してユーザーを識別し、そのユーザーによるサイトの使用に関する情報を保存できますが、記録されたものはすべてトランザクションであるため、ステートレスと見なされる場合があります。たとえば、ユーザーがクリックしたリンク、サーバー。ただし、ユーザーセッションでは維持されません。

サーバーのステートフルネス

サーバーでは、ステートフルアプリが現在のユーザーに関する状態情報を保存します。通常、このアプローチでは、Cookieを使用してユーザーのシステムを識別し、リクエスト間でサーバー上の状態を維持できるようにします。セッションは、アプリケーションのコンテキストに応じて、認証される場合とされない場合があります。ステートフルサーバーアプリには、ユーザー状態情報をサーバーにキャッシュして、検索とページの応答時間を短縮するという利点があります。欠点として、セッションスコープに情報を保存するのは高価であり、規模が大きくなるとリソースを大量に消費します。また、ハッカーがセッションIDをハイジャックしてユーザーセッションを盗むための潜在的な攻撃ベクトルを作成します。ステートフルサーバーアプリには、サーバー障害などの予期しないサービスの中断からユーザーセッションを保護するという課題もあります。

クライアントのステートフルネス

JavaScriptとsessionStorageなどの最新のブラウザーテクノロジーを使用して、アプリケーションはユーザーセッションに関する状態情報をそのユーザーのデバイスに簡単に保存できるようになりました。全体的に、アプリケーションはまだステートフルと見なされる場合がありますが、状態を維持するジョブはクライアントに移動されました。このアプローチは、各ユーザーが実際に自分の状態を維持し、サーバーインフラストラクチャに負担をかけないという点で、サーバー上の状態を維持するよりも（Webアプリのメンテナーにとって）大きな利点があります。Web規模では、そのようなアーキテクチャの選択は、ハードウェアと電力のコストに大きな影響を及ぼします。サーバーの状態を維持するには、文字通り年間数百万ドルの費用がかかります。クライアントの状態を維持するシステムに移行すると、年間数百万ドルを節約できます。

トークンv。クッキー

Cookieは、クライアントデバイス/ブラウザーの識別子として機能します。これらはあらゆるものを保存するために使用できますが、通常はCFMLアプリのCFID / CFTOKENなどの何らかの形式の識別子を保存します。Cookieは、ユーザーのブラウザーに長期間存在するように設定できるため、ブラウザーセッション間でアプリの認証を維持するなどのことが可能になります。Cookieはメモリのみに設定することもできるため、ユーザーがブラウザを閉じると有効期限が切れます。

トークンは一般に、サーバー上で生成され（情報を暗号化するために暗号化を使用）、クライアントに渡され、後続のリクエストでサーバーに返されるユーザーに関するある種の識別情報です。それらは、リクエストとレスポンスのヘッダーで渡される場合があります。これは、単一ページのアプリケーションで一般的なパターンです。理想的には、要求/応答ごとに新しいトークンが生成されるため、攻撃者はトークンを後で傍受して使用することはできません。

単一ページのアプリとクライアントの状態

SPAを使用すると、状態情報がクライアントブラウザーにロードされ、そこで維持されます。ソーシャルメディアアカウントに更新を投稿するなど、状態が変化すると、クライアントはその新しいトランザクションをサーバーに中継します。この場合、サーバーはその更新をデータベースなどの永続データストアに保存し、更新に基づいてサーバーと同期する必要がある情報（更新のIDなど）をクライアントに中継します。

クライアントに状態を保存するこのパターンは、多少使いやすいアプリケーションを持ちながらサーバーから切断できるという点で、オンライン/オフラインエクスペリエンスに利点があることに注意してください。Twitterは、この場合の良い例です。Twitterサーバーアプリから切断されていても、Twitterフィードでクライアント側に読み込まれたものをすべて確認できます。このパターンは、サーバーとクライアント間の同期を複雑にします。これは、それ自体が主題です。ソリューションの複雑さは、クライアントの状態を維持できるためのトレードオフです。

クライアントのステートフル性により、Webアプリは従来のデスクトップアプリのように感じられ、動作します。デスクトップアプリとは異なり、通常、ブラウザのクライアントセッションにアカウント情報のすべてが読み込まれるわけではありません。多くの場合、そうすることは非現実的であり、悪い経験を生みます。Gmailボックス全体をブラウザにロードしようと想像できますか？代わりに、クライアントは、あなたが見ているラベル/フォルダや、見ているそのフォルダ内のメールのリストのどこにいるかなどの情報を保持します。維持する状態情報と必要に応じて要求する状態のバランスを取ることは、このパターンのもう1つのエンジニアリング上の課題であり、これも実用性と優れたユーザーエクスペリエンスの提供とのトレードオフを表しています。

ショッピングカートなど

ショッピングカートのような詳細に関しては、それは本当にソリューションに依存しています。ショッピングカートは、サーバー上のデータベースに保存される場合がありますが、サーバー上のセッションスコープにのみ保存される場合も、クライアントに保存される場合もあります。Amazonには、ログインユーザー用の永続的なショッピングカートと、匿名ユーザー用の「一時的な」カートがありますが、これらのカートはある程度永続的です。

同じブランドの下に実際に存在するさまざまなアプリケーションの集まりであるグーグルのようなものについて話すとき、それらはおそらく共通のアーキテクチャを共有せず、それぞれはユーザーのニーズに最適な方法で構築されます。サイトの構築方法を学びたい場合は、ブラウザーで開発者ツールを開いて見てください。Cookieを確認し、ネットワークトラフィックを監視して、実行方法を確認します。

この回答が少し乱雑な場合は申し訳ありませんが、ステートフルネスは複雑なテーマです。

セッションとCookieを回避する必要はありません。ステートレスWebアプリケーションでも引き続き使用できます。

JavaとRuby on Railsには大きな違いがあります。Javaアプリは、Cookieに保存されたセッションキーを使用してメモリにセッションを保存します。これにより、ユーザーの状態とショッピングカートをすばやく取得できます。ただし、セッションで常に同じサーバーにアクセスする必要があります。

Railsアプリは、署名され暗号化されたCookieにユーザーIDを保存します。改ざんすることはできません。ページを読み込むと、Webアプリはデータベースから状態、ユーザー、ショッピングカートを取得します。これは遅くなりますが、重要なことは、どのインスタンスにもヒットできることです！これにより、インスタンスを自由に再起動、スケーリング、シャットダウンできます。とても便利。また、Redisなどの共有メモリ内キャッシュデータベースを使用して高速化することもできます。または、十分に小さい場合は、ショッピングカートをCookieに保存できます。

そのため、巧妙な手法を使用してステートレスを実現し、自由にスケーリングする機能を追加できます。

プロトコルはステートレスです。

しかし、そのことから、プロトコルを使用するアプリケーションはステートレスである必要があるとは限りません。

以下に、違いをうまく説明する関連するStackOverflowの回答をいくつか示します。

• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34678600#34678600
• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34677668#34677668

RESTful HTTPサービスなどのステートレスを参照する場合、サーバー側での状態の保存を回避しようとしています。せいぜい、バックエンドのデータベースまたはその他の永続的なストレージに状態を保存することも含めます。それを明確にするために、私は一般的にデータではなく状態について話しています。何人かの男が物事を混乱させているようです。

ステートレス通信には、特にスケーラビリティと可用性に関していくつかの利点があります。

より良い方法はトークンを使用することです。トークンはサーバーに何も保存されないためステートレスです。

それは事実です（特定の認証および承認プロトコルの場合）。トークンは、それ自体ではなく、ユーザーの認証またはアクションの承認に必要なリクエスト内のすべての情報を提供できます。例として、JWTを見てください。

だから私は理解しようとしている、私のセッションのために保持されているデータ（ショッピングカートのアイテムなど）があるとき、Webアプリケーションはどのようにステートレスになりますか？これらは実際にどこかにデータベースに保存され、その後定期的にパージされますか？クッキーの代わりにトークンを使用している場合、これはどのように機能しますか？

ショッピングカートの例について。セッションまたはCookieを使用せずに、すべてのカートアイテムをクライアント側に保存しても問題ありません。smashingmagazine.comで例を見つけることができます。ただし、Cookieを使用してステートレスなショッピングカートを実現することもできます（少なくとも品揃えがそれほど大きくなく、4kbのストレージで十分な場合）。

誤解しないでください。これは、価格にかかわらずステートレスなショッピングカートを実装する必要があるという意味ではありません。Amazonや他の大手オンラインショッピングプラットフォームでは、ステートフルなショッピングカートの実装が使用されています。なぜなら、拡張性などの技術的な非機能要件を満たすよりも、ユーザーエクスペリエンスと使いやすさが重要だからです。

通常、トークンはカートのアイテムなどの情報を保存するために使用されません。これらは、ステートレス認証および承認に使用されます。

そして、関連する質問として、主要なWebサイト（Amazon、Google、Facebook、Twitterなど）は実際には無国籍ですか？トークンまたはCookie（または両方）を使用していますか？

認証にCookieまたはトークンを使用しているかどうかを尋ねている場合、答えは両方を使用していることです。ほとんどの場合、技術的なクライアント用のCookieを使用するユーザーの場合、トークンが使用されます。

OK、引用するルールは技術的に間違っています。Webアプリケーションのすべてのレイヤーには状態があります。

ルールの目的は、「セッションごとの状態サーバー側を保持しない」です。

つまり、ASPのセッション変数は、バスケット/ユーザー名などのアイテムのようなことを行うために一般的に使用されていました。

その理由は、アプリケーションがより多くのユーザーを獲得すると、サーバー上のメモリが不足するためです。ストレージをデータベースまたは共有キャッシュに移動しても、まだボトルネックがあるため問題は解決しません。

この問題を発生させずにユーザーごとのアプリケーションの状態を維持するには、状態をクライアント側に移動します。たとえば、バスケットアイテムをCookieまたはより高度なクライアント側ストレージに入れます。

クライアントの数はユーザーの数に比例するため、アプリケーション全体にボトルネックはなく、適切に拡張できます。