So halten Sie Anwendungen zustandslos

97

Dies mag eine verwickelte Frage sein, aber ich versuche, die Staatenlosigkeit besser zu verstehen.

Basierend auf dem, was ich gelesen habe, sollten Webanwendungen statusfrei sein, was bedeutet, dass jede Anfrage als unabhängige Transaktion behandelt wird. Aus diesem Grund sollten Sitzung und Cookies vermieden werden (da beide zustandsbehaftet sind). Ein besserer Ansatz ist die Verwendung von Tokens, die zustandslos sind, da auf dem Server nichts gespeichert ist.

Ich versuche zu verstehen, wie Webanwendungen statusfrei sein können, wenn Daten für meine Sitzung gespeichert werden (z. B. Artikel in einem Warenkorb). Werden diese tatsächlich irgendwo in einer Datenbank gespeichert und dann regelmäßig gelöscht? Wie funktioniert das, wenn Sie ein Token anstelle von Cookies verwenden?

Und sind die wichtigsten Websites (Amazon, Google, Facebook, Twitter usw.) tatsächlich zustandslos? Verwenden sie Token oder Cookies (oder beides)?


quelle
38
Ich habe in letzter Zeit Entwickler gesehen und mit ihnen gesprochen, die bis zur Ablenkung von Staatenlosigkeit besessen sind. Es ist schön, Staatenlosigkeit für die Wiederverwendbarkeit zu haben, aber es ist nicht realistisch, dieses Ziel in jeder Situation über jedes andere Ziel zu verfolgen, es sei denn, Sie haben eine Menge Ressourcen, um dies aus irgendeinem Grund zu tun, wie z. B. Skalieren.
Mark Rogers
4
@MarkRogers Warum? Staatenlosigkeit hat nichts mit Wiederverwendbarkeit zu tun. Und staatenlos zu sein, führt nicht zu einem höheren Aufwand.
Paul Wasilewski
3
@PaulWasilewski: Und Staatenlosigkeit führt nicht zu einem höheren Aufwand. => Mit einer statusbehafteten Anwendung behalten Sie alles im Speicher, was an die Sitzung gebunden ist. Dies lässt sich nicht gut skalieren, funktioniert jedoch mit Sitzungs-Pinning, ist aber SEHR einfach. Wenn Server beginnen müssen, Informationen untereinander auszutauschen, treten Probleme auf.
Matthieu M.
6
Wenn Sie Amazon ansehen, werden Sie feststellen, dass Ihr Warenkorb auch dann erhalten bleibt, wenn Sie den Computer wechseln, sodass er nicht in einem Cookie, sondern in einer Datenbank gespeichert wird.
njzk2
20
Wenn Sie meine Antwort nicht lesen können. Hier ist die Kurzversion: Webanforderungen sind von Natur aus zustandslos. Web - Anwendungen nicht. (Egal was einige "staatenlose Web" Dogmatiker Ihnen
sagen

Antworten:

95

"Webanwendungen sollten statusfrei sein" sollte als "Webanwendungen sollten statusfrei sein, es sei denn, es gibt einen sehr guten Grund, einen Status zu haben" verstanden werden . Ein "Einkaufswagen" ist von Natur aus ein zustandsbehaftetes Merkmal, und das zu leugnen ist ziemlich kontraproduktiv. Der springende Punkt des Warenkorbmusters besteht darin, den Status der Anwendung zwischen den Anforderungen beizubehalten.

Eine Alternative, die ich mir als zustandslose Website vorstellen könnte , die einen Warenkorb implementiert, wäre eine einseitige Anwendung, die den Warenkorb vollständig clientseitig verwaltet, Produktinformationen mit AJAX-Aufrufen abruft und diese dann auf einmal an den Server sendet Der Benutzer führt einen Checkout durch. Ich bezweifle jedoch, dass ich jemals jemanden gesehen habe, der dies tatsächlich tut, da der Benutzer nicht mehrere Browser-Registerkarten verwenden kann und den Status nicht beibehält, wenn er die Registerkarte versehentlich schließt. Sicher, es gibt Workarounds wie die Verwendung von localstorage, aber dann haben Sie wieder state, nur auf dem Client statt auf dem Server.

Wenn Sie eine Webanwendung haben, bei der Daten zwischen Seitenaufrufen beibehalten werden müssen, führen Sie normalerweise Sitzungen ein. Die Sitzung, zu der eine Anfrage gehört, kann entweder durch ein Cookie oder durch einen URL-Parameter identifiziert werden, den Sie jedem Link hinzufügen. Cookies sollten bevorzugt werden, da sie Ihre URLs handlicher halten und verhindern, dass Ihr Benutzer versehentlich eine URL mit der darin enthaltenen Sitzungs-ID weitergibt. Das Vorhandensein von URL-Tokens als Fallback ist jedoch auch für Benutzer von entscheidender Bedeutung, die Cookies deaktivieren. Die meisten Webentwicklungs-Frameworks verfügen über ein Session-Handling-System, das dies sofort erledigt.

Auf der Serverseite werden Sitzungsinformationen normalerweise in einer Datenbank gespeichert. Server-seitiges In-Memory-Caching ist optional. Die Reaktionszeit kann erheblich verkürzt werden, Sie können jedoch keine Sitzungen zwischen verschiedenen Servern übertragen. Sie benötigen also eine persistente Datenbank als Fallback.

Sind die wichtigsten Websites (Amazon, Google, Facebook, Twitter usw.) tatsächlich zustandslos? Verwenden sie Token oder Cookies (oder beides)?

Erlauben sie dir, dich einzuloggen? Wenn Sie dann die Registerkarte schließen und die Site erneut besuchen, sind Sie immer noch angemeldet? In diesem Fall verwenden sie Cookies, um Ihre Identität zwischen den Sitzungen zu wahren.

Philipp
quelle
46
Ich denke, eine der Verwirrungen hier ist die Unterscheidung zwischen einer "Webanwendung" im weiteren Sinne des Benutzers und einer "Webanwendung" im engeren Sinne des "Codes, der auf dem Webserver ausgeführt wird". Es wird oft behauptet, dass der letztere staatenlos ist, nicht der erstere. Wie Sie sagen, macht es keinen Sinn, dass erstere im Allgemeinen staatenlos sind, da der Zustand normalerweise Teil der Geschäftslogik ist. Statuslos zu sein bedeutet lediglich, dass der Status auf dem Client oder dem Datenbankserver oder beiden und nicht auf dem Webserver gespeichert werden muss.
Derek Elkins
16
"[...] aber dann hast du wieder state, nur auf dem client statt auf dem server." Es geht darum, auf der Serverseite keinen Status zu haben, um eine bessere Skalierbarkeit und Verfügbarkeit zu erreichen. Ob ein Status auf der Client-Seite gespeichert ist, spielt keine Rolle.
Paul Wasilewski
5
@ njzk2 kannst du das so ausarbeiten, dass das nicht absurd klingt? Benutzer gehen nicht zu Amazon, um mehr Namen zu kaufen. Und nachdem sie eingekauft haben, verschwindet etwas , das nur während des Einkaufs existierte. Wenn das etwas nicht "der Stand der Anwendung" ist, was ist es dann? Wenn Anwendungen keinen Status haben, welchen haben sie?
3
@nocomprende: Ich denke, das Wichtigste bei njzk2 ist, dass der Inhalt Ihres Einkaufswagens wie Ihr vollständiger Name Daten sind, die eine Webanwendung auf der Serverseite beibehält. Wenn Leute sagen, "Webapps sollten zustandslos sein", meinen sie normalerweise etwas anderes als "Webapps sollten nicht auf eine Datenbank zugreifen, die Ihren vollständigen Namen enthält, der Ihrem Benutzernamen zugeordnet ist". Genau das, was sie tun durch „stateless“ bedeutet vielleicht nicht trivial definiert ist, da , wenn Sie diese Datenbank haben es alle Arten von Unsinn , dass du da drin bestehen könnte, zu übermäßig komplexen App - Status zu unterstützen, sollte aber nicht ;-)
Steve Jessop
4
@nocomprende: Entschlüsseln Sie ein Ei, indem Sie die Datenbank zurücksetzen: Da unsere Webapp zustandslos ist, kann sie wie zuvor fortgesetzt werden ;-)
Steve Jessop
56

