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

Question

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

Answer 5

Декабрь 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 Everywhere (Фонд электронной границы)

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

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

Answer 6

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

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

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

Answer 10

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

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

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

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