Как сохранить приложения без сохранения состояния

Это может быть запутанный вопрос, но я пытаюсь лучше понять безгражданство.

Исходя из того, что я прочитал, веб-приложения должны быть без сохранения состояния, то есть каждый запрос рассматривается как независимая транзакция. В результате следует избегать сеанса и файлов cookie (так как они оба с состоянием). Лучшим подходом является использование токенов, которые не сохраняют состояния, поскольку на сервере ничего не хранится.

Поэтому я пытаюсь понять, как веб-приложения могут быть без сохранения состояния, когда для моего сеанса хранятся данные (например, элементы в корзине)? Хранятся ли они где-то в базе данных, а затем периодически удаляются? Как это работает, когда вы используете токен вместо куки?

И затем, в качестве связанного вопроса, являются ли главные сайты (Amazon, Google, Facebook, Twitter и т. Д.) Фактически без гражданства? Они используют токены или куки (или оба)?

«Веб-приложения должны быть без состояния» следует понимать как «веб-приложения должны быть без состояния, если только для этого нет веских оснований» . «Корзина для покупок» - это особенность, созданная по замыслу, и отрицание этого весьма непродуктивно. Весь смысл шаблона корзины покупок заключается в сохранении состояния приложения между запросами.

Альтернативой, которую я мог бы представить как веб-сайт без состояния, который реализует корзину покупок, было бы одностраничное приложение, которое сохраняет корзину покупок полностью на стороне клиента, извлекает информацию о продукте с помощью вызовов AJAX и затем сразу отправляет ее на сервер, когда пользователь делает заказ. Но я сомневаюсь, что когда-либо видел, чтобы кто-то действительно делал это, потому что он не позволяет пользователю использовать несколько вкладок браузера и не сохраняет состояния, когда они случайно закрывают вкладку. Конечно, есть обходные пути, такие как использование localalstorage, но тогда у вас снова будет состояние, только на клиенте, а не на сервере.

Всякий раз, когда у вас есть веб-приложение, которое требует сохранения данных между просмотрами страниц, вы обычно делаете это, вводя сеансы. Сеанс, к которому принадлежит запрос, может быть идентифицирован с помощью файла cookie или параметра URL, который вы добавляете в каждую ссылку. Куки должны быть предпочтительнее, потому что они делают ваши URL более удобными и предотвращают случайное использование пользователем вашего URL с идентификатором сессии. Но наличие URL-маркеров в качестве запасного варианта также крайне важно для пользователей, которые отключают файлы cookie. Большинство каркасов веб-разработки имеют систему обработки сеансов, которая может сделать это «из коробки».

На стороне сервера информация о сеансе обычно хранится в базе данных. Кэширование в памяти на стороне сервера необязательно. Это может значительно улучшить время отклика, но не позволит вам переносить сеансы между разными серверами. Таким образом, вам понадобится постоянная база данных в качестве запасного варианта.

основные веб-сайты (Amazon, Google, Facebook, Twitter и т. д.) фактически не имеют статуса? Они используют токены или куки (или оба)?

Они позволяют вам войти? Когда вы закрываете вкладку и снова посещаете сайт, вы все еще вошли в систему? Если да, то они используют куки для сохранения вашей личности между сессиями.

Это правда, что веб-приложения не должны иметь состояния. Однако переменные сеанса, файлы cookie и токены не нарушают этого, когда все они хранятся на клиенте (веб-браузер). Они могут быть параметрами в запросе.

Вот упрощенная модель:

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

Это может работать для разработки программного обеспечения стека обмена . Этот ответ, который я печатаю, является частью состояния моего веб-браузера. Пока это единственное место, где оно есть, оно не доступно никому, кроме меня. Но как только я нажимаю, Post your Answerмой браузер отправляет его на веб-сервер. Веб-сервер обрабатывает сообщение, не используя свое собственное состояние. Он узнает, кто я, из моего браузера и из базы данных. Как только он закончит проверку моего сообщения и добавит его в базу данных, веб-сервер быстро забудет обо мне.