Es ist wahr, dass Webanwendungen statusfrei sein sollten. Sitzungsvariablen, Cookies und Token verletzen dies jedoch nicht, wenn sie alle auf dem Client (Webbrowser) gespeichert sind. Sie können Parameter in der Anfrage sein.

Hier ist ein vereinfachtes Modell:

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

Dies könnte für Software Engineering Stack Exchange funktionieren . Diese Antwort, die ich schreibe, ist Teil des Status meines Webbrowsers. Solange das der einzige Ort ist, an dem es ist, ist es niemandem außer mir zugänglich. Sobald ich aber Post your Answerdrücke, schickt mein Browser es an den Webserver. Der Webserver verarbeitet den Beitrag ohne eigenen Status. Es erfährt von meinem Browser und aus der Datenbank, wer ich bin. Sobald mein Beitrag überprüft und zur Datenbank hinzugefügt wurde, vergisst der Webserver umgehend, dass ich angemeldet bin.

Das bedeutet Staatenlos. Der Server ist nicht dafür verantwortlich, sich daran zu erinnern. Das ist nicht seine Aufgabe.

Dies zu tun hat viele Vorteile. Wenn auf dem Webserver ein Speicherverlust auftritt, ist dies erkennbar, da der Speicherbedarf nicht zunehmen sollte. Wenn der Webserver abstürzt, passt meine Identität nicht dazu. Wenn jemand versucht, einen Denial-of-Service-Angriff durchzuführen, kann er keine Ressourcen für den Webserverstatus verwenden, da der Webserver zwischen den Sitzungen keinen Status für ihn zuweist. Dies alles zielt darauf ab, den Webserver stabil zu machen. Auf diese Weise läuft es weiter, wenn es anfängt zu laufen.

