Jak zachować aplikacje bezstanowe

97

To może być skomplikowane pytanie, ale staram się lepiej zrozumieć bezpaństwowość.

Na podstawie tego, co przeczytałem, aplikacje internetowe powinny być bezstanowe, co oznacza, że ​​każde żądanie jest traktowane jako niezależna transakcja. W związku z tym należy unikać sesji i plików cookie (ponieważ oba są stanowe). Lepszym rozwiązaniem jest użycie Tokenów, które są bezstanowe, ponieważ nic nie jest przechowywane na serwerze.

Próbuję więc zrozumieć, w jaki sposób aplikacje internetowe mogą być bezstanowe, gdy przechowywane są dane z mojej sesji (takie jak przedmioty w koszyku)? Czy faktycznie są one gdzieś przechowywane w bazie danych, a następnie okresowo są czyszczone? Jak to działa, gdy używasz tokena zamiast plików cookie?

A następnie jako powiązane pytanie, czy główne strony internetowe (Amazon, Google, Facebook, Twitter itp.) Są w rzeczywistości bezpaństwowcami? Czy używają tokenów lub plików cookie (lub obu)?


źródło
38
Ostatnio widziałem i rozmawiałem z programistami, którzy mają obsesję na punkcie bezpaństwowości, aż do rozproszenia uwagi. Fajnie jest mieć bezpaństwowość związaną z ponownym użyciem, ale nierealistyczne jest dążenie do tego celu w każdej sytuacji ponad każdy inny cel, chyba że masz mnóstwo zasobów, aby to zrobić z jakiegoś powodu, na przykład skalowania.
Mark Rogers,
4
@MarkRogers Dlaczego? Bezpaństwowość nie ma nic wspólnego z możliwością ponownego użycia. A bycie bezpaństwowcem nie prowadzi do większego wysiłku.
Paul Wasilewski
3
@PaulWasilewski: A bycie bezpaństwowcem nie prowadzi do większego wysiłku. => tak, dzięki aplikacji stanowej możesz zachować wszystko w pamięci związane z sesją. Nie skaluje się to dobrze, choć działa z przypinaniem sesji, ale jest BARDZO proste. Gdy serwery muszą zacząć wymieniać informacje między sobą, zaczynają się problemy.
Matthieu M.
6
Patrząc na Amazon, zauważysz, że Twój koszyk pozostaje, nawet jeśli zmienisz komputer, więc nie jest przechowywany w pliku cookie, ale w bazie danych.
njzk2 10.04.17
20
Jeśli nie przejdziesz do czytania mojej odpowiedzi. Oto krótka wersja: Żądania sieciowe są z natury bezstanowe. Aplikacje internetowe nie są. (Bez względu na to, co mówią niektórzy
dogmatyści z

Odpowiedzi:

95

„aplikacje internetowe powinny być bezstanowe” należy rozumieć jako „aplikacje internetowe powinny być bezpaństwowe, chyba że istnieje bardzo dobry powód, aby mieć stan” . „Wózek na zakupy” jest z założenia stanową funkcją, a zaprzeczanie, że przynosi efekt przeciwny do zamierzonego. Chodzi przede wszystkim o zachowanie stanu aplikacji między żądaniami.

Alternatywą, którą mogłem sobie wyobrazić jako bezpaństwową stronę internetową, która implementuje koszyk, byłaby aplikacja jednostronicowa, która utrzymuje koszyk całkowicie po stronie klienta, pobiera informacje o produktach za pomocą wywołań AJAX, a następnie wysyła je do serwera naraz użytkownik dokonuje kasy. Wątpię jednak, czy kiedykolwiek widziałem, aby ktoś to zrobił, ponieważ nie pozwala on na korzystanie z wielu kart przeglądarki i nie zachowuje stanu po przypadkowym zamknięciu karty. Jasne, istnieją obejścia takie jak używanie localstorage, ale potem znowu masz stan, tylko na kliencie zamiast na serwerze.

Ilekroć masz aplikację internetową, która wymaga utrwalania danych między odsłonami, zwykle robisz to, wprowadzając sesje. Sesję, do której należy żądanie, można zidentyfikować za pomocą pliku cookie lub parametru adresu URL dodanego do każdego linku. Pliki cookie powinny być preferowane, ponieważ utrzymują Twoje adresy URL pod ręką i zapobiegają przypadkowemu udostępnieniu adresu URL z identyfikatorem sesji. Jednak posiadanie tokenów URL jako rezerwowych jest również niezbędne dla użytkowników, którzy dezaktywują pliki cookie. Większość platform programistycznych ma system obsługi sesji, który może to zrobić natychmiast po wyjęciu z pudełka.

Po stronie serwera informacje o sesji są zwykle przechowywane w bazie danych. Buforowanie w pamięci po stronie serwera jest opcjonalne. Może znacznie skrócić czas reakcji, ale nie pozwoli na przesyłanie sesji między różnymi serwerami. Będziesz więc potrzebował trwałej bazy danych jako rezerwowej.

czy główne strony internetowe (Amazon, Google, Facebook, Twitter itp.) są w rzeczywistości bezpaństwowcami? Czy używają tokenów lub plików cookie (lub obu)?

Czy pozwalają ci się zalogować? Po zamknięciu karty i ponownym odwiedzeniu witryny nadal jesteś zalogowany? Jeśli tak, używają plików cookie, aby zachować Twoją tożsamość między sesjami.

Philipp
źródło
46
Myślę, że jedną z nieporozumień jest rozróżnienie między „aplikacją internetową” w szerokim znaczeniu perspektywy użytkownika, a „aplikacją internetową” w wąskim znaczeniu „kodu działającego na serwerze internetowym”. To drugie jest często uważane za bezpaństwowca, a nie pierwsze. Jak mówisz, nie ma sensu, aby ci pierwsi byli w ogóle bezpaństwowcami, ponieważ stan jest zwykle częścią logiki biznesowej. Aby ten ostatni był bezstanowy, oznacza to po prostu, że stan musi być przechowywany na kliencie lub serwerze bazy danych lub na obu serwerach, a nie na serwerze WWW.
Derek Elkins,
16
„[...] ale potem znowu masz stan, tylko na kliencie zamiast na serwerze.” Chodzi o brak stanu po stronie serwera, aby osiągnąć lepszą skalowalność i dostępność. Jeśli stan jest przechowywany po stronie klienta, nie ma znaczenia.
Paul Wasilewski
5
@ njzk2 czy możesz to rozwinąć, aby nie brzmiało to absurdalnie? Użytkownicy nie chodzą do Amazon, aby kupić więcej nazwisk. A po dokonaniu zakupu coś znika, co istniało tylko podczas zakupów. Jeśli to coś nie jest „stanem aplikacji”, to co to jest? Jeśli aplikacje nie mają stanu, co mają?
3
@nocomprende: Myślę, że ogólną zasadą njzk2 jest to, że zawartość twojego koszyka, podobnie jak twoje imię i nazwisko, to dane, które aplikacja internetowa utrzymuje po stronie serwera. Kiedy ludzie mówią: „aplikacje internetowe powinny być bezstanowe”, zwykle mają na myśli coś innego niż „aplikacje internetowe nie powinny uzyskiwać dostępu do bazy danych zawierającej pełne imię i nazwisko powiązane z nazwą użytkownika”. Dokładnie to, co oni mają na myśli przez „bezpaństwowiec” być może nie jest trywialnie zdefiniowane, ponieważ po uzyskaniu tej bazy jest wszelkiego rodzaju bzdury, że można utrzymywać się tam, aby wesprzeć nadmiernie skomplikowany stan aplikacji, ale nie powinno ;-)
Steve Jessop,
4
@nocomprende: rozszyfruj jajko, wycofując bazę danych: ponieważ nasza aplikacja internetowa jest bezstanowa, może zostać wznowiona jak wcześniej ;-)
Steve Jessop
56

