Какие накладные расходы налагает SSL?

Question

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

Обновлять

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

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

Обновлять

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

Answer 1

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

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

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

---

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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