Sicher, ich verbrauche Ressourcen in der Datenbank, aber diese Ressourcen wurden zuerst durch etwas Stabiles, auf das wir uns verlassen können, um die Datenbank vor dem wilden und wolligen Web zu schützen, auf dem zustandslosen, die Geschäftsregeln erzwingenden Webserver, auf meine Zulässigkeit überprüft.

kandierte_orange
quelle
8
Ich weiß nicht ... Diese Antwort klingt ein bisschen so, als würde man sagen: " Excel speichert Ihre Kalkulationstabelle nicht, das Laufwerk schon!" Ha ha, ist die Datenbank für die meisten Leute nicht Teil des Webservers? Offensichtlich ist der Status nicht in der CPU oder im Code des Servers gespeichert, und es ist ziemlich albern, alles im Speicher zu belassen.
7
@nocomprende Nein, die Datenbank ist normalerweise nicht Teil Ihres Webservers. Ja, das Speichern des Status in einer Datenbank schränkt möglicherweise die Skalierbarkeit der gesamten Anwendung ein, aber es gibt relativ wenige Anwendungen, die den gesamten Status (oder sogar den gesamten Status "pro Benutzer") auf den Client übertragen können. Datenbankserver sind speziell für die skalierbare Verarbeitung des Status konzipiert und, wie CandiedOrange erwähnt, in der Regel besser geschützt, bereitgestellt und überprüft als Webserver. Die einfache Skalierung von Webservern bietet Vorteile, auch wenn dadurch nicht alle Skalierbarkeitsprobleme gelöst werden.
Derek Elkins
9
@nocomprende: Der Punkt, der besagt, dass die Datenbank nicht Teil des Webservers ist, ist, dass Sie eine einzelne Datenbank (oder einen Datenbankcluster) für 1, 2, 3, ... Webserver haben können. So soll Staatenlosigkeit die Skalierbarkeit erhöhen: Sie können den Datenbankcluster und die Anzahl der Webserver unabhängig voneinander skalieren.
Matthieu M.
6
"Es ist wahr, dass Webanwendungen zustandslos sein sollten." Nein, das ist völliger Unsinn.
Svidgen
4
Diese Antwort gefällt mir am besten, weil sie die Verwendung von "zustandslos" in Web-Entwicklern am besten veranschaulicht. Der Server behält den Status zwischen Anforderungen nicht bei. Der gesamte Status muss vom Client (dh einem Teil der Anforderung) oder aus der Datenbank (wahrscheinlich basierend auf der Anforderung) stammen. Abgesehen davon gibt es in der Webanwendung häufig einen Status (z. B. statische Instanzen von Inhalten), aber im Allgemeinen möchten Sie Dinge so gestalten, dass sie statusfrei sind. Diese Antwort scheint besser zu sein als die akzeptierte, um die Idee der Staatenlosigkeit am besten zu erklären.
Kat
30

Webanwendungen sollten statusfrei sein

Unsinn. Web - Anfragen sollten staatenlos sein. Oder genauer gesagt, Web - Anfragen sind staatenlos.

Aber zu sagen, dass eine ganze Anwendung zustandslos sein sollte, ist völliger Unsinn.

Jede Anfrage wird als unabhängige Transaktion behandelt.

Ja, genau . Oder genauer gesagt, ja, unbedingt . Über HTTP ist jede Anforderung von Natur aus unabhängig von allen anderen Anforderungen. Zum Hinzufügen von "statefulness" zu HTTP müssen Sie "state" für jede "stateful" -Anforderung explizit identifizieren, speichern und abrufen. Das kostet Mühe, verringert die Leistung und erhöht die Komplexität.

