Недавно я установил сервер веб-сокетов на основе Node.js, который был протестирован для обработки около 2000 новых запросов на соединение в секунду на небольшом экземпляре EC2 (m1.small). Учитывая стоимость экземпляра m1.small и возможность разместить несколько экземпляров за прокси-сервером с поддержкой WebSocket, таким как HAProxy, мы очень довольны результатами.
Однако мы поняли, что еще не проводили тестирования с использованием SSL, поэтому рассмотрели несколько вариантов SSL. Стало очевидно, что завершение SSL-соединений на прокси-сервере идеально, потому что тогда прокси-сервер может проверять трафик и вставлять заголовки, такие как X-Forward-For, чтобы сервер знал, с какого IP-адреса пришел запрос.
Я рассмотрел решения для завершения SSL, где Pound, stunnel и stud, все из которых позволяли завершать входящие соединения на 443, а затем передавались на HAProxy через порт 80, который, в свою очередь, передает соединение на веб-серверы. Однако, к сожалению, я обнаружил, что отправка трафика на прокси-сервер завершения SSL на экземпляре c1.medium (High CPU) очень быстро потребляет все ресурсы ЦП и только со скоростью около 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, когда это так дорого. Там должно быть лучшее решение.
Будем очень признательны за любые советы или идеи.
Спасибо Мэтт
Во-первых, хорошо для начала тестирования. Мой инстинкт заставляет меня задуматься, какой размер ключа вы используете. Мне кажется, вы сможете прекратить гораздо больше 200 подключений в секунду. Если вы используете размер ключа больше 1024, знайте, что производительность падает очень быстро.
Если вы используете ключ меньшего размера и по-прежнему сталкиваетесь с проблемами, я бы внимательно посмотрел на предложения графического процессора, которые может предложить EC2. SSLShader может быть экономически эффективным переключением после определенного количества подключений в секунду.
Кроме того, стоит изучить упоминание @ceejayoz об Elastic Load Balancer.
Возможно, вы ошиблись при тестировании. Я сомневаюсь, что вы действительно ожидаете 200 уникальных новых посетителей SSL каждую секунду? Если какое-либо из этих подключений является повторным подключением от людей, которые недавно посещали его, вы должны использовать кеширование SSL - такие вещи:
server.on ('newSession', функция (идентификатор, данные) {tlsSessionStore [id] = data;});
server.on ('resumeSession', function (id, cb) {cb (null, tlsSessionStore [id] || null);});
И, конечно же, ваш эталонный тест должен представлять себя в ваших тестах как правильную пропорцию новых новых подключений и возобновленных / повторно используемых сессий, которая имеет смысл для вашего приложения.
Кроме того, выбранные вами шифры и размеры ключей, как упоминалось ранее, вероятно, также влияют на скорость.
Похоже, что скорость SSL зависит от алгоритма и желаемого уровня безопасности, я еще не тестировал свой экземпляр EC2, но в любом случае хотел бы поделиться со всеми некоторыми советами о включении обмена ключами ECDHE в стиле Google с предварительно выбранными алгоритмами SSL, чтобы избежать BEAST и другие неправильные конфигурации SSL.
Несколько хороших ссылок для начала: (ни в одном месте пока нет всего, я должен написать руководство, но до тех пор я сделал этот пост вики-сообществом, если кто-то хочет поделиться ссылками и советами!)
И взгляни на https://www.vbulletin.com/forum/showthread.php/401411-Time-to-improve-the-site-security для разговора о том, почему в наши дни SSL - это не просто SSL.