Скільки накладних витрат накладає SSL?


168

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

Оновлення

Є питання щодо HTTPS проти HTTP , але мені цікаво дивитись нижче в стеку.

(Я замінив фразу "порядок масштабів", щоб уникнути плутанини; я використовував це як неформальний жаргон, а не в формальному сенсі CompSci. Звичайно, якби я мав на увазі це формально, як справжній виродник, я б думав над бінарним, а не десятковий! ;-)

Оновлення

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


Ви можете поглянути на це подібне питання .
Дарин Димитров

1
Чи можете ви трохи більше охарактеризувати вашу заявку? Наприклад, чи встановлюється багато короткочасних зв’язків? Під час з'єднання наскільки великим є індивідуальне повідомлення? (Наприклад, можливо, ви стираєте кожне натискання клавіш разом із Telnet через тунель SSL, або, можливо, ви копіюєте файли журналу 1 Tb.)
erickson

Відповіді:


178

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

Іншими словами, ви не побачите свою пропускну здатність скоротити навпіл, або щось подібне, коли ви додасте TLS. Відповіді на "повторюваний" питання сильно зосереджуються на продуктивності програми та тому, як це порівнюється з накладними витратами SSL. Це питання спеціально виключає обробку додатків і прагне порівняти лише не-SSL з SSL. Хоча має сенс зайнятися глобальним поглядом на ефективність при оптимізації, але це питання не задається.

Основні накладні витрати SSL - це рукостискання. Ось тут і трапляється дорога асиметрична криптографія. Після узгодження застосовуються відносно ефективні симетричні шифри. Ось чому може бути дуже корисно ввімкнути сеанси SSL для вашої служби HTTPS, де проводиться безліч з'єднань. Для довгоживучого зв'язку цей "кінцевий ефект" не настільки суттєвий, а сеанси не настільки корисні.


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


6
Як "увімкнути сеанси SSL для вашої служби HTTPS"? Який хороший ресурс, щоб дізнатися про це?
Джастін Вінсент

1
Увімкнення сеансів SSL залежить від сервера. Прочитайте посібник для свого сервера.
erickson

7
@Bart van Heukelom - Продовження життя допоможе тримати відкритим розетку (і з'єднання SSL) довше, що допомагає. Але сеанси SSL призводять до того, що узгоджені криптографічні параметри "запам'ятовуються" від сокета до сокета. Таким чином, HTTP-режим зберігання буде живим корисним для завантаження однієї веб-сторінки з посиланням на неї, але через декілька секунд це з'єднання закриється. Через три хвилини, скажімо, під час отримання іншої сторінки сеанс SSL дозволяє відновити з'єднання SSL, не повторюючи повне рукостискання. Зокрема, повільний обмін ключами з криптовалютою з відкритим ключем можна пропустити.
erickson

2
@Тоні у вас є приклади реального світу, коли TLS додає більше ніж кілька відсотків накладних витрат? Моя відповідь така ж загальна, як і питання. Якщо у вас є інший процес, будь ласка, поділіться ним.
erickson

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

39

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

Але майте на увазі, що шифрування ускладнює кешування та балансування завантаження набагато складніше. Це може призвести до величезного штрафу за продуктивність.

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

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


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

3
Китайська цензура в Інтернеті та намагається нюхати трафік кожного не є новиною. З огляду на 4 роки, ви можете подумати, що це був MSA MITMing на шляху до вашого сайту.
Євген Бересовський

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

12

Якщо припустити, що ви не враховуєте налаштування з'єднання (як ви вказали у своєму оновлення), це сильно залежить від обраного шифру. Накладні витрати мережі (з точки зору пропускної здатності) будуть незначними. На центральних процесорах буде домінувати криптовалюта. На своєму мобільному Core i5 я можу зашифровувати близько 250 Мб в секунду за допомогою RC4 на одному ядрі. (RC4 - це те, що слід вибрати для досягнення максимальної продуктивності.) AES повільніше, забезпечуючи "лише" близько 50 Мб / с. Отже, якщо ви виберете правильні шифри, вам не вдасться тримати жодне поточне ядро, зайняте криптовалютою, навіть якщо у вас є повністю використана лінія 1 Гбіт. [ Редагувати : RC4 не слід використовувати, оскільки він більше не захищений. Однак апаратна підтримка AES зараз присутня у багатьох процесорах, що робить шифрування AES дійсно швидким на таких платформах.]

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

Отже, підсумовуючи:

Передача по встановленому з'єднанню:

  • Затримка: майже жодна
  • ЦП: незначний
  • Пропускна здатність: незначна

Перше встановлення з'єднання:

  • Затримка: додаткові туди-назад
  • Пропускна здатність: кілька кілобайт (сертифікати)
  • CPU для клієнта: середній
  • Процесор на сервері: високий

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

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

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