Липкие сессии на балансировщиках нагрузки с HTTP и HTTPS

Как липкие сессии связаны с HTTP и HTTPS;

Если я размещу балансировщик нагрузки перед некоторыми серверами веб-приложений, на которых запущен внешний интерфейс, поддерживающий HTTPS, будут ли сеансы оставаться "закрепленными" на типичном балансировщике нагрузки, в котором в качестве одной из поддерживаемых функций перечисляются "сеансы с привязкой"?

Я понимаю, что этот вопрос частично открыт; Чтобы уточнить, потребуется ли мне балансировщик нагрузки, который поддерживает специфичные для липких сеансов HTTPS, или это "липкие сеансы" - принципал, который функционирует независимо от полезной нагрузки HTTP, независимо от того, зашифрован он или нет?

Спасибо.

2 ответа

Решение

Балансировщики нагрузки могут идентифицировать сеансы с помощью файлов cookie, параметров в URL-адресе и т. Д. Если вы используете https на вашем балансировщике нагрузки, загрузочный балансировщик должен сам выполнить всю обработку SSL, чтобы он мог просматривать сеанс.

Итак, да, вам нужен балансировщик нагрузки, который завершает SSL для клиента, чтобы он мог получить доступ к данным сеанса. (тогда нет виртуального сервера Linux или HAProxy для вас)

Обычно "липкий" является значением по умолчанию для HTTPS, а не "липкий" является значением по умолчанию для HTTP.

Для HTTP необходимо включить липкие сеансы, если часть данных о состоянии сеанса хранится локально на стороне сервера (либо только в оперативной памяти, либо только в локальном хранилище). Например, после проверки подлинности подключения к серверу A его необходимо продолжать маршрутизировать на сервер A, поскольку для сервера B потребуется повторная проверка подлинности.

Если последующие запросы будут успешными независимо от того, на какой сервер они направлены, вам не следует использовать липкие.

Обычно предпочтительным является non-sticky, если ваше приложение его поддерживает.

Другие вопросы по тегам