Сколько накладных расходов накладывает SSL?

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

Обновление

Существует вопрос о HTTPS и HTTP, но мне интересно посмотреть ниже в стеке.

(Я заменил фразу "порядок величины", чтобы избежать путаницы, я использовал ее как неофициальный жаргон, а не в формальном смысле CompSci. Конечно, если бы я имел в виду это формально, как истинный выродка, я бы подумал двоичный, а не десятичный!; -)

Обновление

В запросе в комментарии предположим, что мы говорим о сообщениях хорошего размера (диапазон 1k-10k) по постоянным соединениям. Таким образом, настройка соединения и накладные расходы пакетов не являются значимыми.

ОТВЕТЫ

Ответ 1

Порядок величины: ноль.

Другими словами, вы не увидите, что ваша пропускная способность сокращается наполовину или что-то в этом роде, когда вы добавляете TLS. Ответы на "повторяющийся" вопрос в значительной степени зависят от производительности приложения и того, как это сравнивается с накладными расходами SSL. Этот вопрос специально исключает обработку приложений и пытается сравнить только SSL-протокол SSL. Хотя имеет смысл сделать глобальный взгляд на производительность при оптимизации, это не то, о чем задается этот вопрос.

Основными издержками SSL являются рукопожатие. То, что происходит дорогостоящая асимметричная криптография. После переговоров используются относительно эффективные симметричные шифры. Поэтому очень полезно включить сеансы SSL для вашего HTTPS-сервиса, где выполняется много соединений. Для долговременного соединения этот "конечный эффект" не столь значителен, и сеансы не так полезны.

Здесь интересный анекдот. Когда Google переключил Gmail на использование HTTPS, дополнительных ресурсов не требовалось; нет сетевого оборудования, нет новых хостов. Это только увеличило загрузку процессора примерно на 1%.

Ответ 2

I second @erickson: Чистая скорость передачи данных ничтожно мала. Современные процессоры достигают пропускной способности крипто /AES в несколько сотен Мбит/с. Таким образом, если вы не находитесь в системе с ограниченными ресурсами (мобильный телефон), TLS/SSL достаточно быстр, чтобы перемещать данные вокруг.

Но имейте в виду, что шифрование значительно упрощает кеширование и балансировку нагрузки. Это может привести к огромному снижению производительности.

Но настройка соединения - действительно стоппер для многих приложений. При низкой пропускной способности, высокой потери пакетов, подключении с высокой задержкой (мобильное устройство в сельской местности) дополнительные обратные вызовы, требуемые TLS, могут сделать что-то медленное во что-то непригодное.

Например, нам пришлось отказаться от требования шифрования для доступа к некоторым нашим внутренним веб-приложениям - они, где рядом с непригодными для использования в Китае.

Ответ 3

Предполагая, что вы не считаете настройку соединения (как указано в обновлении), это сильно зависит от выбранного шифра. Накладные расходы на сеть (с точки зрения пропускной способности) будут незначительными. На процессорные ресурсы будут преобладать криптография. На моем мобильном Core i5 я могу зашифровать около 250 МБ в секунду с RC4 на одном ядре. (RC4 - это то, что вы должны выбрать для максимальной производительности.) AES медленнее, обеспечивая "только" около 50 МБ/с. Таким образом, если вы выберете правильные шифры, вам не удастся удержать одно текущее ядро, занятое криптозатратами, даже если у вас есть полностью используемая линия 1 Гбит. [ Изменить: RC4 не следует использовать, поскольку он больше не защищен. Однако аппаратная поддержка AES теперь присутствует во многих процессорах, что делает шифрование AES очень быстрым на таких платформах.]

Установление соединения, однако, отличается. В зависимости от реализации (например, поддержка ложного запуска TLS), он будет добавлять круглые поездки, что может вызвать заметные задержки. Кроме того, дорогая криптография имеет место при первом установлении соединения (вышеупомянутый процессор может принимать только 14 подключений на ядро ​​в секунду, если вы глупо использовали 4096-битные ключи и 100, если используете 2048-битные ключи). При последующих подключениях предыдущие сеансы часто используются повторно, избегая дорогого криптования.

Итак, суммируем:

Передача по установленному соединению:

  • Задержка: почти нет
  • CPU: пренебрежимо малый
  • Полоса пропускания: незначительная

Первое установление соединения:

  • Задержка: дополнительные круглые поездки
  • Полоса пропускания: несколько килобайт (сертификаты)
  • ЦП на клиенте: среда
  • Процессор на сервере: высокий

Последующие установки подключения:

  • Задержка: дополнительный раунд (не уверен, что один или несколько, может быть зависимым от реализации)
  • Полоса пропускания: незначительная
  • CPU: почти нет