Эффективное завершение большого количества SSL-соединений

Question

Недавно я настроил сервер веб-сокетов на базе Node.js, который был протестирован для обработки около 2000 новых запросов на подключение в секунду для небольшого экземпляра EC2 (m1.small). Учитывая стоимость экземпляра m1.small и возможность разместить несколько экземпляров за прокси-сервером с поддержкой WebSocket, таким как HAProxy, мы очень довольны результатами.

Однако мы поняли, что еще не проводили никакого тестирования с использованием SSL, поэтому изучили несколько вариантов SSL. Стало очевидным, что разрыв SSL-соединений на прокси-сервере идеален, потому что тогда прокси-сервер может проверять трафик и вставлять заголовки, такие как X-Forward-For, чтобы сервер знал, с какого IP-адреса поступил запрос.

Итак, я рассмотрел ряд решений, таких как Pound, Stunnel и Stud, которые позволили прервать входящие соединения на 443, а затем передать их на HAProxy через порт 80, который, в свою очередь, передает соединение на веб-серверы. , Однако, к сожалению, я обнаружил, что отправка трафика на прокси-сервер завершения SSL на экземпляре c1.medium (высокая загрузка ЦП) очень быстро потребляет все ресурсы ЦП и только со скоростью около 50 запросов в секунду. Я попытался использовать все три решения, перечисленных выше, и все они работали примерно так же, как я предполагаю, что все они в любом случае полагаются на OpenSSL. Я попытался использовать 64-битный очень большой экземпляр High CPU (c1.xlarge) и обнаружил, что производительность масштабируется только линейно в зависимости от стоимости. Таким образом, исходя из цен EC2, мне нужно было бы заплатить примерно 600 долл. / М за 200 запросов SSL в секунду, а не 60 долл. / М за 2000 запросов без SSL в секунду. Первая цена становится экономически нежизнеспособной очень быстро, когда мы начинаем планировать принимать 1000 или 10000 запросов в секунду.

Я также пытался завершить SSL с помощью https-сервера Node.js, и производительность была очень похожа на Pound, Stunnel и Stud, поэтому нет явного преимущества для этого подхода.

Так что я надеюсь, что кто-то может помочь с советами, как мне обойти эту нелепую стоимость, которую мы должны заплатить, чтобы обеспечить SSL-соединения. Я слышал, что аппаратные ускорители SSL обеспечивают гораздо лучшую производительность, поскольку аппаратные средства предназначены для шифрования и дешифрования SSL, но поскольку в настоящее время мы используем Amazon EC2 для всех наших серверов, использование аппаратных ускорителей SSL невозможно, если у нас нет отдельных данных. центр с физическими серверами. Я просто изо всех сил пытаюсь понять, как такие сервисы, как Amazon, Google, Facebook, могут предоставлять весь свой трафик через SSL, когда стоимость этого очень высока. Там должно быть лучшее решение.

Любой совет или идеи будут с благодарностью.

Спасибо Matt

Answer 1

Я не знаю много о мощности ЦП, доступной в разных экземплярах EC2, но я полагаю, что ваша проблема не в выборе вами прокси-программного обеспечения с TLS-завершением, а в его конфигурации. Я предполагаю, что без какой-либо конфигурации все они предложат все наборы шифров, которые они поддерживают, включая (очень) медленные. И они, вероятно, позволят клиенту выбрать тот, который ему нравится больше всего.

Не все комплекты шифров TLS одинаковы, некоторые имеют более высокую стоимость ЦП, чем другие, будь то обмен ключами или сам шифр. В зависимости от используемого программного обеспечения, должен быть способ указать строку шифров, которые принимает сервер (а также способ заставить сервер настаивать на этом). Для OpenSSL они работают следующим образом: http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS

Если вы стремитесь к скорости, по крайней мере, убедитесь, что вы не используете шифры, которые используют обмен ключами Диффи-Хеллмана (не эллиптической кривой). Чтобы отключить наборы шифров с помощью обмена ключами DH, убедитесь, что в какой-то момент строка содержит !DH. Вы можете проверить, какая строка приводит к тому, что шифры доступны, например, openssl ciphers -v 'HIGH:!aNULL:!DH:!ECDH'.

Эта строка отключает как нормальный обмен ключами Диффи-Хеллмана, так и обменом Диффи-Хеллмана по эллиптической кривой. Это, вероятно, оставляет только обмен ключами RSA, в зависимости от вашей версии OpenSSL.

Что касается шифров, вам, вероятно, следует протестировать на предполагаемом оборудовании EC2. Без аппаратного ускорения вы, вероятно, предпочтете RC4, а не AES128, а не AES256, а не все остальное, по крайней мере в соответствии с этим тестом .

Я также предлагаю прочитать этот замечательный пост , особенно на первой просвещающей диаграмме, показывающей влияние DH на производительность рукопожатия TLS.

Наконец, убедитесь, что вы используете кеширование сеансов TLS. Это также экономит некоторые ресурсы процессора.

Answer 2

Я только что понял, что Amazon Elastic Load Balancer очень медленный для терминации SSL ... Я провел простой тест на www.blitz.io (не имеет отношения, только клиент) с 1 до 250 одновременных подключений в течение 1 минуты. Это ужасно провалилось ... Но если я сделаю TCP 443 на внешнем интерфейсе ELB и TCP 443 на внутреннем без сертификата, он уничтожит ЦП небольшого экземпляра при запуске IIS и сертификат SSL на этом экземпляре. Мне нужны только рукопожатия, это простой веб-сервис, обслуживающий клиентов со всего мира. Новая настройка соединения и разрыв связи каждый раз.

Как я могу создать веб-службу SSL с высоким трафиком, желательно с SSL вплоть до серверной части для строгого соответствия требованиям безопасности?

Answer 3

Мне также интересно, как это сделать эффективно. Завершение AWS ssl ужасно медленно, но, возможно, есть какой-то способ улучшить его производительность. Стад казался многообещающим, но, как вы упомянули, также имеет большую стоимость процессора.

Answer 4

Производительность https-сервера Node.js очень похожа на Pound, Stunnel и Stud, и у этого подхода нет явных преимуществ.