Вот что значит безгражданство. Сервер не несет ответственности за запоминание всего этого. Это не его работа.

Делать это имеет много преимуществ. Если у веб-сервера есть утечка памяти, это можно обнаружить, так как его объем памяти не должен расти. Если веб-сервер падает, моя личность не идет с этим. Если кто-то пытается выполнить атаку типа «отказ в обслуживании», он не может использовать для этого ресурсы состояния веб-сервера, потому что веб-сервер не выделяет ему состояния между сеансами. Все это направлено на то, чтобы сделать веб-сервер стабильным. Таким образом, когда он начинает работать, он продолжает работать.

Теперь, конечно, я использую ресурсы в базе данных, но эти ресурсы сначала были проверены с учетом моих допусков с помощью чего-то стабильного, на что мы можем рассчитывать, чтобы защитить базу данных от дикого и неуклюжего веба: веб-сервер, обеспечивающий соблюдение бизнес-правил без сохранения состояния.

веб-приложения должны быть без сохранения состояния

Бред какой то. Веб- запросы должны быть без сохранения состояния. Точнее, веб-запросы не сохраняют состояния.

Но говорить, что все приложение должно быть без сохранения состояния, - полная чушь.

каждый запрос рассматривается как независимая транзакция.

Да, точно . Точнее да, обязательно . По HTTP каждый запрос по своей природе не зависит от всех других запросов. Для добавления «состояния» в HTTP требуется, чтобы вы явно идентифицировали, хранили и извлекали «состояние» для каждого «запроса с состоянием». И это требует усилий, снижает производительность и добавляет сложности.

И по этим причинам каждый запрос, который может быть без сохранения состояния «должен быть» без сохранения состояния.

В результате следует избегать сеанса и файлов cookie (так как они оба с состоянием). Лучше всего использовать токены

Несколько вещей: токены также могут быть привязаны к хранилищу сессии. Cookies не нужно привязывать к хранилищу сессии. Токены часто хранятся в файлах cookie. И иногда сессия - это просто правильный инструмент для работы.

Это означает, что, по крайней мере, иногда сеансы и файлы cookie так же «лучше», как токены!

[Токены] не имеют состояния, потому что на сервере ничего не хранится.

Ну вот и все. Вот о чем действительно догмат "безгражданства". Хотя, чтобы было ясно, речь идет не о хранении «ничего» на сервере, а о том, чтобы не хранить состояние сеанса на сервере.

Например, мой почтовый ящик Gmail находится в состоянии. И черт побери, лучше хранить на сервере! Но это не состояние сеанса .

Таким образом, вместо того, чтобы иметь серверы, которые могут взять небольшой идентификатор и выяснить, кто вы и т. Д., Приложения без сохранения состояния хотят напоминать, кто вы и что вы делаете с каждым кровавым запросом. Состояние приложения все еще существует, клиент просто отвечает за его удержание.

Теперь, если это состояние маленькое, это, вероятно, нормально. В некоторых случаях это очень хорошо.

И затем, конечно, есть вещи, которые мы просто ожидаем, чтобы быть с состоянием ...

Как веб-приложения могут быть без сохранения состояния, если для моего сеанса хранятся данные (например, элементы в корзине)? Хранятся ли они где-то в базе данных, а затем периодически удаляются?

Два варианта. Либо у вас есть сеанс, либо вы отрицаете!

... Но серьезно. Обычно вы не храните корзину в cookie. Что-то вроде корзины покупок будет либо сохранено в «традиционном» сеансе, либо будет сохранено как Cartобъект с каким-то идентификатором, который сервер использует для перетаскивания его в последующие запросы. Вроде как .. э-э-э ... эээ ... сессия.

По-настоящему серьезно: в значительной степени «состояние» - это именно то, что мы называем, когда два взаимодействующих агента могут контекстуализировать сообщения в разговоре. Традиционно понимаемый сеанс - это то, что мы обычно называем механизмом, посредством которого это происходит.

