Веб-приложение без гражданства, городская легенда?
Я пытаюсь понять token-based authentication в эти дни, который утверждает, что stateless authentication метод. И я встретил концепцию stateless web application,
Ниже приведены некоторые темы, о которых я читал:
- Используйте Spring MVC для разработки веб-приложений без состояния (пока нет ответа)
- Springless Spring MVC
- Как сделать Java-приложение полностью без сохранения состояния
- Как сделать так, чтобы мое веб-приложение не сохраняло состояние, но при этом оставалось полезным?
Сначала я был в восторге от этой идеи. Но все больше и больше я думаю stateless это pseudo-proposition,
Например, предположим, что мы используем клиентский токен для аутентификации, как мы можем сделать статистику по онлайн-пользователям (предположим, что нет журнала)? Должны ли мы хранить токен в БД? Разве это не означает, что мы храним информацию о состоянии на сервере? И даже более того, простая информация о пользователе, такая как имя, возраст и т. Д. В БД, также является некоторой информацией о состоянии?
Я думаю, что реальный вопрос здесь состоит не в том, чтобы сделать веб-приложение без сохранения состояния, а в том, чтобы веб-приложение правильно обрабатывало информацию о состоянии так, чтобы это не поставило под угрозу масштабируемость.
Это зависит от того, как интерпретировать слово stateless:
- Веб-приложение не имеет состояния.
- Или веб-приложение не хранит само состояние.
Я предпочитаю 2, потому что всегда могут быть некоторые inevitable global state (цитата из комментария @deceze к его ответу). И независимо от того, сохраняем ли мы информацию о состоянии в виде веб-хранилища HTML 5, или заголовка HTTP, или скрытых полей формы, или Cookie, это состояние все еще существует. Только то, что оно хранится где-то, кроме как на сервере.
Я что-то упустил? Может ли кто-нибудь пролить свет на это, чтобы я мог освободиться от этой умственной борьбы?
ДОБАВИТЬ 1
Просто прочитайте о книге RESTful Web Services от Leonard Richardson, В главе 4, в конце раздела Statelessness это классифицирует государство в Application State а также Resource State, Таким образом, обычная информация о пользователе и данные, которые я упоминал ранее, такие как изображения и т. Д., Могут быть классифицированы как Resource State, И что stateless относится к Application State, Таким образом, он не нарушает код хранения без сохранения состояния resource state на сервере.
Но в книге также упоминается сценарий, в котором an application key is used to restrict how many times a user can invoke a web service. Он признает, что такая информация не может быть сохранена на стороне клиента. А необходимость хранить его на стороне сервера нарушает код отсутствия состояний и создает проблему схожести сеанса. Он утверждает, что без сохранения состояния можно избежать проблемы схожести сеанса, но не объясняет как. Я действительно не понимаю, как лица без гражданства могут справиться с этим сценарием. Кто-нибудь может пролить свет здесь?
3 ответа
"Состояние" действительно относится только к состоянию между клиентом и сервером. Конечно, сервер будет хранить данные, и технически вы можете увидеть любую модификацию любых данных на сервере как "изменяющееся состояние". Следовательно, применение в этом смысле "без гражданства" не имеет абсолютно никакого практического смысла.
Под "состоянием без сохранения состояния" понимается, находится ли сервер в любое конкретное время в состоянии, позволяющем конкретному клиенту отправить ему конкретный запрос.
Обратите внимание: при традиционном сеансе входа в систему на основе файлов cookie сервер находится в состоянии только принимать запросы от клиента в течение ограниченного периода времени; до тех пор, пока текущий сеанс действителен. Клиент не может предсказать, как долго это будет. В любое время запрос от клиента может завершиться неудачей, поскольку время ожидания некоторого состояния на сервере истекло. В этом случае клиент должен сбросить состояние сервера, выполнив вход снова.
Сравните это с аутентификацией на основе токенов. Токен должен быть действителен бесконечно. По сути, это замена имени пользователя и пароля. Ради обсуждения просто предположим, что клиент отправляет свое имя пользователя и пароль при каждом запросе. Это означает, что каждый запрос может быть аутентифицирован по существу, не требуя, чтобы сервер находился в каком-то определенном временном "состоянии".
Причина, по которой вы используете токены вместо имен пользователей и паролей, двояка:
- Вы можете авторизовать несколько клиентов, используя одну учетную запись, но каждый со своими индивидуально управляемыми учетными данными
- Вы не хотите отправлять "мастер-пароль" туда и обратно с каждым запросом
Конечно, серверу нужно будет отслеживать созданные токены и проверять подлинность по какой-либо базе данных при каждом запросе. Это нерелевантная деталь реализации. Это не отличается от использования файлов cookie сеанса; однако, поскольку токены действительны неопределенно долго, запросы могут быть кэшированы легче, вместо того чтобы дублировать временное хранилище сеансов.
Последний потенциальный аргумент, который требует упреждающего противодействия: в чем разница между неопределенным сеансом и неопределенным токеном и в чем разница, когда сеанс заканчивается, и когда токен может быть отозван?
Когда сеанс заканчивается, его можно восстановить, используя некоторые другие "основные учетные данные" (вход в систему). Токен может / должен заканчиваться только при активном аннулировании, что похоже на аннулирование авторизации на полный доступ к сервису для основных учетных данных и не является частью обычного потока приложения.
Говоря более широко: противопоставьте HTTP-протокол без сохранения состояния протоколу с контролем состояния, например, FTP. В FTP сервер и клиент должны синхронизировать общее состояние. Например, протокол FTP имеет, помимо прочего, CWD Команда для изменения текущего рабочего каталога. То есть, существует представление о том, в каком каталоге "клиент" находится в данный момент времени. Последующие команды ведут себя по-разному в зависимости от того, в каком каталоге они находятся. Это состояние. Вы не можете произвольно отправлять команды, не зная об этом состоянии, иначе вы не сможете предсказать, каким будет результат.
Обмен данными между клиентом и сервером без сохранения состояния в первую очередь упрощает клиентскую сторону, поскольку клиент всегда может предполагать, что он может запросить что-либо от сервера, без необходимости знать состояние сервера ("мой сеанс все еще активен или нет? msgstr "" "на какой каталог это действие повлияет?" Это может помочь в масштабировании реализации сервера, поскольку между всеми серверами должна реплицироваться только статическая информация, а не постоянно меняющийся пул допустимых сеансов и связанных с ними данных.
С архитектурной точки зрения ваша цель должна состоять в том, чтобы иметь как можно больше компонентов без сохранения состояния. Это упростит масштабирование. Например, если ваш веб-сервер хранит локальное хранилище сеансов, это очень затрудняет масштабирование вашего веб-сервера до нескольких экземпляров за балансировщиком нагрузки /CDN. Одним из улучшений является централизация хранилища сеансов в независимой базе данных; теперь у вас может быть несколько веб-серверов без сохранения состояния, которые знают, как получать данные (включая данные сеанса) откуда-то и могут отображать шаблоны, но в остальном полностью взаимозаменяемы.
Однако хранилище сеансов должно быть идеально синхронизировано с каждым, кто пытается получить к нему доступ, что затрудняет его масштабирование. Токены улучшают это, делая изменение данных реже (только когда токены добавляются или удаляются), что означает, что вы можете использовать распределенную базу данных или другой более простой механизм репликации, если вы хотите иметь несколько хранилищ токенов в возможно нескольких местах и / или делать эти данные кэшируются.
Хорошо, я не думаю, что термин веб-приложение без состояния имеет какой-либо смысл. Что имеет смысл, так это протокол без сохранения состояния. А протокол без сохранения состояния - это протокол, который обрабатывает каждый запрос независимо.
Так что в вашем случае, если вы отправляете токен авторизации с каждым запросом, то он не имеет состояния. Вот как HTTP-аутентификация должна работать.
С другой стороны, если вы отправляете токен аутентификации только один раз, и каждый последующий запрос не должен (например, потому что сервер знает, что это TCP-соединение уже аутентифицировано), то это означает, что каждый запрос зависит от запроса аутентификации. Это делает протокол с состоянием.
Протоколы без учета состояния легче масштабировать, проще прокси и т. Д.
Теперь, что касается веб-приложений, термин может иметь или не иметь смысла в зависимости от определения. Я не знаю ничего разумного, хотя.
Примечание: наличие состояния без сохранения состояния не связано с совместным использованием данных между клиентом и сервером.
Я не думаю, что аутентификация без сохранения состояния и приложения без учета состояния связаны с вашим мнением; слово без гражданства используется здесь в двух разных контекстах.
Аутентификация без сохранения состояния - это метод определения того, кем является клиент, без переноса какой-либо информации / состояния из предыдущего запроса или взаимодействия клиента, в отличие, например, от файлов cookie.
Веб-приложения без сохранения состояния? Конечно, они возможны, но это полностью зависит от того, нужно ли сохранять пользовательские данные, то есть действительно ли это зависит от рассматриваемого приложения.