Сеансовые файлы cookie с балансировкой нагрузки (не липкие сеансы)
Я просмотрел RFC 6265, но не нашел ответа на следующий вопрос.
Я хочу поставить наивный балансировщик нагрузки round-robbin перед несколькими серверами для одного веб-приложения. Балансировщик нагрузки Не предоставляет липкие сеансы. Таким образом, клиент обычно отскакивает от одного сервера приложений к другому при последовательных запросах.
При первом подключении клиент не имеет SID и случайным образом направляется, скажем, на сервер A.
Сервер отправляет файл cookie сеанса, а данное время.
При следующем подключении клиент включает SID с сервера A в заголовки HTTP.
На этот раз клиент случайным образом направляется, скажем, на сервер B.
Сервер B видит SID, который (можно надеяться!) не соответствует ни одному SID, который он выдал.
Что же происходит? Не сервер B просто игнорировать "плохие" Сида, или жаловаться, или проигнорировать просьбу, или что?
Идея в том, что я вообще не хочу использовать сеансовые куки. Я хочу избежать всех сложностей липкости. Но я также знаю, что мои серверы вероятно, будет генерировать - и более того, искать-файлы cookie сеанса в любом случае.
Как я могу убедиться, что серверы просто игнорируют (или еще лучше не устанавливают) сеансовые файлы cookie?
1 ответ:
Я думаю, что ответ на этот вопрос будет сильно отличаться в зависимости от приложения, которое работает на сервере. В то время как любой балансировщик нагрузки имеет липкие сеансы, Работа без них может быть выполнена до тех пор, пока все серверы в пуле могут получить доступ к одному и тому же состоянию сеанса через централизованную базу данных.
Поскольку вы говорите об идентификаторах сеансов, я предполагаю, что приложение действительно полагается на состояние сеанса, чтобы функционировать. В этом случае, если запрос поступил с "плохим" идентификатор сеанса, скорее всего, будет отброшен, и пользователю будет предложено войти в систему-опять же, точное поведение зависит от приложения. Если бы вы полностью отключили файл cookie сеанса, проблема, скорее всего, усугубилась бы, так как даже отсутствие идентификатора, скорее всего, приведет к появлению запроса на вход.
Если вы действительно хотите избежать сложностей в балансировщике нагрузки, вам нужно будет ввести некоторый механизм, с помощью которого все серверы могут обрабатывать запросы от всех сеансов. Как правило, это принимает форму централизованная база данных или другое общее хранилище. Это позволяет поддерживать состояние сеанса независимо от сервера, обрабатывающего этот конкретный запрос.
Поддержание состояния сеанса является одной из точек преткновения (каламбур) балансировки нагрузки, но простое игнорирование или избегание файлов cookie сеанса не является решением.
Comments