To prawda, że ​​aplikacje internetowe powinny być bezstanowe. Jednak zmienne sesji, pliki cookie i tokeny nie naruszają tego, gdy wszystkie są przechowywane na kliencie (przeglądarce internetowej). Mogą to być parametry w żądaniu.

Oto uproszczony model:

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

Może to działać w przypadku wymiany stosu inżynierii oprogramowania . Ta odpowiedź, którą wpisuję, jest częścią stanu mojej przeglądarki internetowej. Dopóki jest to jedyne miejsce, w którym się znajduje, nie jest dostępne dla nikogo oprócz mnie. Ale jak tylko uderzę, Post your Answermoja przeglądarka wysyła ją do serwera internetowego. Serwer WWW przetwarza pocztę bez własnego stanu. Dowie się, kim jestem z mojej przeglądarki i bazy danych. Po sprawdzeniu i dodaniu go do bazy danych serwer internetowy szybko o mnie zapomina.

To właśnie oznacza bezpaństwowiec. Serwer nie ponosi odpowiedzialności za zapamiętywanie tych informacji. To nie jest jego praca.

Takie postępowanie ma wiele zalet. Jeśli serwer WWW ma wyciek pamięci, jest wykrywalny, ponieważ jego pojemność pamięci nie powinna rosnąć. Jeśli serwer WWW ulegnie awarii, moja tożsamość się z nim nie zgadza. Jeśli ktoś próbuje przeprowadzić atak typu „odmowa usługi”, nie może użyć do tego celu zasobów stanu serwera WWW, ponieważ serwer internetowy nie przydziela mu żadnego stanu między sesjami. Wszystko to ma na celu zapewnienie stabilności serwera WWW. W ten sposób, gdy zacznie działać, będzie działać.

