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

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

Обновить

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

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

Обновить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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