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


168

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

Обновить

Есть вопрос о HTTPS по сравнению с HTTP , но мне интересно посмотреть в стеке.

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

Обновить

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


Вы можете взглянуть на этот похожий вопрос .
Дарин Димитров

1
Можете ли вы охарактеризовать ваше приложение немного больше? Например, устанавливает ли он много недолговечных связей? Насколько велика индивидуальное сообщение при подключении? (Например, возможно, вы сбрасываете каждое нажатие клавиши с помощью Telnet через туннель SSL, или, возможно, вы копируете файлы журнала
объемом

Ответы:


178

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

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

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


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


6
Как вы «включаете сеансы SSL для своей службы HTTPS»? Какой хороший ресурс, чтобы узнать об этом?
Джастин Винсент

1
Включение сеансов SSL зависит от сервера. Прочтите руководство для вашего сервера.
erickson 29.10.10

7
@Bart van Heukelom - Keep-alive поможет дольше держать сокет (и соединение SSL) открытым, что помогает. Но сеансы SSL приводят к тому, что согласованные криптографические параметры «запоминаются» от сокета к сокету. Поэтому HTTP keep-alive был бы полезен для загрузки одной веб-страницы с ссылочным содержимым, но через несколько секунд это соединение закроется. Через три минуты, скажем, когда выбирается другая страница, сеанс SSL позволяет восстановить соединение SSL без повторения полного рукопожатия. В частности, медленный обмен ключами с шифрованием с открытым ключом может быть пропущен.
Эриксон

2
@ Тони, есть ли у вас примеры из реальной жизни, где TLS увеличивает накладные расходы более чем на несколько процентов? Мой ответ такой же общий, как и вопрос. Если у вас есть другой дубль, пожалуйста, поделитесь им.
Эриксон

3
@ Тони Я видел, что простые сокеты превосходят SSL-сокеты в 42 раза по объему при записи по одному байту за раз, что является наихудшим случаем. Никогда не видел 250x. Я провел обширный эксперимент по Интернету с 1700 точками данных, где общий результат состоял в том, что незашифрованные сокеты были не лучше, чем в три раза быстрее, чем SSL, используя программирование, не более сложное, чем буферизация и очистка. JSSE, вероятно, Java 5 с указанием даты эксперимента.
Маркиз Лорн

39

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

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

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

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


20
Оглядываясь назад на 4 года: возможно, Китай просто намеренно испортил весь трафик SSL / TLS.
максимум

3
Китайская цензура интернета и попытка понюхать весь трафик - не совсем новость. Но если вспомнить 4 года назад, вы бы подумали, что это MITMing АНБ на пути к вашему сайту.
Евгений Бересовский

Ключ к ненадежным соединениям состоит в том, чтобы настроить шифрование один раз, а затем избегать повторных переговоров, если в этом нет особой необходимости, и позволить обеим сторонам изменять свои IP-адреса в любое время, не моргнув глазом. (OpenVPN поддерживает это.) ИТ помогает сделать фрагментацию возможной, поскольку MTU может быть очень ненадежным и совершенно нечестным.
Evi1M4chine

12

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

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

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

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

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

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

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

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

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

Важное примечание: никто не должен снова использовать RC4. Протокол следует считать нарушенным, и передача RC4 вместе с ним должна рассматриваться как эквивалент незашифрованной передачи, по крайней мере, для безопасности от шпионских организаций. В настоящее время что-то вроде chacha20-poly1305 настоятельно рекомендуется для массового шифрования из-за его независимости от таких организаций.
Evi1M4chine
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.