Чи є якісь великі відмінності у продуктивності між http та https? Здається, я пам'ятаю, що читав, що HTTPS може бути на п'яту частину швидшим, ніж HTTP. Чи дійсно це для веб-серверів / браузерів поточного покоління? Якщо так, то чи є які-небудь газети для їх підтримки?

На це є дуже проста відповідь: Профілюйте ефективність роботи вашого веб-сервера, щоб побачити, що покарання за ефективність вашої конкретної ситуації. Існує кілька інструментів для порівняння продуктивності HTTP та HTTPS-сервера (JMeter і Visual Studio приходять на думку), і вони досить прості у використанні.

Ніхто не може дати тобі змістовної відповіді без деякої інформації про характер вашого веб-сайту, апаратних засобів, програмного забезпечення та конфігурації мережі.

Як говорили інші, через шифрування буде деякий рівень накладних витрат, але він дуже залежить від:

• Обладнання
• Серверне програмне забезпечення
• Співвідношення динамічного та статичного вмісту
• Відстань клієнта до сервера
• Типова тривалість сеансу
• І т. Д. (Мій особистий улюблений)
• Кеш поведінка клієнтів

З мого досвіду, сервери, які відрізняються великим динамічним контентом, мають менший вплив на HTTPS, оскільки час шифрування (витрата SSL) незначний порівняно із часом створення контенту.

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

Редагувати: Один момент, який підкреслили кілька інших, - це те, що передача SSL - це основна вартість HTTPS. Це правильно, саме тому важлива "типова тривалість сеансу" та "кешування поведінки клієнтів".

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

Кешування клієнта може бути виконано в кілька етапів - від великомасштабного проксі-сервера до індивідуального кешу браузера. Як правило, вміст HTTPS не буде кешовано у спільному кеші (хоча декілька проксі-серверів можуть використовувати поведінку чоловіка-посередника для досягнення цього). Багато браузерів кешують вміст HTTPS для поточного сеансу та часто разів протягом сеансів. Вплив не кешування або менш кешування означає, що клієнти частіше будуть отримувати той самий вміст. Це призводить до збільшення кількості запитів та пропускної спроможності для обслуговування однакової кількості користувачів.

HTTPS вимагає початкового рукостискання, яке може бути дуже повільним. Фактичний об'єм даних, переданих як частина рукостискання, не величезний (як правило, менше 5 кБ), але для дуже малих запитів це може бути досить великим затратою. Однак, як тільки рукостискання зроблено, використовується дуже швидка форма симетричного шифрування, тому накладні витрати є мінімальними. Підсумок: подання великої кількості коротких запитів через HTTPS буде дещо повільніше, ніж HTTP, але якщо ви передасте багато даних в одному запиті, різниця буде незначною.

Однак keepalive - це поведінка за замовчуванням у HTTP / 1.1, тому ви зробите одне рукостискання, а потім безліч запитів через те саме з'єднання. Це суттєво відрізняється для HTTPS. Ви, напевно, маєте профайлювати свій сайт (як це запропонували інші), щоб переконатися, але я підозрюю, що різниця в продуктивності не буде помітна.

Щоб дійсно зрозуміти, як HTTPS збільшить вашу затримку, ви повинні зрозуміти, як встановлюються з'єднання HTTPS. Ось приємна схема . Ключовим моментом є те, що замість того, щоб клієнт отримав дані після 2-х "ножок" (за одну туру, ви відправляєте запит, сервер надсилає відповідь), клієнт не отримає дані, щонайменше, 4 ноги (2 тури) . Отже, якщо для переміщення пакета між клієнтом і сервером потрібно 100 мс, ваш перший запит HTTPS займе не менше 500 мс.

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

Накладні витрати НЕ обумовлені шифруванням. У сучасному процесорі шифрування, необхідне SSL, є тривіальним.

Накладні витрати пов’язані з рукостисканням SSL, які є тривалими і різко збільшують кількість об’їзних поїздок, необхідних для сеансу HTTPS через HTTP.

Виміряйте (використовуючи такий інструмент, як Firebug) час завантаження сторінки, коли сервер знаходиться в кінці імітованого посилання з високою затримкою. Існують інструменти для імітації високої затримки зв'язку - для Linux існує "netem". Порівняйте HTTP з HTTPS в одній програмі.

Затримку можна певною мірою пом'якшити:

• Забезпечення того, що ваш сервер використовує HTTP keepalives - це дозволяє клієнту повторно використовувати сеанси SSL, що дозволяє уникнути необхідності в іншому рукостисканні
• Зменшення кількості запитів до якомога меншої кількості - комбінуючи ресурси, де це можливо (наприклад, .js включає файли, CSS) та заохочуючи кешування на стороні клієнта
• Зменшіть кількість завантажень сторінки, наприклад, завантаживши на сторінку не потрібні дані (можливо, у прихованому HTML-елементі), а потім показавши їх за допомогою клієнтського скрипту.

Оновлення грудня 2014 року

