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

Question

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

Обновление

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

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

Обновление

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

Answer 1

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

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

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

---

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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