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

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

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

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

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

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

Обновление за декабрь 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 года:

• Расписание запуска Let's Encrypt (16 июня 2015 г.)
• Давайте зашифруем корневые и промежуточные сертификаты (4 июня 2015 г.)
• Проект абонентского соглашения Let's Encrypt (21 мая 2015 г.)

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

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

• TLS быстро еще?
• Высокопроизводительная сеть браузера, Глава 4: Безопасность транспортного уровня
• Разгон SSL
• Анатомия и производительность обработки SSL

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

• Почему HTTPS для всего? (Стандарт только для HTTPS)
• Let's Encrypt (Исследовательская группа по интернет-безопасности)
• HTTPS Везде (Фонд Электронной Границы)

Подводя итог, позвольте мне процитировать Илью Григорика : «У 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 КБ):

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/comparison/comparison_slides/sld001.htm

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

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

TLS еще быстр? Да.

• Смотреть: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Читайте: https://istlsfastyet.com/

Есть много проектов, которые стремятся размыть линии и сделать HTTPS столь же быстрым. Как SPDY и мод-спди .

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

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

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

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

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

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

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

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

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

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

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

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

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