Teraz, na pewno, zużywam zasoby w bazie danych, ale te zasoby zostały najpierw sprawdzone pod kątem mojej rezerwy przez coś stabilnego, na którym możemy liczyć, aby chronić bazę danych przed dziką i zwodniczą siecią: bezpaństwowy serwer sieciowy wymuszający reguły biznesowe.

candied_orange
źródło
8
Nie wiem ... Ta odpowiedź brzmi trochę jak powiedzenie: „ Excel nie przechowuje twojego arkusza kalkulacyjnego, ale dysk twardy!” Ha ha, czy baza danych nie jest częścią serwera WWW, jeśli chodzi o większość ludzi? Oczywiście stan nie jest przechowywany w CPU ani kodzie serwera, a trzymanie tego wszystkiego w pamięci jest dość głupie.
7
@nocomprende Nie, baza danych zwykle nie jest częścią twojego serwera WWW. Tak, przechowywanie stanu w bazie danych prawdopodobnie ogranicza skalowalność całej aplikacji, ale istnieje stosunkowo niewiele aplikacji, które mogą odciążyć cały swój stan (lub nawet cały stan „na użytkownika”) na kliencie. Serwery baz danych są specjalnie zaprojektowane do skalowalnej obsługi stanu i, jak wspomina CandiedOrange, są zwykle lepiej chronione, zabezpieczane i weryfikowane niż serwery WWW. Łatwość skalowania serwerów sieciowych ma wiele zalet, chociaż nie rozwiązuje to wszystkich problemów ze skalowalnością.
Derek Elkins,
9
@nocomprende: Mówiąc, że baza danych nie jest częścią serwera WWW, możesz mieć jedną bazę danych (lub klaster bazy danych) dla 1, 2, 3, ... serwerów. W ten sposób bezpaństwowość ma zwiększyć skalowalność: możesz skalować klaster bazy danych i liczbę serwerów WWW niezależnie.
Matthieu M.
6
„To prawda, że ​​aplikacje internetowe powinny być bezstanowe”. Nie. To kompletny nonsens.
svidgen
4
Ta odpowiedź najbardziej mi się podoba, ponieważ najlepiej ilustruje użycie „bezstanowego” w web dev. Serwer nie utrzymuje stanu między żądaniami. Cały stan musi pochodzić od klienta (tj. Część żądania) lub z bazy danych (prawdopodobnie na podstawie żądania). Nawiasem mówiąc, w aplikacji internetowej często występuje pewien stan (np. Statyczne wystąpienia rzeczy), ale ogólnie rzecz biorąc, chciałbyś zaprojektować rzeczy tak, aby były bezstanowe. Ta odpowiedź wydaje się lepsza niż przyjęta, ponieważ najlepiej wyjaśnia ideę bezpaństwowości.
Kat
30

aplikacje internetowe powinny być bezstanowe

Nonsens. Żądania sieciowe powinny być bezstanowe. Mówiąc dokładniej, żądania internetowe bezstanowe.

Ale stwierdzenie, że cała aplikacja powinna być bezpaństwowcem, jest kompletnym nonsensem.

każde żądanie jest traktowane jako niezależna transakcja.

