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


363

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


1
Вы также должны проверить HTTP2, который браузеры в настоящее время поддерживают только при использовании с HTTPS. en.wikipedia.org/wiki/HTTP/2
Лука Стиб

1
httpsвсегда медленнее, чем http(или намного медленнее).
i486

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

Ответы:


231

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

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

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

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

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

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

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

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

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


Джеймс, надеялся, что вы сможете кратко прокомментировать сравнительную скорость этого решения aSSL : assl.sullof.com/assl Вне всякого сомнения , что-нибудь получилось с точки зрения производительности? Спасибо!
Мэтт Гарднер

PS: Насколько я понимаю, для этого решения требуется ключ на стороне клиента (который может быть реализован в случае приложения webkit / titanium), цель состоит в том, чтобы просто максимизировать этот компонент уравнения скорости вместе с другими, упомянутыми вами.
Мэтт Гарднер

7
Этот пост не совсем отвечает на вопрос. Похоже, что Джим Гертс спрашивает о природе производительности самих HTTP и HTTPS, а не о конкретной реализации. HTTPS, несомненно, медленнее, потому что он делает больше работы. Вопрос в том, насколько медленнее? Все знают, что если вы добавите больше переменных, вы получите разные результаты.
Эллиот Кэмерон

74
Этот ответ упоминает много несоответствующих (другими словами, неправильных) вещей в начале . Он берет 5 абзацев, чтобы получить правильный ответ, который является рукопожатием .
Бобобобо

2
Контент, обслуживаемый по HTTPS, не будет кэшироваться прокси . Все современные браузеры кэшируют HTTPS-контент по умолчанию, если явно не сказано, как объяснил Джефф Этвуд
Jarek Przygódzki

222

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

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


19
Оказывается, что стоимость квитирования будет оплачиваться как минимум в 4-10 раз за сеанс, поскольку большинство браузеров используют несколько подключений к одному серверу. В зависимости от того, как долго будет работать https-keep-alive для браузера, он может возникать повторно во время сеанса.
Джеймс Шек

6
Что касается функции поддержки активности HTTP, мы столкнулись со сценарием, когда соединения не остаются постоянными. Для каждого запроса создается соединение запроса и передается рукопожатие MA-SSL. Существуют возможности, в которых клиент или сервер могут быть настроены на закрытие соединений. Обычно происходит в средах Tomcat / Websphere.
zkarthik

8
@JamesSchek Несколько соединений должны использовать один и тот же сеанс SSL , что немного меняет картину. То же самое относится, даже если HTTP keep-alive не работает.
маркиз Лорн

14
@EJP Это правда. А в 2013 году большинство браузеров / серверов и реализации SSL / TLS используют повторное использование сеансов. В 2008 году это не всегда было безопасным предположением.
Джеймс Шек

3
Этот вопрос часто встречается в Google как «производительность http против https». Хотя приведенный выше ответ был верным в 2008 году, он больше не верен в 2015 году и не должен использоваться в качестве основы для решений, позволяющих избежать использования https.
Пол Шрайбер

101

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

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


1
С точки зрения клиента Java, как можно сделать подключение HTTPS повторно используемым? Я имею в виду, могу ли я сделать статический объект HttpsConnection и использовать его повторно? (в контексте веб-приложения)
Никс

1
Спустя 5 лет ссылка на симпатичную диаграмму +1 не работает, кто-нибудь может найти ее и вставить в ответ вместо ссылки?
Джим Вольф

2
@FRoZen нашел альтернативную ссылку
Stefan L

Также я думаю, что эта страница является очень хорошей диаграммой http, чтобы лучше понять всю картину: blog.catchpoint.com/2010/09/17/anatomyhttp
эллиптический вид

1
@Nikhil Java автоматически повторно использует базовое соединение и распределяет его между запросами, если только пользователь не форсирует его disconnect. Проверьте документы .
Могниш

76

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

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

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

Задержка может быть уменьшена до некоторой степени:

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

8
Я полностью согласен с @MarkR. Мой недавний профиль моей домашней страницы, HTTP против HTTPS, среднее время загрузки было 1,5 с и 4,5 с, соответственно. При взгляде на детали соединения, большим фактором замедления были дополнительные обходы из-за рукопожатия SSL. Мобильные браузеры через 3G были еще хуже. Числа были 5 и 9 соответственно.
Клинт Пахл

26

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

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

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

Важно иметь актуальную информацию о производительности HTTPS, поскольку центр сертификации Let's Encrypt начнет выпускать бесплатные, автоматизированные и открытые сертификаты SSL летом 2015 года благодаря Mozilla, Akamai, Cisco, Electronic Frontier Foundation и IdenTrust.

Обновление за июнь 2015 года

Обновления Let's Encrypt - прибытие в сентябре 2015 года:

Больше информации в Твиттере: @letsencrypt

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

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

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

Спасибо Крису - автору теста HTTP vs HTTPS Test - за его комментарии ниже.


6
Этот «HTTP vs HTTPS Test» намеренно вводит в заблуждение, пожалуйста, не связывайтесь с ним. На самом деле эта страница сравнивает HTTP с SPDY . Это правда, если вы мне не верите, попробуйте в IE и посмотрите, что там написано. Не бывает ситуации, когда HTTP-запрос выполняется быстрее, чем эквивалентный HTTPS-запрос.
orrd

3
Google заставил SPDY использовать защищенные соединения только по политическим, а не техническим причинам. HTTP / 2 (который использует те же методы повышения скорости SPDY) может использовать незащищенное соединение, и это немного быстрее, когда это происходит. Незащищенное соединение всегда по крайней мере немного быстрее защищенного соединения, использующего тот же протокол. «Тест HTTP против HTTPS» намеренно вводит в заблуждение и вводит в заблуждение.
Орд

3
Веб-сайт обеспечивает количественное сравнение с реальными числами, и это попытка побудить большее количество людей защитить своих пользователей с помощью HTTPS. Мнения только у нас далеко, и у нас всегда есть свобода создавать медленные, небезопасные приложения для IE по HTTP. Я всегда буду голосовать за создание быстрых, передовых и безопасных веб-приложений для Chrome / Firefox поверх HTTPS.
AnthumChris

2
Арифметика на httpvshttps.com выглядит неправильно: 1,7 секунды по сравнению с 34 секундами - это не «95% быстрее». Это в 20 раз быстрее или на 1900% быстрее. Следует сравнивать скорости, а не продолжительность.
Полковник Паник

2
Тест вводит в заблуждение и обманывает. В соответствии с tools.ietf.org/html/rfc7540#section-3.2 нет причин, по которым HTTP / 2 нельзя использовать в незащищенном соединении. Крупные компании стремятся к универсальному использованию HTTPS. Причины разные. Но факт остается фактом. Если на странице нет личных данных, нет смысла использовать SSL. И хотя да с сегодняшними компьютерами, рукопожатие SSL тривиально. Если мы начнем говорить это, и это тривиальные вещи, то просто увязнут. Создайте 1: 1 тест HTTP / 1.1 против HTTP / 1.1 SSL и HTTP / 2 против HTTP / 2 SSL. Тогда обсудите.
Shinrai

23

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

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

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

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

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


12

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


6
Отправка заголовка «Cach-Control: max-age = X, public» приведет к тому, что современные браузеры (только что протестированные FF4, Chrome12, IE8, IE9) будут кэшировать контент. Однако я заметил, что эти браузеры отправляют условный запрос GET, который может привести к дополнительной задержке для дополнительных циклов, особенно если соединение SSL не кэшируется (Keep Alive).
Клинт Пахл

6

На это нет единого ответа.

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

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

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


6

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


6
Хорошая точка зрения. Я также обнаружил, что время загрузки через сеть мобильной связи (3G) также в 2–3 раза меньше.
Клинт Пахл

Ага! Спустя всего полтора года после этого ответа я переехала в новый дом и, наконец, смогла перейти на DSL за меньшие деньги, чем линия POTS!
Брайан Кноблаух

6

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

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


4

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

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

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

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

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


4
невозможно создать метрику статистического анализа на основе 2 запросов, по одному на каждый.
Том

3

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

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


2

Поскольку я исследую ту же проблему для своего проекта, я нашел эти слайды. Старше, но интересно:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm


Я нашел упрощенные диаграммы полезными, но также немного отсутствующими. Я думаю, чтобы лучше понять количество поездок туда и обратно, эта страница для http полезна: blog.catchpoint.com/2010/09/17/anatomyhttp Тогда, насколько я могу судить по https: мы добавляем одну поездку туда и обратно.
эллиптический вид

2

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

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



2

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

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

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

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

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

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

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

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


1
В целом, пример хороший, но он более сложный, чем изображенный, особенно с Perfect Forward Secrecy. Также на самом деле используются четыре симметричных ключа.
Zaph

0

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


-1

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


-1

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

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


2
Не в HTTP 1.1. Соединения остаются открытыми в течение длительного времени.
Sklivvz

-1

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


2
Что есть разница в производительности между этими двумя случаями.
Дэвид Человек

2
Но вопрос такой: «Существуют ли какие-либо существенные различия в производительности между http и https?»
Sklivvz

-1

HTTPS действительно влияет на скорость страницы ...

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

Издержки рукопожатия HTTPS отображаются в информации о времени до первого байта (TTFB). Обычный TTFB колеблется от менее 100 миллисекунд (в лучшем случае) до более 1,5 секунд (в худшем случае). Но, конечно, с HTTPS это на 500 миллисекунд хуже.

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

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

Источник: Pagepipe


-2

Браузеры могут принимать протокол 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
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.