Und aus diesen Gründen sollte jede Anfrage, die zustandslos sein kann , zustandslos sein.

Aus diesem Grund sollten Sitzung und Cookies vermieden werden (da beide zustandsbehaftet sind). Ein besserer Ansatz ist die Verwendung von Tokens

Ein paar Dinge: Tokens können auch an den Sitzungsspeicher gebunden werden. Cookies nicht brauchen , um Sitzungsspeicher gebunden werden. Tokens werden oft in Cookies gespeichert. Und manchmal ist eine Sitzung einfach das richtige Werkzeug für den Job.

Das bedeutet, dass Sitzungen und Cookies zumindest manchmal genauso "besser" sind wie Token!

[Tokens] sind zustandslos, da auf dem Server nichts gespeichert ist.

Das war's. Darum geht es im Dogma der Staatenlosigkeit wirklich. Es geht jedoch nicht darum, "nichts" auf dem Server zu speichern, sondern darum, den Sitzungsstatus nicht auf dem Server zu speichern .

Mein Google Mail-Posteingang befindet sich beispielsweise in einem Status. Und es ist verdammt noch mal besser , auf dem Server gespeichert zu werden! Es ist jedoch kein Sitzungsstatus .

Anstatt einen Server zu haben, der eine kleine Kennung hat und herausfindet, wer Sie sind und so weiter, möchten zustandslose Anwendungen bei jeder verdammten Anfrage daran erinnert werden, wer Sie sind und was Sie tun . Der Anwendungsstatus ist noch vorhanden, der Client ist nur dafür verantwortlich, ihn zu behalten.

Wenn dieser Zustand klein ist, ist das wahrscheinlich in Ordnung. In einigen Fällen ist es sehr gut.

Und dann gibt es natürlich Dinge, von denen wir einfach erwarten, dass sie zustandsmäßig sind ...

Wie können Webanwendungen statusfrei sein, wenn Daten für meine Sitzung gespeichert werden (z. B. Artikel in einem Warenkorb)? Werden diese tatsächlich irgendwo in einer Datenbank gespeichert und dann regelmäßig gelöscht?

Zwei Optionen. Entweder haben Sie eine Sitzung oder Sie sind in Ablehnung!

... Aber ernsthaft. Normalerweise würden Sie einen Einkaufswagen nicht in einem Cookie speichern. So etwas wie ein Einkaufswagen wird entweder in einer "herkömmlichen" Sitzung oder als CartObjekt mit einer ID gespeichert , mit der der Server ihn für nachfolgende Anforderungen abruft. Irgendwie wie eine ... äh ... ähm ... Sitzung.

Im Ernst: In hohem Maße ist "Statefulness" genau das, was wir nennen, wenn zwei Kommunikationsagenten Nachrichten in einem Gespräch kontextualisieren können. Und eine Sitzung, die traditionell verstanden wird, ist genau das, was wir normalerweise den Mechanismus nennen, durch den dies geschieht.

Ich würde argumentieren, dass Sie, unabhängig davon, ob Sie Token oder "Sitzungen" verwenden, für jede Anforderung, die Ihr Server verarbeitet, diese Anforderung entweder kontextualisieren müssen, um sie zu erfüllen, oder nicht. Wenn der Kontext nicht erforderlich ist, holen Sie ihn nicht ab. Wenn der Kontext ist notwendig, Sie es besser in der Nähe haben!

Und sind die wichtigsten Websites (Amazon, Google, Facebook, Twitter usw.) tatsächlich zustandslos? Verwenden sie Token oder Cookies (oder beides)?

Wahrscheinlich beides. Aber im Allgemeinen tun sie genau das, was Sie tun: Sie setzen Cookies, um "Status" -Datensätze in umfangreichen "Sitzungs" -Datenbanken zu identifizieren.

Wenn möglich, vermute ich, dass sie grundlegende Identitätsansprüche in kurzlebige "Token" verwandeln, um unnötige Konflikte bei der zentralen Speicherung zu vermeiden. Die Tatsache, dass ich mich bei vielen dieser Dienste von allen anderen Standorten abmelden kann, ist jedoch ein guter Indikator dafür, dass sie, wenn sie überhaupt Token verwenden, zumindest von einem semi-traditionellen Sitzungsmodell "unterstützt" werden .

