Пусть балансировщик нагрузки передаст зашифрованные SSL/TLS данные на серверы. Интересно, как обрабатывается хэншейк, если установлено новое HTTPS-соединение с клиентом: хэндшейк — это коммуникация с отслеживанием состояния. Например, чтобы проверить завершенное сообщение клиента, серверу необходимо знать все сообщения хэндшейка, которыми обменялись сервер (ферма) и клиент до сих пор. Следовательно, насколько я могу судить, есть три возможности:
Данные SSL/TLS хранятся в кэше, который используется всеми серверами.
Содержимое сообщений о рукопожатии реплицируется на все серверы.
Балансировщик нагрузки направляет все сообщения о рукопожатии от клиента на один и тот же сервер.
Вопрос: Какой сценарий обычно используется в такой среде? Есть ли какие-то дополнительные политики в обработке рукопожатий, которые я пропустил?
Добавлен:Я столкнулся с утверждением, что мой вопрос является дубликатом, и мне сказали отредактировать мой вопрос, чтобы объяснить, чем он отличается отБалансировка нагрузки и стратегии HTTPS. Итак, вот мое сравнение между моим вопросом и другим вопросом:
а) Я придумал три варианта обработки состояния https в среде балансировки нагрузки и спросил, какие из них (или, может быть, другие) используются на практике.
b) В другом вопросе OP использует вариант 3 («тот же сервер»), т. е. все запросы с одинаковым IP направляются на один и тот же сервер. Однако, поскольку большинство их клиентов используют один и тот же IP, lb работает не очень хорошо, и OP просит найти выход. Четыре с половиной из пяти ответов дают предложения, которые, по сути, сохраняют вариант 3 выше. Одну часть ответа там («DNS для целевого сервера») я не понял.
Так что вопрос все еще в том, используются ли на практике варианты 1 («кэш ssl») и 2 («репликация данных ssl hanshake»). Статьяhttp://wtarreau.blogspot.de/2006/11/making-applications-scalable-with-load.htmlпо-видимому, предпочтение отдается варианту 1 (см. «4. Выделенная ферма кэширования SSL»).
решение1
Если требуется наличие HTTPS на всех этапах настройки, проще/более целесообразно организовать рукопожатие между клиентом и LB, а затем создать отдельный набор сертификатов между LB и серверами.
SSL passthrough возможен, и некоторые CDN его предлагают. Насколько я понимаю, весь трафик пересылается как есть, но это не позволяет балансировать нагрузку.
Чтобы это работало, вам понадобится привязка сеанса к уровню LB.
решение2
Вы можете реализовать SSL-пропуск через TCP-прокси-серверы в Nginx.
https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/