Я бы сказал, что независимо от того, используете ли вы токены или «сеансы» для каждого запроса, который обрабатывает ваш сервер, вам нужно либо контекстуализировать этот запрос для его выполнения, либо нет. Если контекст не нужен, не выбирайте его. Если контекст является необходимым, то лучше иметь его рядом!

И затем, в качестве связанного вопроса, являются ли главные сайты (Amazon, Google, Facebook, Twitter и т. Д.) Фактически без гражданства? Они используют токены или куки (или оба)?

Вероятно, оба. Но, вообще говоря, они делают именно то, что вы делаете: они устанавливают файлы cookie для идентификации записей «состояния» в больших «сессионных» базах данных.

Я подозреваю, что, когда это возможно, они помещают базовые утверждения личности в недолговечные «токены», чтобы избежать ненужных конфликтов в централизованном хранилище. Но тот факт, что многие из этих сервисов позволяют мне «выходить из всех других местоположений», является хорошим индикатором того, что, если они вообще используют токены, они, по крайней мере, «поддерживаются» полу-традиционной моделью сеанса ,

Statefulness не обязательно плохая вещь, но вы должны понимать разницу между приложениями с состоянием и приложениями без сохранения состояния. Короче говоря, приложения с отслеживанием состояния хранят информацию о текущем сеансе, а приложения без сохранения состояния - нет. Информация, хранимая постоянно как часть учетной записи пользователя, может храниться или не сохраняться в сеансе, но хранение информации, связанной с учетной записью пользователя, само по себе не делает приложение сохраняющим состояние. Statefulness требует, чтобы сервер поддерживал информацию о сеансе текущего пользователя помимо того, что поддерживает браузер клиента. Например, клиент может пройти аутентификацию и получить cookie-файл JSESSIONID, который он затем отправляет на сервер с каждым запросом. Если сервер начинает хранить содержимое в области сеанса приложения на основе этого JSESSIONID, он становится состоящим.

безгражданство

Под сохранением состояния мы подразумеваем, что сервер и клиент не поддерживают текущую информацию о сеансе пользователя. Клиент и сервер могут использовать токен некоторой формы для обеспечения аутентификации между запросами, но другая текущая информация не сохраняется. Типичным вариантом использования такого решения может быть новостной сайт, где большинство пользователей (новых потребителей) потребляют информацию, но не производят информацию, которая возвращается на сайт. В таких случаях сайту не нужно хранить какую-либо информацию о текущем сеансе пользователя. Обратите внимание, что сайт может по-прежнему использовать куки для идентификации пользователя и хранить информацию об использовании сайта этим пользователем, но это все равно может рассматриваться как не сохраняющее состояния, поскольку все записанное может быть транзакционным, например, по той ссылке, по которой щелкнул пользователь, которая может быть записана сервер, но не поддерживается в пользовательском сеансе.

Statefulness на сервере

На сервере приложение с сохранением состояния сохраняет информацию о состоянии текущих пользователей. Этот подход обычно включает использование файлов cookie для идентификации системы пользователя, чтобы можно было поддерживать состояние на сервере между запросами. Сеансы могут или не могут быть аутентифицированы, в зависимости от контекста приложения. Серверные приложения с сохранением состояния предлагают преимущество кэширования информации о состоянии пользователя на сервере, ускорения поиска и времени отклика страницы. С другой стороны, хранение информации в области сеанса является дорогостоящим, а в масштабе это становится очень ресурсоемким. Это также создает потенциальный вектор атаки для хакеров, пытающихся перехватить идентификаторы сеансов и украсть сеансы пользователей. Серверные приложения с отслеживанием состояния также сталкиваются с проблемой защиты пользовательских сеансов от непредвиденных прерываний обслуживания, например сбоя сервера.

Statefulness на клиенте

Используя JavaScript и современные браузерные технологии, такие как sessionStorage, приложение теперь может легко сохранять информацию о состоянии сеанса пользователя на устройстве этого пользователя. В целом, приложение все еще может считаться состоящим из состояния, но работа по поддержанию состояния была перенесена на клиента. Этот подход имеет большое преимущество (для сопровождающего веб-приложения) по сравнению с поддержанием состояния на сервере в том смысле, что каждый пользователь, по сути, поддерживает свое собственное состояние, и нет никакой нагрузки на инфраструктуру сервера. В масштабах сети такой архитектурный выбор имеет огромные последствия для затрат на оборудование и электроэнергию. Поддержание состояния сервера может буквально стоить миллионы долларов в год. Переход на систему, поддерживающую состояние клиента, может сэкономить миллионы долларов в год.