Svidgen
quelle
3
Zustimmen. Es erinnert mich an die Idee "unveränderlicher Daten". Wenn es unveränderlich ist, schnitzen Sie es in einen Stein, verschwenden Sie keinen Computer dafür. Lassen Sie Computer Daten verarbeiten! Deshalb haben wir sie gebaut! Anwendungen arbeiten mit Daten. Konstante Daten sind nutzlos.
@nocomprende FYI, ich werde später einen Nachtrag dazu machen. Ich habe das Gefühl, dass meine Antwort ein Teil der zugrunde liegenden Frage des OP ist. Denn es ist eine legitime Sorge hinter der „stateless Anwendung“ Idee schweben. Aber ist die Antwort nach dem Vorbild der, wenn Leute sagen , ‚stateless‘, was sie bedeuten , sagen ‚verlässt sich minimal auf serverseitige Sitzungen.‘
Svidgen
4
@nocomprende: Unveränderliche Datenstrukturen sind etwas anderes und werden zum Verwalten des Lebenszyklus von Speicherobjekten verwendet.
Whatsisname
1
Lieben Sie Ihre erste Zeile der Erklärung. Wenn wir etwas besprechen, stirbt jede verbale Aussage, die wir machen, sofort in Vergessenheit. Aber irgendwie können wir immer noch ein Gespräch führen, oder? Es ist Magie!
1
@nocomprende Dies ist eine interessante Diskussion, aber ich denke, wir sollten es hier nicht fortsetzen.
Pabrams
14

Statefulness ist nicht unbedingt eine schlechte Sache, aber Sie müssen den Unterschied zwischen stateful und zustandslosen Apps verstehen. Kurz gesagt, in statusbehafteten Apps werden Informationen zur aktuellen Sitzung gespeichert, in statusbehafteten Apps jedoch nicht. Informationen, die permanent als Teil eines Benutzerkontos gespeichert werden, können in einer Sitzung gespeichert werden oder auch nicht, aber das Speichern von Informationen in Bezug auf ein Benutzerkonto macht die Anwendung nicht automatisch statusbehaftet. Statefulness erfordert, dass der Server Informationen über die Sitzung des aktuellen Benutzers verwaltet, die über die des Client-Browsers hinausgehen. Ein Client könnte sich beispielsweise authentifizieren und ein JSESSIONID-Cookie erhalten, das er dann bei jeder Anforderung an den Server sendet. Wenn der Server mit dem Speichern von Inhalten im Sitzungsbereich der Anwendung beginnt, die auf dieser JSESSIONID basieren, wird der Zustand wiederhergestellt.

Staatenlosigkeit

Mit zustandslos ist gemeint, dass Server und Client keine aktuellen Informationen über die Benutzersitzung verwalten. Der Client und der Server können eine Form von Token verwenden, um die Authentifizierung zwischen Anforderungen bereitzustellen, es werden jedoch keine anderen aktuellen Informationen gespeichert. Ein typischer Anwendungsfall für eine solche Lösung könnte eine Nachrichten-Site sein, auf der die meisten Benutzer (neue Verbraucher) Informationen konsumieren, aber keine Informationen produzieren, die auf die Site zurückgehen. In solchen Fällen muss die Site keine Informationen über die aktuelle Benutzersitzung verwalten. Beachten Sie, dass die Website möglicherweise immer noch Cookies verwendet, um den Benutzer zu identifizieren und Informationen über die Verwendung der Website durch den Benutzer zu speichern. Dies kann jedoch weiterhin als zustandslos angesehen werden, da alles, was aufgezeichnet wurde, eine Transaktion sein kann, z der Server, aber nicht in einer Benutzersitzung verwaltet.

Statefulness auf dem Server

Auf dem Server speichert eine Stateful-App Statusinformationen zu aktuellen Benutzern. Bei diesem Ansatz werden in der Regel Cookies verwendet, um das System des Benutzers zu identifizieren, sodass der Status zwischen Anforderungen auf dem Server beibehalten werden kann. Sitzungen können je nach Anwendungskontext authentifiziert werden oder nicht. Stateful-Server-Apps bieten den Vorteil, dass Benutzerzustandsinformationen auf dem Server zwischengespeichert werden und Lookups und Seitenantwortzeiten beschleunigt werden. Andererseits ist das Speichern von Informationen im Sitzungsbereich teuer und wird im Maßstab sehr ressourcenintensiv. Es schafft auch einen potenziellen Angriffsvektor für Hacker, mit dem sie versuchen können, Sitzungskennungen zu hijacken und Benutzersitzungen zu stehlen. Stateful Server-Apps haben auch die Herausforderung, Benutzersitzungen vor unerwarteten Dienstunterbrechungen, z. B. einem Serverausfall, zu schützen.

Statefulness auf dem Klienten

