Предположим, у меня есть балансировщик нагрузки на уровне TCP, который передает TCP-пакеты между одним из двух внутренних HTTPS-серверов и клиентом. Чтобы гарантировать отсутствие проблем с шифрованием, балансировщик нагрузки должен будет вести таблицу, чтобы гарантировать, что IP-адрес клиента X всегда находится на сервере A HTTPS, а IP-адрес клиента Y находится на сервере B HTTPS и т. Д.
Предположим, что клиент мобильный, что произойдет при переключении, например, с протокола интернет-соединения 3G на 1X? В этом случае (почти наверняка) происходит изменение IP-адреса. Что будет с пользователем?
Если у вас есть балансировщик нагрузки с хорошим пониманием HTTP (большинство из них), вы обычно можете настроить «привязку» к данному реальному серверу на основе файлов cookie. Балансировщик нагрузки вставит cookie в ответ сервера с уникальным значением для каждого возможного реального сервера. При последующих запросах к тому же домену хорошо настроенный браузер будет отправлять обратно тот же файл cookie, который балансировщик нагрузки будет читать и использовать для перенаправления обратно на тот же сервер, что и раньше.
Это будет зависеть от реализации конкретного балансировщика нагрузки относительно того, учитывает ли он это значение cookie для разных исходных IP-адресов или просто вернет его в круговой (или взвешенный) пул, но большинство, с которыми я работал, просто используйте cookie, если существует «липкая» конфигурация.
Ваши большие проблемы будут зависеть от того, как вы примените свой сертификат SSL. Ты будешь иметь чтобы балансировщик нагрузки выполнял шифрование / дешифрование SSL, чтобы это работало. Если сертификат SSL применяется к сервер, балансировщик нагрузки не сможет проверять базовые данные HTTP в зашифрованном туннеле, поэтому сможет выполнять только балансировку нагрузки TCP (т. е. взвешенную или циклическую). Если эта настройка обязательный (например, в рамках какого-либо пункта контракта о сквозном шифровании) вам нужно будет настроить правила, чтобы один сервер имел преимущество перед другим, за исключением случаев, когда он недоступен (например, настроить его как резервную резервную копию, а не служба балансировки нагрузки) - в этом случае вам просто нужно будет принять на себя краткий удар по повторному подключению клиентов. Вы можете смягчить это в приложении, сохранив состояние приложения / сеанса в устойчивом / избыточном (база данных) хранилище и отправив идентификатор сеанса в каждый запрос (с помощью файла cookie, скрытого поля формы или параметра строки запроса) - будьте очень осторожны re: безопасность сеанса, если вы это сделаете.
Другие условия будут применяться к вашему приложению нескольких веб-сайтов с поддержкой SSL на одном IP. Большинство (если не все) устройства балансировки нагрузки / сервера (не могут) связывать несколько сертификатов SSL с одной и той же комбинацией IP / порта. В лучшем случае подстановочный сертификат для *.yourdomain.example.org может быть применен к одному IP / порту (например, для покрытия www.yourdomain.example.org, other.yourdomain.example.org), или вместо него может использоваться сертификат с несколькими SAN (альтернативные имена субъектов) (хотя большинство поставщиков сертификатов не будет выдавать сертификат на основе SAN с SAN для нескольких корневых доменов).