Жетоны против печенья

Cookies действуют как идентификаторы для клиентских устройств / браузеров. Они могут использоваться для хранения всевозможных вещей, но обычно они хранят некоторую форму идентификатора, такую ​​как CFID / CFTOKEN в приложениях CFML. Куки-файлы могут быть настроены на длительное использование в браузере пользователя, что позволяет выполнять такие вещи, как поддержание аутентификации в приложении между сеансами браузера. Куки-файлы также могут быть установлены только для памяти, поэтому они истекают, когда пользователь закрывает браузер.

Токены, как правило, являются своего рода идентифицирующей информацией о пользователе, которая генерируется на сервере (с использованием шифрования для шифрования информации), передается клиенту и возвращается на сервер с последующим запросом. Они могут быть переданы в заголовке запроса и ответа, что является общим шаблоном в одностраничных приложениях. В идеале каждый запрос / ответ приводит к генерации нового токена, поэтому токены не могут быть перехвачены и использованы злоумышленником позднее.

Одностраничные приложения и состояние клиента

С помощью SPA информация о состоянии загружается в браузер клиента и сохраняется там. Когда состояние изменяется, например, вы публикуете обновление для своей учетной записи в социальной сети, клиент передает эту новую транзакцию на сервер. В этом случае сервер сохраняет это обновление в постоянном хранилище данных, таком как база данных, и передает клиенту любую информацию, необходимую для синхронизации с сервером, на основе обновления (например, идентификатор для обновления).

Обратите внимание, что этот шаблон хранения состояния на клиенте предлагает преимущества для онлайн / офлайнового взаимодействия в том, что вы можете быть отключены от сервера, оставаясь при этом несколько пригодным для использования приложением. Twitter является хорошим примером этого случая, когда вы можете просмотреть все загруженные клиентские части в своем фиде Twitter, даже если вы отключены от приложения сервера Twitter. Этот шаблон также создает сложность в синхронизации между сервером и клиентом, что является отдельной темой. Сложности решения являются компромиссом для возможности поддерживать состояние на клиенте.

Statefulness на клиенте заставляет веб-приложения чувствовать и вести себя как традиционные настольные приложения. В отличие от настольных приложений, вы обычно не загружаете всю информацию своей учетной записи в сеанс клиента в браузере. Это во многих случаях было бы нецелесообразным и приводило к плохому опыту. Можете ли вы представить себе попытку загрузить весь ящик Gmail в браузер? Вместо этого клиент хранит информацию, например, какую метку / папку вы просматриваете и где в списке писем в этой папке вы просматриваете. Балансирование того, какую информацию о состоянии поддерживать и что запрашивать по мере необходимости, является еще одной инженерной задачей этого шаблона, и опять же, он представляет собой компромисс между практичностью и предоставлением хорошего пользовательского опыта.

Тележки для покупок и тому подобное

Что касается специфики, например, корзин для покупок, то это действительно зависит от решения. Корзина для покупок может храниться в базе данных на сервере, она может храниться только в объеме сеанса на сервере или даже может храниться на клиенте. Amazon имеет постоянные корзины покупок для зарегистрированных пользователей и «временные» корзины для анонимных пользователей, хотя эти корзины в некоторой степени постоянны.

Когда вы говорите о чем-то вроде Google, который на самом деле представляет собой набор различных приложений, принадлежащих одному бренду, они, вероятно, не разделяют общую архитектуру, и каждое из них построено так, чтобы наилучшим образом удовлетворить потребности своих пользователей. Если вы хотите узнать, как создается сайт, откройте инструменты разработчика в своем браузере и посмотрите на него. Проверьте наличие файлов cookie, просмотрите сетевой трафик и посмотрите, как он работает.