Mithilfe von JavaScript und modernen Browsertechnologien wie sessionStorage kann die Anwendung jetzt problemlos Statusinformationen zu einer Benutzersitzung auf dem Gerät des Benutzers speichern. Insgesamt kann die Anwendung immer noch als statusbehaftet angesehen werden, die Aufgabe der Statusverwaltung wurde jedoch auf den Client verlagert. Dieser Ansatz hat einen großen Vorteil (für den Betreuer der Webanwendung) gegenüber der Aufrechterhaltung des Status auf dem Server, da jeder Benutzer seinen eigenen Status aufrechterhält und die Serverinfrastruktur nicht belastet wird. Im Internet hat diese Art der Architekturauswahl enorme Auswirkungen auf die Hardware- und Stromkosten. Es könnte buchstäblich Millionen von Dollar pro Jahr kosten, den Status auf dem Server aufrechtzuerhalten. Durch den Wechsel zu einem System, das den Status des Clients beibehält, können dann jährlich Millionen von Dollar eingespart werden.

Tokens v. Cookies

Cookies dienen als Bezeichner für Clientgeräte / Browser. Sie können verwendet werden, um alle möglichen Dinge zu speichern, aber im Allgemeinen speichern sie eine Art von Bezeichner, wie z. B. CFID / CFTOKEN in CFML-Apps. Cookies können so eingestellt werden, dass sie für längere Zeit im Browser des Benutzers gespeichert bleiben. Dies ermöglicht es beispielsweise, die Authentifizierung in einer App zwischen Browsersitzungen aufrechtzuerhalten. Cookies können auch auf Nur-Speicher gesetzt werden, sodass sie verfallen, wenn ein Benutzer den Browser schließt.

Bei Tokens handelt es sich im Allgemeinen um eine Art identifizierender Informationen über den Benutzer, die auf dem Server generiert (mithilfe von Verschlüsselung zum Verwürfeln der Informationen), an den Client übergeben und mit der nachfolgenden Anforderung an den Server zurückgegeben werden. Sie können im Header der Anforderung und der Antwort übergeben werden, was in Anwendungen mit nur einer Seite ein gängiges Muster ist. Im Idealfall wird bei jeder Anforderung / Antwort ein neues Token generiert, sodass Token nicht abgefangen und später von einem Angreifer verwendet werden können.

Single Page Apps und Clientstatus

Bei SPAs werden Statusinformationen in den Client-Browser geladen und dort verwaltet. Wenn sich der Status ändert, z. B. wenn Sie eine Aktualisierung auf Ihrem Social Media-Konto veröffentlichen, leitet der Client diese neue Transaktion an den Server weiter. In diesem Fall speichert der Server das Update in einem dauerhaften Datenspeicher wie einer Datenbank und leitet alle Informationen an den Client zurück, die er für die Synchronisierung mit dem Server basierend auf dem Update benötigt (z. B. eine ID für das Update).

Beachten Sie, dass dieses Muster des Speicherns des Status auf dem Client Vorteile für Online- / Offline-Erlebnisse bietet, da Sie vom Server getrennt werden können, während Sie noch eine einigermaßen verwendbare Anwendung haben. Twitter ist ein gutes Beispiel für diesen Fall, in dem Sie alle geladenen Clientseiten in Ihrem Twitter-Feed überprüfen können, auch wenn Sie nicht mit der Twitter-Server-App verbunden sind. Dieses Muster schafft auch Komplexität bei der Synchronisation zwischen Server und Client, was ein ganz eigenes Thema ist. Die Komplexität der Lösung ist ein Kompromiss für die Aufrechterhaltung des Status auf dem Client.

Durch die Statefulness auf dem Client fühlen und verhalten sich Web-Apps eher wie herkömmliche Desktop-Apps. Im Gegensatz zu Desktop-Apps werden in der Regel nicht alle Kontoinformationen in einem Browser in Ihre Clientsitzung geladen. Dies wäre in vielen Fällen unpraktisch und würde zu schlechten Erfahrungen führen. Können Sie sich vorstellen, ein ganzes Google Mail-Postfach in den Browser zu laden? Stattdessen verwaltet der Client Informationen wie das Label / den Ordner, den Sie suchen, und wo in der Liste der E-Mails in dem Ordner, den Sie suchen. Das Abwägen der zu pflegenden Statusinformationen und der erforderlichen Anforderungen ist eine weitere technische Herausforderung dieses Musters. Auch hier besteht ein Kompromiss zwischen Praktikabilität und der Bereitstellung einer guten Benutzererfahrung.