Ви можете легко перевірити різницю між продуктивністю HTTP і HTTPS у власному браузері за допомогою веб-сайту HTTP vs HTTPS Test від AnthumChris : «Ця сторінка вимірює час її завантаження через незахищені HTTP та зашифровані HTTPS-з'єднання. Обидві сторінки завантажують 360 унікальних, не кешованих зображень (всього 2,04 МБ). "

Результати можуть вас здивувати.

Важливо мати сучасні знання про ефективність HTTPS, оскільки Letter Encrypt Certificate Authority почне видавати безкоштовні, автоматизовані та відкриті сертифікати SSL влітку 2015 року завдяки Mozilla, Akamai, Cisco, Electronic Frontier Foundation та IdenTrust.

Оновлення за червень 2015 року

Оновлення програми Let’s Encrypt - прибуття вересня 2015 року:

• Давайте зашифруємо графік запуску (16 червня 2015 р.)
• Давайте шифруємо кореневі та проміжні сертифікати (4 червня 2015 р.)
• Проект Давайте шифруємо Угоду про підписку (21 травня 2015 р.)

Більше інформації у Twitter: @letsencrypt

Для отримання додаткової інформації про продуктивність HTTPS та SSL / TLS див.

• Це TLS все ж швидкий?
• Високопродуктивна мережа веб-переглядачів, Глава 4: Безпека транспортного шару
• Розгін SSL
• Анатомія та ефективність обробки SSL

Для отримання додаткової інформації про важливість використання HTTPS див.

• Чому HTTPS для всього? (Стандарт HTTPS)
• Давайте шифруємося (дослідницька група з питань безпеки в Інтернеті)
• HTTPS Everywhere (Фонд електронних кордонів)

Підводячи підсумок, дозвольте процитувати Іллю Григорика : "У TLS є рівно одна проблема продуктивності: вона використовується недостатньо широко. Все інше можна оптимізувати".

Дякуємо Крису - автору тесту HTTP vs HTTPS Test - за коментарі нижче.

Поточна відповідь не є коректною.

Як вже вказували інші, https вимагає рукостискань і, отже, робить більше TCP / IP туди і назад.

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

Тільки майте на увазі, що затримка від Європи до США може становити близько 200 мс (час торнтрипта).

Ви можете легко виміряти це (для одного випадку користувача) за допомогою HTTPWatch .

На додаток до всього, що згадувалося до цього часу, майте на увазі, що деякі (усі?) Веб-браузери не зберігають кешований вміст, отриманий через HTTPS, на локальному жорсткому диску з міркувань безпеки. Це означає, що з точки зору користувача сторінки з великою кількістю статичного вмісту будуть завантажуватися повільніше після перезавантаження браузера, і з точки зору вашого сервера обсяг запитів на статичний вміст через HTTPS буде вище, ніж було б над HTTP.

На це немає однозначної відповіді.

Шифрування завжди буде споживати більше процесора. Це може бути завантажено спеціалізованим обладнанням у багатьох випадках, а вартість буде змінюватися залежно від обраного алгоритму. 3des дорожче, наприклад, AES. Деякі алгоритми шифрують дорожче, ніж дешифратор. Деякі мають протилежну вартість.

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

Для перехресного інтернет-трафіку ви можете не помітити цієї вартості у швидкості передачі даних, оскільки доступна пропускна здатність занадто мала. Але ви, звичайно, помітите це при використанні процесора на зайнятому сервері.

Я можу сказати вам (як комутований користувач), що одна і та ж сторінка через SSL в кілька разів повільніше, ніж через звичайний HTTP ...

У ряді випадків ефективність впливу рукостискань SSL буде пом'якшена тим, що сеанс SSL може кешуватися на обох кінцях (настільний і серверний). Наприклад, на машинах Windows, наприклад, сеанс SSL може кешуватися до 10 годин. Дивіться http://support.microsoft.com/kb/247658/EN-US . Деякі прискорювачі SSL також матимуть параметри, що дозволяють настроїти час кешування сеансу.

Інший вплив, який слід врахувати, полягає в тому, що статичний вміст, що подається через HTTPS, не буде кешований проксі-серверами, і це може знизити продуктивність для кількох користувачів, які отримують доступ до сайту через один і той же проксі. Це може бути пом’якшено тим фактом, що статичний вміст також буде кешований на настільних комп’ютерах, версії Internet Explorer 6 та 7 кешують статичний вміст HTTPS, якщо не доручено робити інше (Меню інструментів / Параметри Інтернету / Додаткові / Безпека / Не зберігати зашифровані сторінки на диск).

Я зробив невеликий експеримент і отримав 16% різницю у часі для того ж зображення від flickr (233 kb):

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

Зрозуміло, ці цифри залежать від багатьох факторів, таких як продуктивність комп'ютера, швидкість з'єднання, завантаження сервера, QoS на шляху (конкретний мережевий шлях, взятий від браузера до сервера), але це показує загальну ідею: HTTPS повільніше, ніж HTTP, оскільки це вимагає більше операцій для завершення (передача даних SSL та кодування / декодування даних).