Извините, если этот ответ немного гремит, но полнота - сложная тема.

Не следует избегать сессий и файлов cookie. Вы все еще можете иметь их с веб-приложениями без сохранения состояния.

Существует большая разница между Java и Ruby on Rails. Приложения Java сохранят сеанс в памяти, используя ключ сеанса, сохраненный в файле cookie. Это быстро восстановить состояние пользователя и корзину. Однако вы всегда должны использовать один и тот же сервер во время сеанса.

Приложения Rails хранят идентификатор пользователя в подписанном зашифрованном файле cookie. Это не может быть подделано. Когда вы загружаете страницу, веб-приложение выбирает ваше состояние, пользователя и корзину из базы данных. Это медленнее, но главное, вы можете поразить любой экземпляр ! Это позволяет вам перезапускать, масштабировать, выключать экземпляры по желанию. Очень удобно. Это также можно сделать быстрее с помощью общей, находящейся в памяти, кеш-базы данных, такой как 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 Service - это поможет избежать сохранения состояния на стороне сервера. В лучшем случае это также позволяет избежать сохранения какого-либо состояния в базе данных или других постоянных хранилищах на сервере. Чтобы было понятно, я говорю о состоянии, а не о данных в целом. Кажется, что некоторые парни все путают.

Связь без сохранения состояния имеет несколько преимуществ, особенно в отношении масштабируемости и доступности.

Лучшим подходом является использование токенов, которые не сохраняют состояния, поскольку на сервере ничего не хранится.

Это правда (для определенных протоколов аутентификации и авторизации). Токены могут (но не сами по себе) предоставлять всю информацию в запросе, которая необходима для аутентификации пользователя или авторизации действия. Для примера взгляните на JWT .

Поэтому я пытаюсь понять, как веб-приложения могут быть без сохранения состояния, когда для моего сеанса хранятся данные (например, элементы в корзине)? Хранятся ли они где-то в базе данных, а затем периодически удаляются? Как это работает, когда вы используете токен вместо куки?

Что касается примера корзины. Нет проблем хранить все элементы корзины на стороне клиента без использования сеанса или файлов cookie. Вы можете найти пример на smashingmagazine.com . Но также возможно реализовать корзину покупок без сохранения состояния с cookie-файлами (по крайней мере, если ваш ассортимент не такой большой и вам достаточно 4 КБ).

Не поймите меня неправильно, это не значит, что вы должны внедрить корзину покупок без сохранения состояния любой ценой. Amazon или другие крупные платформы для онлайн-покупок используют реализации корзины с отслеживанием состояния, потому что для них важнее пользовательский опыт и удобство использования, чем соответствие техническим нефункциональным требованиям, таким как масштабируемость.

Как правило, токены не используются для хранения информации, такой как элементы корзины. Они используются для аутентификации и авторизации без сохранения состояния.

И затем, в качестве связанного вопроса, являются ли главные сайты (Amazon, Google, Facebook, Twitter и т. Д.) Фактически без гражданства? Они используют токены или куки (или оба)?

Если вы спрашиваете, используют ли они куки или токены для аутентификации, ответ - оба. Для пользователей в основном куки для технических клиентов в основном используются токены.

ОК, правило, которое вы цитируете, технически неверно. Все слои веб-приложения имеют состояние.

Целью правила является «не держать на стороне сервера состояния сеанса».

То есть переменные сеанса в ASP , которые обычно использовались для таких вещей, как элементы в корзине / имя пользователя и т. Д.

Причина в том, что вам не хватит памяти на сервере, поскольку ваше приложение набирает больше пользователей. Перемещение хранилища в базу данных или общий кэш не решает проблему, поскольку у вас все еще есть узкое место.

Чтобы поддерживать состояние приложения для пользователя без решения этой проблемы, переместите состояние на сторону клиента. Например, поместите элементы корзины в файл cookie или в более сложное хранилище на стороне клиента.

Поскольку количество клиентов зависит от количества пользователей, ваше приложение в целом не будет иметь узких мест и будет хорошо масштабироваться.