Tak, dokładnie . Lub dokładniej, tak, koniecznie . Przez HTTP każde żądanie jest z natury niezależne od wszystkich innych żądań. Dodanie „stanowości” do HTTP wymaga jawnej identyfikacji, przechowywania i pobierania „stanu” dla każdego żądania „stanowego”. A to wymaga wysiłku, zmniejsza wydajność i dodaje złożoności.

I z tych powodów każde żądanie, które może być bezpaństwowe „powinno” być bezpaństwowe.

W związku z tym należy unikać sesji i plików cookie (ponieważ oba są stanowe). Lepszym rozwiązaniem jest użycie żetonów

Kilka rzeczy: Tokeny można również powiązać z pamięcią sesji. Pliki cookie nie muszą być powiązane z przechowywaniem sesji. Tokeny są często przechowywane w plikach cookie. A czasami sesja jest po prostu odpowiednim narzędziem do pracy.

Oznacza to, że przynajmniej czasami , sesje i ciasteczka są po prostu jako „lepszy”, jak tokeny!

[Tokeny] są bezstanowe, ponieważ nic nie jest przechowywane na serwerze.

Cóż, to wszystko. Na tym właśnie polega dogmat „bezpaństwowości”. Chociaż, żeby być jasnym, nie chodzi o przechowywanie „niczego” na serwerze, nie chodzi o przechowywanie stanu sesji na serwerze.

Na przykład moja skrzynka odbiorcza Gmaila jest w stanie. I cholernie lepiej jest przechowywać na serwerze! Ale to nie jest stan sesji .

Więc zamiast serwerów, które mogą wziąć mały identyfikator i dowiedzieć się, kim jesteś itd., Bezpaństwowe aplikacje chcą przypomnieć, kim jesteś i co robisz z każdą cholerną prośbą. Stan aplikacji nadal istnieje, klient jest po prostu odpowiedzialny za jego utrzymanie.

Teraz, jeśli ten stan jest niewielki, to prawdopodobnie jest OK. W niektórych przypadkach jest to bardzo dobre.

A potem oczywiście są rzeczy, których po prostu oczekujemy, że będą stanowcze ...

w jaki sposób aplikacje internetowe mogą być bezstanowe, gdy przechowywane są dane z mojej sesji (takie jak przedmioty w koszyku)? Czy faktycznie są one gdzieś przechowywane w bazie danych, a następnie okresowo są czyszczone?

Dwie opcje. Albo masz sesję, albo odmawiasz!

... ale poważnie. Zwykle nie przechowujesz koszyka w pliku cookie. Coś w rodzaju koszyka na zakupy albo będzie przechowywane w „tradycyjnej” sesji, albo będzie przechowywane jako Cartobiekt, z jakimś identyfikatorem, którego serwer użyje do wciągnięcia go do kolejnych żądań. Coś w stylu ... uch ... sesji ...

Naprawdę na poważnie: w dużym stopniu „stanowość” jest tym, co nazywamy, gdy dwóch komunikujących się agentów może kontekstualizować wiadomości w rozmowie. Sesja, tradycyjnie rozumiana, jest właśnie tym, co zwykle nazywamy mechanizmem, za pomocą którego się to dzieje.

Twierdzę, że niezależnie od tego, czy korzystasz z tokenów, czy „sesji” dla każdego żądania obsługiwanego przez serwer, musisz kontekstualizować to żądanie, aby je spełnić, albo nie. Jeśli kontekst nie jest konieczny, nie pobieraj go. Jeśli kontekst jest konieczny, lepiej go mieć w pobliżu!

A następnie jako powiązane pytanie, czy główne strony internetowe (Amazon, Google, Facebook, Twitter itp.) Są w rzeczywistości bezpaństwowcami? Czy używają tokenów lub plików cookie (lub obu)?

Prawdopodobnie jedno i drugie. Ale ogólnie rzecz biorąc, robią dokładnie to, co robisz: ustawiają pliki cookie, aby identyfikować rekordy „stanowe” w ogromnych bazach danych „sesyjnych”.

O ile to możliwe, podejrzewam, że wprowadzili podstawowe roszczenia dotyczące tożsamości w krótkotrwałe „tokeny”, aby uniknąć niepotrzebnej rywalizacji o scentralizowane przechowywanie. Ale fakt, że wiele z tych usług pozwala mi „wylogować się ze wszystkich innych lokalizacji”, jest dobrym wskaźnikiem, że jeśli w ogóle korzystają z tokenów, są przynajmniej „obsługiwane” przez pół-tradycyjny model sesji .

