Существуют ли какие-либо факторы, препятствующие балансировке нагрузки HTTPS по сравнению с балансировкой нагрузки HTTP?
Может ли это быть причиной, почему HTTPS не распространяется на разных сайтах? (на рынке есть дешевые СА)
Это не стоимость сертификата так много (хотя это спорно и, как правило, на основании которых CA один использует и что лицензионные требования ЦС), но стоимость серверов. Балансировка нагрузки HTTPS-трафика и HTTP-трафика также не сильно отличается с точки зрения реализации. Все зависит от затрат. SSL может быть дорогостоящей операцией с точки зрения процессора как для обмена ключами, так и для шифрования / дешифрования данных. Общее количество одновременных пользователей, которые вы можете получить с сервера, будет ниже с HTTPS, чем общее количество одновременных пользователей по HTTP, а это означает, что вам понадобится больше серверов, чтобы делать то же самое.
Хотя они действительно работают очень хорошо, устройства, которые разгружают эти ssl-операции, также могут быть довольно дорогими.
«Традиционные» веб-сайты (в отличие от веб-приложений), как правило, имеют компонент сайта с высокой посещаемостью, который представляет собой строго маркетинговый контент, который в основном представляет собой анонимный трафик без отслеживания состояния. Несмотря на важность для бизнеса пресс-релизов, маркетинговые сообщения, спецификации продуктов, загружаемые или онлайн-демонстрации и т. Д., Все они предназначены для превращения этих анонимных пользователей в покупателей, но зачем шифровать этот анонимный трафик? Я думаю, что администраторы сайтов склонны рассматривать это как неоптимальное и ненужное использование вычислительных ресурсов.
Web 2.0, социальные сети и веб-приложения отличаются друг от друга и должны быть зашифрованы по ssl прежде всего потому, что по самой своей природе не существует анонимности между пользователем и сайтом. В конце концов, первое, что делают в Twitter или Facebook, - это войти в систему.
Я не уверен, что Джеймс прав. Насколько я понимаю, рукопожатие SSL начинается и заканчивается парой запрос / ответ. Даже если HTTPS поддерживает возобновление TLS с помощью ключей сеанса, эти ключи возобновления будут находиться на внешнем балансировщике нагрузки с клиентом, который всегда будет использовать один и тот же балансировщик нагрузки.
При этом вполне возможно выполнить балансировку нагрузки на HTTPS-серверы, и я считаю, что большинство людей этого не делает:
Ваш вопрос кажется немного запутанным.
Если вы имеете в виду, каковы недостатки HTTPS по сравнению с HTTP, то:
1) он намного медленнее - хотя накладные расходы на пропускную способность не так велики, проблема, как всегда, заключается в задержке - SSL требует как минимум 2 дополнительных круговых обходов на запрос.
2) Прокси-серверы не могут кэшировать данные, что делает его еще медленнее
3) Существенное влияние на все, что может потребоваться для обработки, например, брандмауэры контента и балансировщики нагрузки.
Накладные расходы на обработку не так уж велики - все проблемы с производительностью связаны с задержкой в сети - и отключение SSL от веб-сервера не помогает.
Ну, HTTPS - это не без состояния / без установления соединения; клиент должен вернуться к тому же серверу для последующих подключений, потому что ключи сеанса хранятся в кеше на этом сервере. При использовании HTTP, пока контент реплицируется на ваших серверах, не имеет значения, на какой сервер обращается клиент, и они могут быть отправлены на другой сервер при последующих запросах.
Кроме того, одна из основных причин, по которой люди завершают работу SSL на балансировщике нагрузки, - это экономия средств на сертификатах; поместите один сертификат на LB, расшифруйте трафик, передайте на ваши серверы как обычный HTTP, а затем повторно зашифруйте обратный трафик через балансировщик нагрузки.
Я бы посоветовал продолжить чтение процесса подтверждения SSL / TLS: http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail