Производительность HTTP против HTTPS

Существуют ли какие-либо существенные различия в производительности между http и https? Кажется, я помню, что HTTPS может быть на пятом месте быстрее HTTP. Это действительно с веб-серверами/браузерами текущего поколения? Если да, есть ли какие-либо документы для его поддержки?

ОТВЕТЫ

Ответ 1

Вот очень простой ответ на этот вопрос: Профайл производительности вашего веб-сервера, чтобы узнать, какое ограничение производительности для вашей конкретной ситуации. Есть несколько инструментов для сравнения производительности HTTP vs HTTPS (JMeter и Visual Studio приходят на ум), и они довольно просты в использовании.

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

Как говорили другие, из-за шифрования будет некоторый уровень накладных расходов, но он сильно зависит от:

  • Оборудование
  • Серверное программное обеспечение
  • Соотношение динамического и статического содержимого
  • Расстояние клиента до сервера
  • Типичная продолжительность сеанса
  • Etc (мой личный фаворит)
  • Кэширование поведения клиентов

По моему опыту, серверы, которые тяжелы в динамическом контенте, как правило, меньше влияют на HTTPS, потому что время, затрачиваемое на шифрование (SSL-служебные данные), незначительно по сравнению с временем генерации контента.

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

Изменить: Один момент, который был поднят несколькими другими, заключается в том, что SSL-связь является основной ценой HTTPS. Это правильно, поэтому важны "типичная продолжительность сеанса" и "кэширование поведения клиентов".

Многие, очень короткие сеансы означают, что время установления связи будет подавлять любые другие факторы эффективности. Более длительные сеансы будут означать, что стоимость установления связи будет понесена в начале сеанса, но последующие запросы будут иметь относительно низкие накладные расходы.

Кэширование клиентов может выполняться с нескольких шагов, от широкомасштабного прокси-сервера до отдельного кеша браузера. Как правило, содержимое HTTPS не кэшируется в общем кеше (хотя для достижения этого несколько прокси-серверов могут использовать поведение типа "человек в середине" ). Многие браузеры кэшируют содержимое HTTPS для текущего сеанса и часто раз в сеансах. Влияние не кэширования или меньшее кэширование означает, что клиенты будут получать тот же контент чаще. Это приводит к большему количеству запросов и пропускной способности для обслуживания одинакового количества пользователей.

Ответ 2

HTTPS требует начального рукопожатия, которое может быть очень медленным. Фактический объем данных, передаваемых как часть рукопожатия, не является огромным (обычно не более 5 кБ), но для очень маленьких запросов это может быть довольно накладным. Однако, как только рукопожатие сделано, используется очень быстрая форма симметричного шифрования, поэтому накладные расходы минимальны. Итог: выполнение большого количества коротких запросов по HTTPS будет довольно медленным, чем HTTP, но если вы передадите большое количество данных в одном запросе, разница будет незначительной.

Однако keepalive - это поведение по умолчанию в HTTP/1.1, поэтому вы будете выполнять одно рукопожатие, а затем много запросов по одному и тому же соединению. Это делает существенную разницу для HTTPS. Вероятно, вы должны профилировать свой сайт (как предложили другие), но я подозреваю, что разница в производительности не будет заметной.

Ответ 3

Чтобы понять, как HTTPS увеличит вашу задержку, вы должны понять, как устанавливаются соединения HTTPS. Вот диаграмма nice. Ключ заключается в том, что вместо того, чтобы клиент получал данные после 2 "ножек" (в один раунд, вы отправляете запрос, сервер отправляет ответ), клиент не получит данные, по крайней мере, до 4 ножек (2 раунда), Итак, если для перехода между клиентом и сервером требуется 100 мс, ваш первый запрос HTTPS займет не менее 500 мс.

Конечно, это можно смягчить, повторно используя соединение HTTPS (какие браузеры должны делать), но он объясняет часть этого начального ларька при загрузке веб-сайта HTTPS.

Ответ 4

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

Накладные расходы связаны с SSL-рукопожатиями, которые являются длительными и значительно увеличивают количество раундов, необходимых для сеанса HTTPS по HTTP-протоколу.

Измерьте (используя такой инструмент, как Firebug) время загрузки страницы, пока сервер находится в конце симулированной ссылки с высокой задержкой. Существуют инструменты для имитации ссылки с высокой задержкой - для Linux существует "netem". Сравните HTTP с HTTPS на той же настройке.

Задержка может быть в некоторой степени смягчена:

  • Убедитесь, что ваш сервер использует HTTP keepalives - это позволяет клиенту повторно использовать сеансы SSL, что позволяет избежать необходимости в другом рукопожатии
  • Сокращение количества запросов на как можно меньше - путем объединения ресурсов там, где это возможно (например .js include files, CSS) и поощрения кэширования на стороне клиента.
  • Уменьшить количество загрузок страниц, например. загружая данные, не требуемые на страницу (возможно, в скрытом элементе HTML), а затем показывая ее с помощью client- script.

Ответ 5

Декабрь 2014 Обновление

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

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

Важно иметь последние знания о производительности HTTPS, поскольку Lets encrypt Центр сертификации начнет выпуск бесплатных, автоматизированных, и открывать SSL-сертификаты летом 2015 года, благодаря Mozilla, Akamai, Cisco, Electronic Frontier Foundation и IdenTrust.

Обновление 2015 года в 2015 году

Обновления в режиме шифрования - прибытие в сентябре 2015 года:

Дополнительная информация о Twitter: @letsencrypt

Для получения дополнительной информации о производительности HTTPS и SSL/TLS см.:

Подробнее о важности использования HTTPS см. ниже:

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

Благодаря Chris - автору теста HTTP vs HTTPS Test - за его комментарии ниже.

Ответ 6

Текущий топ-ответ не совсем правильный.

Как уже отмечали другие, https требует рукопожатия и, следовательно, делает больше обходов TCP/IP.

В среде WAN обычно задержка становится ограничивающим фактором, а не повышенным использованием ЦП на сервере.

Просто имейте в виду, что латентность от Европы до США может составлять около 200 мс (время прохождения через туннель).

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

Ответ 7

В дополнение ко всему, что упоминалось до сих пор, имейте в виду, что некоторые (все?) веб-браузеры не хранят кешированный контент, полученный по HTTPS на локальном жестком диске по соображениям безопасности. Это означает, что с точки зрения пользователя страницы с большим количеством статического контента будут загружаться медленнее после перезапуска браузера, и с точки зрения вашего сервера объем запросов на статический контент через HTTPS будет выше, чем если бы был HTTP.

Ответ 8

Для этого нет ни одного ответа.

Шифрование всегда будет потреблять больше CPU. Во многих случаях это может быть выгружено на выделенное оборудование, и стоимость будет зависеть от выбранного алгоритма. Например, 3дед более дорогой, чем AES. Некоторые алгоритмы для шифрования дороже, чем дешифратор. У некоторых есть противоположная стоимость.

Более дорогим, чем объемный криптограф, является стоимость рукопожатия. Новые подключения будут потреблять гораздо больше ЦП. Это может быть уменьшено за счет возобновления сеанса за счет сохранения старых секретов сеанса до истечения срока их действия. Это означает, что небольшие запросы от клиента, который не возвращается больше, являются самыми дорогими.

Для кросс-интернет-трафика вы можете не заметить эту стоимость в скорости передачи данных, поскольку доступная полоса пропускания слишком низкая. Но вы наверняка заметите это в использовании ЦП на занятом сервере.

Ответ 9

Я могу сказать вам (как пользователь dialup), что одна и та же страница через SSL в несколько раз медленнее, чем через обычный HTTP...

Ответ 10

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

Еще одно влияние на рассмотрение заключается в том, что статический контент, обслуживаемый через HTTPS, не будет кэшироваться прокси-серверами, и это может снизить производительность для нескольких пользователей, обращающихся к сайту по тому же самому прокси. Это можно смягчить из-за того, что статический контент будет кэшироваться и на настольных компьютерах, а в Internet Explorer версии 6 и 7 - кеш-кешируемое статическое содержимое HTTPS, если не указано иное (меню "Сервис" / "Свойства обозревателя" / "Дополнительно" / "Безопасность" / "Не сохранять зашифрованные страницы" на диск).

Ответ 11

Я провел небольшой эксперимент и получил 16% разницы во времени для того же изображения из flickr (233 КБ):

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

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

enter image description here

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

Ответ 12

Здесь отличная статья (немного старая, но все же замечательная) в латентности SSL-привязки. Помогло мне идентифицировать SSL как основную причину медленности для клиентов, которые использовали мое приложение через медленные интернет-соединения:

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

Ответ 15

Кажется, что здесь есть неприятный край: Ajax над перегруженным Wi-Fi.

Ajax обычно означает, что KeepAlive истекает через 20 секунд. Однако Wi-Fi означает, что (идеально быстрое) соединение ajax должно совершать многократные поездки. Хуже того, Wi-Fi часто теряет пакеты, и есть повторные передачи TCP. В этом случае HTTPS выполняет действительно очень плохо!

Ответ 16

HTTP VS HTTPS ПОРЯДОК ВЫПОЛНЕНИЯ

Я всегда связывал HTTPS с более медленным временем загрузки страницы по сравнению с обычным старым HTTP. Как веб-разработчик, производительность веб-страницы важна для меня, и все, что замедлит работу моих веб-страниц, - это не-нет.

Чтобы понять последствия для производительности, приведенная ниже диаграмма дает вам общее представление о том, что происходит под капотом, когда вы делаете запрос на ресурс с помощью HTTPS.

введите описание изображения здесь

Как видно из приведенной выше диаграммы, есть несколько дополнительных шагов, которые должны выполняться при использовании HTTPS по сравнению с использованием простого HTTP. Когда вы делаете запрос с использованием HTTPS, для подтверждения подлинности запроса необходимо выполнить рукопожатие. Это рукопожатие является дополнительным шагом по сравнению с HTTP-запросом и, к сожалению, несет некоторые накладные расходы.

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

Как вы можете видеть из Здесь тестовый видеоролик с использованием HTTPS повлиял на время загрузки страницы, однако разница незначительна и я заметил только разницу в 300 миллисекунд. Важно отметить, что эти времена зависят от многих факторов, таких как производительность компьютера, скорость соединения, загрузка сервера и расстояние от сервера.

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

МОЖЕТ ЛИ УЛУЧШИТЬ ПРОИЗВОДИТЕЛЬНОСТЬ? посетите здесь, чтобы получить подробную информацию

Ответ 17

Есть способ измерить это. Инструмент из apache, называемый jmeter, будет измерять пропускную способность. Если вы настроили большую выборку своей службы с помощью jmeter, в контролируемой среде с использованием SSL и без него, вы должны получить точное сравнение относительной стоимости. Меня бы интересовали ваши результаты.

Ответ 18

Это почти наверняка будет верно, если для SSL требуется дополнительный шаг шифрования, который просто не требуется для протокола non-SLL HTTP.

Ответ 19

HTTPS имеет накладные расходы на шифрование/дешифрование, поэтому он будет всегда немного медленнее. Терминал SSL очень интенсивен. Если у вас есть устройства для разгрузки SSL, разница в задержках может быть едва заметной в зависимости от нагрузки, на которую находятся ваши серверы.

Ответ 20

Более важная разница в производительности заключается в том, что сеанс HTTPS открыт ketp, пока пользователь подключен. HTTP-сеанс длится только для одного запроса элемента.

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

Ответ 21

Браузеры могут принимать протокол 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