Ось чудова стаття (трохи стара, але все ж чудова) про затримку в рукостисканні SSL. Допоміг мені визначити SSL як основну причину сповільнення для клієнтів, які користувалися моїм додатком через повільні Інтернет-з'єднання:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

Оскільки я досліджую ту саму проблему для свого проекту, я знайшов ці слайди. Старіші, але цікаві:

http://www.cs.nyu.edu/artg/research/comppare/comppare_slides/sld001.htm

Тут, здається, є неприємний крайовий випадок: Аякс через перевантажений wifi.

Ajax зазвичай означає, що KeepAlive закінчився через 20 секунд. Однак, wifi означає, що (в ідеалі швидкий) ajax-з'єднання має здійснювати безліч туди-назад. Гірше, що Wi-Fi часто втрачає пакети, і є ретрансляція TCP. У цьому випадку HTTPS працює дуже реально!

Ще TLS швидкий? Так.

• Дивитися: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Читайте: https://istlsfastyet.com/

Існує багато проектів, які мають на меті розмити лінії та зробити HTTPS так само швидко. Як SPDY та mod-spdy .

Порівняння HTTP VS HTTPS PERFORMANCE

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

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

Як видно з діаграми, наведеної вище, є кілька додаткових кроків, які необхідно виконати під час використання HTTPS порівняно з використанням звичайного HTTP. Коли ви робите запит за допомогою HTTPS, потрібно здійснити рукостискання, щоб перевірити справжність запиту. Це рукостискання є додатковим кроком у порівнянні з HTTP-запитом і, на жаль, несе певні накладні витрати.

Щоб зрозуміти наслідки для продуктивності та зрозуміти, чи буде вплив на продуктивність значним, я використовував цей сайт як тестову платформу. Я перейшов на webpagetest.org і застосував інструмент візуального порівняння для порівняння завантаження цього сайту за допомогою HTTPS та HTTP.

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

Ваш сайт може бути різним, і важливо ретельно перевірити його і перевірити вплив на продуктивність, пов’язаний з переходом на HTTPS.

Існує спосіб виміряти це. Інструмент від apache під назвою jmeter вимірює пропускну здатність. Якщо ви налаштували велику вибірку своєї послуги з jmeter, в контрольованому середовищі, з SSL і без нього, ви повинні отримати точне порівняння відносної вартості. Мене зацікавлять ваші результати.

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

Більш важлива відмінність продуктивності полягає в тому, що HTTPS-сеанс відкритий кетпом під час підключення користувача. HTTP-сеанс триває лише для одного запиту.

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

Це майже напевно буде правдою, враховуючи, що SSL вимагає додаткового кроку шифрування, який просто не потрібен HTTP, який не є SLL.

HTTPS дійсно впливає на швидкість сторінки ...

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

Накладні рукостискання HTTPS відображаються в інформації "Час до першого байту" (TTFB). Поширений TTFB становить від менш ніж 100 мілісекунд (найкращий варіант) до понад 1,5 секунд (найгірший випадок). Але, звичайно, з HTTPS це на 500 мілісекунд гірше.

Бездротове підключення 3G може бути 500 мілісекунд або більше. Додаткові відключення подвійні затримки до 1 секунди або більше. Це великий, негативний вплив на продуктивність мобільних пристроїв. Дуже погані новини.

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

Джерело: Pagepipe

Браузери можуть приймати протокол HTTP / 1.1 з HTTP або HTTPS, але браузери можуть обробляти протокол HTTP / 2.0 лише з HTTPS. Різниці в протоколі від HTTP / 1.1 до HTTP / 2.0 роблять HTTP / 2.0, в середньому, в 4-5 разів швидше, ніж HTTP / 1.1. Також сайти, які реалізують HTTPS, більшість роблять це через протокол HTTP / 2.0. Тому HTTPS майже завжди буде швидше, ніж HTTP, просто завдяки різному протоколу, який він зазвичай використовує. Однак, якщо HTTP через HTTP / 1.1 порівнюється з HTTPS через HTTP / 1.1, то HTTP в середньому трохи швидший, ніж HTTPS.

Ось декілька порівнянь, які я запускав за допомогою Chrome (Версія 64):

HTTPS через HTTP / 1.1:

• 0,47 секунди середній час завантаження сторінки
• 0,05 секунди повільніше, ніж HTTP через HTTP / 1.1
• На 0,37 секунди повільніше, ніж HTTPS над HTTP / 2.0

HTTP через HTTP / 1.1

• 0,42 секунди середній час завантаження сторінки
• 0,05 секунди швидше, ніж HTTPS через HTTP / 1.1
• На 0,32 секунди повільніше, ніж HTTPS над HTTP / 2.0

HTTPS через HTTP / 2.0

• 0,10 секунди середній час завантаження
• 0,32 секунди швидше, ніж HTTP через HTTP / 1.1
• 0,37 секунди швидше, ніж HTTPS над HTTPS / 1.1