Большие веб-сайты могут быть «сбалансированы по нагрузке» на нескольких машинах. Во многих установках с балансировкой нагрузки пользователь может подключиться к любому из базовых компьютеров во время сеанса. Из-за этого существует ряд методов, позволяющих многим машинам совместно использовать пользовательские сеансы.
Выбор метода будет зависеть от стиля балансировки нагрузки, а также от доступности / емкости внутреннего хранилища:
Информация о сеансе сохраняется только в файлах cookie : информация о сеансе (а не только идентификатор сеанса) хранится в файле cookie пользователя. Например, cookie пользователя может содержать содержимое его корзины покупок. Чтобы предотвратить вмешательство пользователей в данные сеанса, HMAC может быть предоставлен вместе с cookie. Этот метод, вероятно, наименее подходит для большинства приложений:
- Бэкэнд-хранилище не требуется
- Пользователю не нужно каждый раз подключаться к одной и той же машине, поэтому можно использовать балансировку нагрузки DNS.
- Нет задержки, связанной с получением информации о сеансе с компьютера базы данных (как это предусмотрено в HTTP-запросе). Полезно, если ваш сайт сбалансирован по нагрузке машинами на разных континентах.
- Количество данных, которые могут быть сохранены в сеансе, ограничено (ограничение размера куки 4K)
- Необходимо использовать шифрование, если пользователь не может видеть содержимое своего сеанса.
- HMAC (или аналогичный) должен использоваться для предотвращения вмешательства пользователя в данные сеанса
- Поскольку данные сеанса не хранятся на стороне сервера, разработчикам сложнее отлаживать
Балансировщик нагрузки всегда направляет пользователя на один и тот же компьютер : многие балансировщики нагрузки могут устанавливать свои собственные куки-файлы сеанса, указывая, с какого бэкэнд-компьютера пользователь отправляет запросы, и направлять их на этот компьютер в будущем. Поскольку пользователь всегда направлен на один и тот же компьютер, совместное использование сеансов между несколькими компьютерами не требуется. Это может быть хорошо в некоторых ситуациях:
- Обработка сеанса существующего приложения, возможно, не должна быть изменена, чтобы стать осведомленной о нескольких машинах
- Для хранения сессий не требуется система общей базы данных (или аналогичная), что может повысить надежность, но за счет сложности
- Отключение бэкэнда завершит все запущенные на нем сеансы пользователей.
- Вывести машины из строя сложнее. Пользователи с сеансами на машине, которые должны быть отключены для технического обслуживания, должны иметь возможность выполнять свои задачи до выключения машины. Для поддержки этого в веб-балансировщиках нагрузки может быть предусмотрена функция «утечки» запросов к определенной бэкэнд-машине.
Общая серверная база данных или хранилище ключей / значений : информация о сеансе хранится в серверной базе данных, к которой все веб-серверы имеют доступ для запроса и обновления. Браузер пользователя сохраняет cookie, содержащий идентификатор (например, идентификатор сеанса), указывающий на информацию о сеансе. Это, наверное, самый чистый метод из трех:
- Пользователь никогда не должен подвергаться хранению информации о сеансе.
- Пользователю не нужно каждый раз подключаться к одной и той же машине, поэтому можно использовать балансировку нагрузки DNS.
- Одним недостатком является узкое место, которое может быть размещено в любой используемой внутренней системе хранения.
- Информация о сеансе может быть истекла и резервное копирование последовательно.
В целом, большинство динамических веб-приложений выполняют несколько запросов к базе данных или запросы к хранилищу ключей / значений, поэтому база данных или хранилище ключей / значений является логическим местом хранения данных сеанса.