svidgen
źródło
3
Zgodzić się. Przypomina mi pomysł „niezmiennych danych”. Jeśli jest niezmienny, wyrzeźb go w skale, nie marnuj na to komputera. Pozwól komputerom robić rzeczy z danymi! Właśnie dlatego je zbudowaliśmy! Aplikacje działają z danymi. Dane, które są stałe, są bezużyteczne.
@nocomprende FYI, zrobię uzupełnienie do tego później. Wydaje mi się, że brakuje mojej odpowiedzi w podstawowym pytaniu PO. Bo tam jest legit obawy pływające za „bezpaństwowca aplikacji” pomysłu. Ale odpowiedź jest taka, że kiedy ludzie mówią „bezpaństwowiec”, mają na myśli „minimalnie polegają na sesjach po stronie serwera”.
svidgen
4
@nocomprende: niezmienne struktury danych są czymś innym i są narzędziem służącym do zarządzania cyklami życia obiektów pamięci.
whatsisname
1
Uwielbiam swoją pierwszą linię wyjaśnień. Kiedy coś omawiamy, każde wypowiedziane przez nas oświadczenie natychmiast zamiera w zapomnienie. Ale jakoś nadal jesteśmy w stanie kontynuować rozmowę, co? To magia!
1
@nocomprende To interesująca dyskusja, ale myślę, że nie powinniśmy jej tutaj kontynuować.
pabrams
14

Stanowość niekoniecznie jest złą rzeczą, ale musisz zrozumieć różnicę między aplikacjami stanowymi a bezpaństwowymi. Krótko mówiąc, aplikacje stanowe przechowują informacje o bieżącej sesji, a aplikacje bezstanowe nie. Informacje przechowywane na stałe jako część konta użytkownika mogą, ale nie muszą być przechowywane w sesji, ale przechowywanie informacji związanych z kontem użytkownika samo w sobie nie powoduje stanu aplikacji. Stan wymaga, aby serwer przechowywał informacje o sesji bieżącego użytkownika poza tym, co utrzymuje przeglądarka klienta. Na przykład klient może się uwierzytelnić i otrzymać plik cookie JSESSIONID, który następnie wysyła do serwera przy każdym żądaniu. Jeśli serwer zacznie przechowywać rzeczy w zakresie sesji aplikacji na podstawie tego JSESSIONID, staje się stanowy.

Bezpaństwowość

Przez „bezstanowy” rozumiemy, że serwer i klient nie przechowują bieżących informacji o sesji użytkownika. Klient i serwer mogą używać jakiejś formy tokena, aby zapewnić uwierzytelnianie między żądaniami, ale nie są przechowywane żadne inne bieżące informacje. Typowym przykładem użycia takiego rozwiązania może być serwis informacyjny, w którym większość użytkowników (nowych konsumentów) konsumuje informacje, ale nie generuje informacji, które wracają do witryny. W takich przypadkach witryna nie musi utrzymywać żadnych informacji o bieżącej sesji użytkownika. Należy pamiętać, że witryna może nadal używać plików cookie do identyfikowania użytkownika i przechowywania informacji o korzystaniu z niego przez tego użytkownika, ale może to nadal być uważane za bezpaństwowe, ponieważ wszystko zarejestrowane może być transakcyjne, np. Jaki link kliknął użytkownik, który może zostać zarejestrowany przez serwer, ale nie utrzymywany w sesji użytkownika.

Stan na serwerze

Na serwerze aplikacja stanowa zapisuje informacje o stanie o bieżących użytkownikach. Podejście to ogólnie polega na wykorzystaniu plików cookie do identyfikacji systemu użytkownika, dzięki czemu można zachować stan na serwerze między żądaniami. Sesje mogą być uwierzytelniane lub nie, w zależności od kontekstu aplikacji. Zaletą stanowych aplikacji serwerowych jest buforowanie informacji o stanie użytkownika na serwerze, przyspieszenie wyszukiwania i czas odpowiedzi strony. Z drugiej strony przechowywanie informacji w zakresie sesji jest kosztowne, a na dużą skalę staje się bardzo zasobochłonne. Tworzy również potencjalny wektor ataku dla hakerów, którzy próbują przejąć identyfikatory sesji i ukraść sesje użytkownika. Wyzwaniem dla stanowych aplikacji serwerowych jest ochrona sesji użytkowników przed nieoczekiwanymi przerwami w świadczeniu usług, np. Awarią serwera.