Einkaufswagen und dergleichen

Was Besonderheiten wie Einkaufswagen betrifft, kommt es wirklich auf die Lösung an. Ein Einkaufswagen kann in einer Datenbank auf dem Server gespeichert sein, er kann nur im Sitzungsbereich auf dem Server gespeichert sein oder er kann sogar auf dem Client gespeichert sein. Amazon bietet beständige Warenkörbe für angemeldete Benutzer und "temporäre" Warenkörbe für anonyme Benutzer an, obwohl diese Warenkörbe zu einem gewissen Grad beständig sind.

Wenn Sie über etwas wie Google sprechen, bei dem es sich in Wirklichkeit um eine Reihe verschiedener Anwendungen handelt, die unter derselben Marke laufen, haben sie wahrscheinlich keine gemeinsame Architektur und sind so aufgebaut, dass sie den Bedürfnissen ihrer Benutzer am besten entsprechen. Wenn Sie erfahren möchten, wie eine Website erstellt wird, öffnen Sie die Entwicklertools in Ihrem Browser und schauen Sie sich diese an. Suchen Sie nach Cookies, beobachten Sie den Netzwerkverkehr und sehen Sie, wie er ausgeführt wird.

Tut mir leid, wenn diese Antwort ein wenig verwirrt, aber Staatlichkeit ist ein komplexes Thema.

Robert Munn
quelle
6

Sitzungen und Cookies müssen nicht vermieden werden. Sie können sie weiterhin mit zustandslosen Webanwendungen verwenden.

Es gibt einen großen Unterschied zwischen Java und Ruby on Rails. Java-Apps speichern die Sitzung mithilfe eines in einem Cookie gespeicherten Sitzungsschlüssels im Speicher. So können Sie schnell den Benutzerstatus und den Warenkorb abrufen. Sie müssen jedoch immer denselben Server mit Ihrer Sitzung treffen.

Rails-Apps speichern die Benutzer-ID in einem signierten, verschlüsselten Cookie. Es kann nicht manipuliert werden. Wenn Sie eine Seite laden, ruft die Web-App Ihren Status, Ihren Benutzer und Ihren Einkaufswagen aus einer Datenbank ab. Dies ist langsamer, aber der Schlüssel ist, dass Sie jede Instanz treffen können ! Auf diese Weise können Sie Instanzen nach Belieben neu starten, skalieren und herunterfahren. Sehr angenehm. Mit einer gemeinsam genutzten speicherinternen Cachedatenbank wie Redis kann dies ebenfalls beschleunigt werden. Sie können den Einkaufswagen auch im Cookie speichern, sofern er klein genug ist.

So können Sie durch clevere Techniken Staatenlosigkeit erreichen und die Fähigkeit hinzufügen, nach Belieben zu skalieren.

Chloe
quelle
5

Das Protokoll ist zustandslos.

Daraus folgt jedoch nicht unbedingt, dass Anwendungen, die das Protokoll verwenden, zustandslos sein sollten.

Hier einige verwandte StackOverflow-Antworten, die den Unterschied gut erklären:

Nebenbarker
quelle
5

Wenn Sie auf statuslos verweisen, z. B. in einem RESTful HTTP-Dienst, vermeiden Sie das Speichern des Status auf der Serverseite. Dazu gehört im besten Fall auch, dass Sie keinen Status in einer Datenbank oder anderen dauerhaften Speichern im Backend speichern. Um es deutlich zu machen, spreche ich von einem Zustand, der im Allgemeinen keine Daten ist. Es scheint, dass einige Leute die Dinge durcheinander bringen.

Eine zustandslose Kommunikation bietet mehrere Vorteile, insbesondere in Bezug auf Skalierbarkeit und Verfügbarkeit.

Ein besserer Ansatz ist die Verwendung von Tokens, die zustandslos sind, da auf dem Server nichts gespeichert ist.

Das stimmt (für bestimmte Authentifizierungs- und Autorisierungsprotokolle). Tokens können (aber nicht per se) alle Informationen innerhalb der Anforderung bereitstellen, die zur Authentifizierung eines Benutzers oder zur Autorisierung einer Aktion erforderlich sind. Ein Beispiel ist JWT .

Ich versuche zu verstehen, wie Webanwendungen statusfrei sein können, wenn Daten für meine Sitzung gespeichert werden (z. B. Artikel in einem Warenkorb). Werden diese tatsächlich irgendwo in einer Datenbank gespeichert und dann regelmäßig gelöscht? Wie funktioniert das, wenn Sie ein Token anstelle von Cookies verwenden?

