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

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

обновление

здесь вопрос о HTTPS против HTTP, но мне интересно посмотреть ниже в стек.

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

обновление

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

3 ответов


порядок: ноль.

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

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


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


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

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

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

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


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

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

Итак, подведем итоги:

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

  • задержка: около нет!--16-->
  • CPU: незначительный
  • пропускная способность: л

первое соединение основания:

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

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

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