Stan klienta

Korzystając z JavaScript i nowoczesnych technologii przeglądarki, takich jak sessionStorage, aplikacja może teraz łatwo przechowywać informacje o stanie sesji użytkownika na urządzeniu tego użytkownika. Ogólnie aplikacja może być nadal uważana za stanową, ale zadanie utrzymania stanu zostało przeniesione do klienta. Takie podejście ma dużą zaletę (dla osoby zarządzającej aplikacją internetową) nad utrzymywaniem stanu na serwerze, ponieważ w rzeczywistości każdy użytkownik utrzymuje własny stan i nie ma obciążenia infrastruktury serwera. W skali sieci tego rodzaju wybór architektury ma ogromny wpływ na koszty sprzętu i energii elektrycznej. Utrzymanie stanu na serwerze może dosłownie kosztować miliony dolarów rocznie. Przejście do systemu utrzymującego stan na kliencie może wówczas zaoszczędzić miliony dolarów rocznie.

Tokeny v. Ciasteczka

Pliki cookie działają jako identyfikatory urządzeń / przeglądarek klienta. Mogą być używane do przechowywania wszelkiego rodzaju rzeczy, ale ogólnie przechowują jakąś formę identyfikatora, np. CFID / CFTOKEN w aplikacjach CFML. Pliki cookie można ustawić tak, aby długo działały w przeglądarce użytkownika, umożliwiając między innymi utrzymanie uwierzytelnienia w aplikacji między sesjami przeglądarki. Pliki cookie można również ustawić tylko na pamięć, więc wygasają, gdy użytkownik zamknie przeglądarkę.

Tokeny to generalnie pewne informacje identyfikujące użytkownika, które są generowane na serwerze (za pomocą szyfrowania w celu szyfrowania informacji), przekazywane do klienta i zwracane na serwer z kolejnym żądaniem. Mogą być one przekazywane w nagłówku żądania i odpowiedzi, co jest częstym wzorcem w aplikacjach jednostronicowych. Idealnie byłoby, gdyby każde żądanie / odpowiedź generowało nowy token, więc token nie może zostać przechwycony i wykorzystany później przez atakującego.

Aplikacje pojedynczej strony i stan klienta

W przypadku SPA informacje o stanie są ładowane do przeglądarki klienta i tam przechowywane. Kiedy stan się zmienia, np. Gdy opublikujesz aktualizację na swoim koncie w mediach społecznościowych, klient przekazuje tę nową transakcję do serwera. W takim przypadku serwer zapisuje tę aktualizację w trwałym magazynie danych, takim jak baza danych, i przekazuje klientowi wszelkie informacje potrzebne do synchronizacji z serwerem na podstawie aktualizacji (np. Identyfikator aktualizacji).

Zauważ, że ten wzorzec przechowywania stanu na kliencie oferuje korzyści dla doświadczeń online / offline, ponieważ możesz być odłączony od serwera, wciąż mając nieco użyteczną aplikację. Twitter jest dobrym przykładem tego przypadku, w którym możesz przejrzeć wszystko załadowane po stronie klienta w swoim kanale Twitter, nawet jeśli nie masz połączenia z aplikacją serwera Twitter. Ten wzorzec powoduje również złożoność synchronizacji między serwerem a klientem, co stanowi całość. Złożoność rozwiązania jest kompromisem za możliwość utrzymania stanu na kliencie.

Stan na kliencie sprawia, że ​​aplikacje internetowe są bardziej podobne do tradycyjnych aplikacji komputerowych. W przeciwieństwie do aplikacji komputerowych, zazwyczaj nie wszystkie informacje o koncie są ładowane do sesji klienta w przeglądarce. Takie postępowanie w wielu przypadkach byłoby niepraktyczne i powodowałoby złe doświadczenia. Czy możesz sobie wyobrazić próbę załadowania całego pola Gmaila do przeglądarki? Zamiast tego klient przechowuje informacje, takie jak etykieta / folder, na który patrzysz i gdzie na liście wiadomości e-mail w tym folderze, którego szukasz. Równoważenie informacji o stanie, które należy zachować, i tego, o co należy poprosić w razie potrzeby, jest kolejnym wyzwaniem inżynieryjnym tego rodzaju, i znowu stanowi kompromis między praktycznością a zapewnieniem dobrych wrażeń użytkownika.