Zum Warenkorb Beispiel. Es ist kein Problem, alle Einkaufswagenartikel auf der Client-Seite zu speichern, ohne eine Sitzung oder Cookies zu verwenden. Ein Beispiel finden Sie auf smashingmagazine.com . Es ist aber auch möglich, einen staatenlosen Einkaufswagen mit Cookies zu realisieren (zumindest wenn Ihr Sortiment nicht so groß ist und 4 KB Speicherplatz für Sie ausreicht).

Verstehen Sie mich nicht falsch, das heißt nicht, dass Sie einen Einkaufswagen ohne Status zu jedem Preis implementieren sollten. Amazon oder andere große Online-Einkaufsplattformen verwenden Stateful-Shopping-Cart-Implementierungen, da für sie Benutzererfahrung und Benutzerfreundlichkeit wichtiger sind als die Anpassung an technische nicht-funktionale Anforderungen wie Skalierbarkeit.

Im Allgemeinen werden Token nicht zum Speichern von Informationen wie Einkaufswagen-Artikeln verwendet. Sie werden für eine zustandslose Authentifizierung und Autorisierung verwendet.

Und sind die wichtigsten Websites (Amazon, Google, Facebook, Twitter usw.) tatsächlich zustandslos? Verwenden sie Token oder Cookies (oder beides)?

Wenn Sie gefragt werden, ob Cookies oder Token zur Authentifizierung verwendet werden, lautet die Antwort, dass beide verwendet werden. Für Benutzer werden meist Cookies für technische Kunden, meist Token verwendet.

Paul Wasilewski
quelle
-2

OK, die von Ihnen angegebene Regel ist technisch falsch. Alle Ebenen einer Webanwendung haben einen Status.

Die Intention der Regel ist "Keine sitzungsbezogenen Statusserver".

Das heißt, Sitzungsvariablen in ASP , die üblicherweise verwendet wurden, um Dinge wie Artikel im Warenkorb / Benutzernamen usw. zu erledigen.

Der Grund dafür ist, dass Ihnen der Arbeitsspeicher auf dem Server ausgeht, wenn Ihre Anwendung mehr Benutzer gewinnt. Das Verschieben des Speichers in eine Datenbank oder einen gemeinsam genutzten Cache löst das Problem nicht, da Sie immer noch einen Engpass haben.

Verschieben Sie den Status auf der Clientseite, um den Anwendungsstatus pro Benutzer beizubehalten, ohne dieses Problem zu beheben. Platzieren Sie die Warenkorbelemente beispielsweise in einem Cookie oder einem erweiterten clientseitigen Speicher.

Da die Anzahl der Clients mit der Anzahl der Benutzer skaliert, hat Ihre Anwendung insgesamt keinen Engpass und lässt sich gut skalieren.

Ewan
quelle
2
Während Speicherverluste und Denial-of-Service-Probleme ein Faktor waren, denke ich, dass ein wichtigerer Treiber heutzutage die Elastizität und Robustheit gegenüber Ausfällen eines Webservers ist, was natürlich auch mit der Skalierbarkeit zusammenhängt. Die Idee ist, wenn ein Server überlastet wird oder sogar abstürzt, kann ich zukünftige Anfragen (und mit ein bisschen mehr Sorgfalt auch fehlgeschlagene Anfragen wiedergeben) an neue Webserver weiterleiten, ohne die Koordination zu verlieren oder den Status zu verlieren (wie der Benutzer es sieht).
Derek Elkins
hmm irgendwie. Wenn Sie pro Benutzer Informationen auf dem Server haben, haben Sie immer noch ein Problem mit der Skalierbarkeit, auch wenn diese verteilt sind.
Ewan
Sie können viel tun, wenn das Abrufen von Daten von der Festplatte der Engpass ist, z. B. das Zwischenspeichern.
JeffO
nein, es liegt ein inhärentes Problem vor, wenn Sie diese Daten pro Sitzung speichern. Entweder Sie verschieben es vom Webserver auf ein eigenes Hochverfügbarkeitssystem oder Sie entfernen alles zusammen, indem Sie es auf den Client verschieben
Ewan,
1
All diese Diskussionen über den Versuch, die heiße Kartoffel zu meiden, rätseln mich wirklich. Was ist mit dem alten Sprichwort passiert: "Hier hört das Geld auf"? Irgendwas muss die Daten verwalten, meine Bank möchte nicht, dass ich alle meine Finanztransaktionsinformationen nur auf meinem Laptop behalte. Warum rennen alle weg und schreien vor Daten? Deshalb haben wir Computer! Verrückt.