Wózki sklepowe i tym podobne

Jeśli chodzi o szczegóły, takie jak koszyki, to naprawdę zależy od rozwiązania. Koszyk na zakupy może być przechowywany w bazie danych na serwerze, może być przechowywany tylko w zakresie sesji na serwerze, a nawet może być przechowywany na kliencie. Amazon ma trwałe koszyki na zakupy dla zalogowanych użytkowników i „tymczasowe” wózki dla anonimowych użytkowników, chociaż koszyki te są do pewnego stopnia trwałe.

Gdy mówisz o czymś takim jak Google, który jest naprawdę zbiorem różnych aplikacji pod tą samą marką, prawdopodobnie nie mają one wspólnej architektury, a każda z nich jest zbudowana w sposób, który najlepiej odpowiada potrzebom jej użytkowników. Jeśli chcesz dowiedzieć się, jak zbudowana jest witryna, otwórz narzędzia programistyczne w przeglądarce i spójrz na nią. Sprawdź pliki cookie, obserwuj ruch sieciowy i zobacz, jak działa.

Przepraszam, jeśli ta odpowiedź trochę się wtrąca, ale stanowość jest złożonym tematem.

Robert Munn
źródło
6

Sesji i plików cookie nie trzeba unikać. Nadal możesz je mieć za pomocą bezstanowych aplikacji internetowych.

Istnieje duża różnica między Javą a Ruby on Rails. Aplikacje Java będą przechowywać sesję w pamięci za pomocą klucza sesji zapisanego w pliku cookie. Jest to szybki sposób na odzyskanie stanu użytkownika i koszyka. Jednak zawsze musisz trafić na ten sam serwer podczas sesji.

Aplikacje Railsowe przechowują identyfikator użytkownika w podpisanym, zaszyfrowanym pliku cookie. Nie można go manipulować. Podczas ładowania strony aplikacja internetowa pobiera stan, użytkownika i koszyk z bazy danych. Jest to wolniejsze, ale kluczem jest to, że możesz trafić w każdą instancję ! Umożliwia to ponowne uruchamianie, skalowanie i zamykanie instancji do woli. Bardzo wygodne Można to również przyspieszyć dzięki współużytkowanej pamięci podręcznej, takiej jak Redis. Możesz też przechowywać koszyk w pliku cookie, pod warunkiem, że jest wystarczająco mały.

Dzięki sprytnym technikom możesz osiągnąć bezpaństwowość i dowolnie skalować.

Chloe
źródło
5

Protokół jest bezstanowy.

Ale z tego niekoniecznie wynika, że ​​aplikacje korzystające z protokołu powinny być bezstanowe.

Oto kilka powiązanych odpowiedzi StackOverflow, które dobrze wyjaśniają różnicę:

sidehowbarker
źródło
5

Odnosząc się do bezstanowych - np. W usłudze RESTful HTTP - ma zamiar uniknąć przechowywania stanu po stronie serwera. W najlepszym wypadku obejmuje to również unikanie przechowywania dowolnego stanu w bazie danych lub innych trwałych magazynach w wewnętrznej bazie danych. Aby to wyjaśnić, mówię o stanie, a nie o danych w ogóle. Wygląda na to, że niektórzy mieszają rzeczy.

Bezpaństwowa komunikacja ma kilka zalet, zwłaszcza jeśli chodzi o skalowalność i dostępność.

Lepszym rozwiązaniem jest użycie Tokenów, które są bezstanowe, ponieważ nic nie jest przechowywane na serwerze.

To prawda (w przypadku niektórych protokołów uwierzytelniania i autoryzacji). Tokeny mogą (ale nie same w sobie) zawierać wszystkie informacje w żądaniu, które są potrzebne do uwierzytelnienia użytkownika lub autoryzacji działania. Na przykład spójrz na JWT .

Próbuję więc zrozumieć, w jaki sposób aplikacje internetowe mogą być bezstanowe, gdy przechowywane są dane z mojej sesji (takie jak przedmioty w koszyku)? Czy faktycznie są one gdzieś przechowywane w bazie danych, a następnie okresowo są czyszczone? Jak to działa, gdy używasz tokena zamiast plików cookie?

Jeśli chodzi o przykład koszyka. Przechowywanie wszystkich produktów w koszyku po stronie klienta nie stanowi problemu bez użycia sesji lub plików cookie. Możesz znaleźć przykład na smashingmagazine.com . Ale możliwe jest również zrealizowanie bezpaństwowego koszyka z ciasteczkami (przynajmniej jeśli twój asortyment nie jest tak duży i wystarcza Ci miejsce na 4kb).

Nie zrozum mnie źle, to nie znaczy, że powinieneś wdrożyć koszyk bezstanowy za każdą cenę. Amazon lub inne duże platformy zakupów online używają stanowych implementacji koszyków, ponieważ wygoda użytkownika i użyteczność są dla nich ważniejsze niż dopasowanie technicznych niefunkcjonalnych wymagań, takich jak skalowalność.

Zasadniczo tokeny nie są używane do przechowywania informacji, takich jak przedmioty w koszyku. Służą do bezpaństwowego uwierzytelniania i autoryzacji.

A następnie jako powiązane pytanie, czy główne strony internetowe (Amazon, Google, Facebook, Twitter itp.) Są w rzeczywistości bezpaństwowcami? Czy używają tokenów lub plików cookie (lub obu)?

Jeśli pytasz, czy używają plików cookie lub tokenów do uwierzytelnienia, odpowiedzią jest, że używają obu. W przypadku użytkowników najczęściej wykorzystywane są pliki cookie dla klientów technicznych, w większości używane są tokeny.

Paweł Wasilewski
źródło
-2

OK, cytowana reguła jest technicznie niepoprawna. Wszystkie warstwy aplikacji internetowej mają stan.

Reguła ma na celu „nie utrzymuj serwera stanów na sesję po stronie”.

Tzn. Zmienne sesji w ASP , które były powszechnie używane do robienia rzeczy takich jak elementy w koszyku / nazwie użytkownika itp.

Powodem jest to, że zabraknie pamięci na serwerze, gdy aplikacja zyska więcej użytkowników. Przeniesienie magazynu do bazy danych lub współdzielonej pamięci podręcznej nie rozwiązuje problemu, ponieważ nadal występuje wąskie gardło.

Aby utrzymać stan aplikacji dla poszczególnych użytkowników bez dotykania tego problemu, przenieś stan na stronę klienta. Na przykład umieść elementy koszyka w pliku cookie lub bardziej zaawansowanym magazynie po stronie klienta.

Ponieważ liczba klientów skaluje się wraz z liczbą użytkowników, cała aplikacja nie będzie miała wąskiego gardła i będzie dobrze skalowana.

Ewan
źródło
2
Podczas gdy wycieki pamięci i problemy z odmową usługi były czynnikiem, myślę, że obecnie bardziej znaczącym czynnikiem jest elastyczność i odporność na awarie serwera WWW, co oczywiście jest również związane ze skalowalnością. Chodzi o to, że jeśli serwer zostanie przeciążony lub nawet ulegnie awarii, mogę po prostu przekierować przyszłe żądania (a przy odrobinie staranności nawet odtwarzać nieudane żądania) na nowe serwery sieciowe bez koordynacji lub utraty stanu (jak widzi to użytkownik).
Derek Elkins,
hmm jakby. Jeśli masz na serwerze informacje o użytkowniku, nawet jeśli jest ono rozproszone, nadal masz problem ze skalowalnością.
Ewan
Jest wiele rzeczy, które możesz zrobić, jeśli wąskim gardłem jest pobieranie danych z dysku, np. Buforowanie.
JeffO
nie, istnieje nieodłączny problem, jeśli przechowujesz dane na sesję. albo przeniesiesz go z serwera do własnego systemu wysokiej dostępności, albo pozbędziesz się tego wszystkiego razem, przenosząc go do klienta
Ewan
1
Cała ta dyskusja na temat unikania gorącego ziemniaka naprawdę mnie zaskakuje. Cokolwiek się stało ze starym powiedzeniem: „Buck kończy się tutaj”? Coś musi zarządzać danymi, mój bank nie chciałby, żebym przechowywał wszystkie informacje o moich transakcjach finansowych tylko na moim laptopie. Dlaczego wszyscy uciekają krzycząc z danych? Właśnie dlatego mamy komputery! Zwariowany.