HTTP против HTTPS производительности
Существуют ли существенные различия в производительности между http и https? Кажется, я вспомнил, что читал, что HTTPS может быть в пять раз быстрее HTTP. Действительно ли это с веб-серверами / браузерами текущего поколения? Если так, есть ли какие-либо технические документы, чтобы поддержать это?
21 ответ
Ответ на этот вопрос очень прост: профилируйте производительность вашего веб-сервера, чтобы увидеть, как снижается производительность вашей конкретной ситуации. Существует несколько инструментов для сравнения производительности сервера 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 vs 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 есть только одна проблема с производительностью: она используется недостаточно широко. Все остальное можно оптимизировать".
Спасибо AnthumChris - автору теста HTTP vs HTTPS Test - за его комментарии ниже.
Текущий топ-ответ не совсем правильный.
Как уже отмечали другие, https требует рукопожатия и, следовательно, делает больше обходов TCP/IP.
В среде WAN обычно задержка становится ограничивающим фактором, а не повышенным использованием ЦП на сервере.
Просто имейте в виду, что задержка из Европы в США может составлять около 200 мс (время в пути).
Вы можете легко измерить это (для случая одного пользователя) с HTTPWatch.
В дополнение ко всему, что упомянуто до сих пор, имейте в виду, что некоторые (все?) Веб-браузеры не сохраняют кэшированный контент, полученный через HTTPS, на локальном жестком диске по соображениям безопасности. Это означает, что с точки зрения пользователя страницы с большим количеством статического контента будут загружаться медленнее после перезапуска браузера, а с точки зрения вашего сервера объем запросов на статический контент по HTTPS будет выше, чем по HTTP.
В ряде случаев влияние SSL-квитирования на производительность будет уменьшено за счет того, что сеанс SSL может кэшироваться на обоих концах (на рабочем столе и на сервере). Например, на компьютерах с Windows сеанс SSL может кэшироваться до 10 часов. См. http://support.microsoft.com/kb/247658/EN-US. Некоторые ускорители SSL также имеют параметры, позволяющие настраивать время кэширования сеанса.
Другое влияние, которое следует учитывать, заключается в том, что статический контент, обслуживаемый по HTTPS, не будет кэшироваться прокси-серверами, что может снизить производительность для нескольких пользователей, обращающихся к сайту через один и тот же прокси-сервер. Это может быть смягчено тем фактом, что статический контент будет также кэшироваться на настольных компьютерах, Internet Explorer версий 6 и 7 кэширует статический контент HTTPS, который кэшируется, если не указано иное (меню "Сервис" / "Свойства обозревателя" / "Дополнительно" / "Безопасность" / "Не сохранять зашифрованные страницы"). на диск).
На это нет однозначного ответа.
Шифрование всегда будет потреблять больше ресурсов процессора. Во многих случаях это может быть выгружено на выделенное оборудование, и стоимость будет зависеть от выбранного алгоритма. Например, 3des дороже, чем AES. Некоторые алгоритмы являются более дорогостоящими для шифратора, чем для расшифровщика. Некоторые имеют противоположную стоимость.
Рукопожатие обходится дороже, чем массовая криптография. Новые соединения будут потреблять гораздо больше ресурсов процессора. Это может быть уменьшено при возобновлении сеанса за счет хранения старых секретов сеанса до истечения срока их действия. Это означает, что небольшие запросы от клиента, которые не возвращаются больше, являются самыми дорогими.
Для перекрестного интернет-трафика вы можете не заметить эту стоимость в скорости передачи данных, поскольку доступная пропускная способность слишком низкая. Но вы наверняка заметите это при использовании процессора на загруженном сервере.
Я могу сказать вам (как коммутируемому пользователю), что одна и та же страница по SSL работает в несколько раз медленнее, чем по обычному HTTP...
Я провел небольшой эксперимент и получил 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.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm
TLS еще быстр? Да.
- Смотреть: https://www.youtube.com/watch?v=0EB7zh_7UE4
- Читайте: https://istlsfastyet.com/
Есть много проектов, которые стремятся размыть линии и сделать HTTPS такими же быстрыми. Как SPDY и мод-спди.
Здесь, кажется, есть неприятный крайний случай: Ajax по перегруженному Wi-Fi.
Ajax обычно означает, что время ожидания KeepAlive истекло, скажем, через 20 секунд. Тем не менее, Wi-Fi означает, что (в идеале быстрое) AJAX-соединение должно совершать несколько циклов. Хуже того, Wi-Fi часто теряет пакеты, и есть повторные передачи TCP. В этом случае HTTPS действительно очень плохо работает!
Сравнение производительности HTTP и HTTPS
Я всегда связывал HTTPS с более медленным временем загрузки страницы по сравнению с простым старым HTTP. Как веб-разработчик, для меня важна производительность веб-страниц, и все, что может снизить производительность моих веб-страниц, - нет-нет.
Чтобы понять связанные с производительностью последствия, приведенная ниже диаграмма дает вам базовое представление о том, что происходит под капотом, когда вы делаете запрос на ресурс с использованием HTTPS.
Как видно из приведенной выше диаграммы, при использовании HTTPS необходимо выполнить несколько дополнительных шагов по сравнению с обычным HTTP. Когда вы делаете запрос с использованием HTTPS, необходимо выполнить квитирование, чтобы проверить подлинность запроса. Это рукопожатие является дополнительным шагом по сравнению с HTTP-запросом и, к сожалению, требует дополнительных затрат.
Чтобы понять последствия для производительности и убедиться, будет ли влияние на производительность значительным, я использовал этот сайт в качестве платформы для тестирования. Я отправился на webpagetest.org и использовал инструмент визуального сравнения, чтобы сравнить загрузку этого сайта с использованием HTTPS и HTTP.
Как вы можете видеть из " Вот тестовое видео", результат с использованием HTTPS оказал влияние на время загрузки моей страницы, однако разница незначительна, и я заметил только разницу в 300 миллисекунд. Важно отметить, что это время зависит от многих факторов, таких как производительность компьютера, скорость соединения, нагрузка на сервер и расстояние от сервера.
Ваш сайт может отличаться, и важно тщательно протестировать его и проверить влияние на производительность, связанную с переходом на HTTPS.
Можем ли мы улучшить производительность? посетите здесь, чтобы получить подробную информацию
HTTPS действительно влияет на скорость страницы...
Приведенные выше цитаты показывают глупость многих людей в отношении безопасности и скорости сайта. Подтверждение связи с сервером HTTPS / SSL создает начальную задержку в установлении Интернет-соединений. Есть медленная задержка, прежде чем что-либо начнет отображаться на экране браузера вашего посетителя. Эта задержка измеряется в информации о времени до первого байта.
Издержки установления связи HTTPS отображаются в информации о времени до первого байта (TTFB). Обычный TTFB колеблется от менее 100 миллисекунд (в лучшем случае) до более 1,5 секунд (в худшем случае). Но, конечно, с HTTPS на 500 миллисекунд хуже.
Беспроводное соединение 3G в обе стороны может длиться 500 миллисекунд и более. Дополнительные отключения удваивают задержку до 1 секунды или более. Это большое негативное влияние на производительность мобильных устройств. Очень плохие новости.
Мой совет: если вы не обмениваетесь конфиденциальными данными, тогда вам вообще не нужен SSL, но если вам нравится веб-сайт электронной коммерции, вы можете просто включить HTTPS на определенных страницах, где происходит обмен конфиденциальными данными, такими как вход в систему и оформление заказа.
Источник: Pagepipe
Есть способ измерить это. Инструмент из Apache под названием jmeter будет измерять пропускную способность. Если вы настроили большую выборку вашего сервиса с помощью jmeter, в контролируемой среде, с использованием SSL и без него, вы должны получить точное сравнение относительной стоимости. Я был бы заинтересован в ваших результатах.
Более важное различие в производительности заключается в том, что сеанс HTTPS остается открытым, пока пользователь подключен. HTTP-сессия длится только для одного запроса элемента.
Если вы работаете с сайтом с большим количеством одновременно работающих пользователей, ожидайте покупки большого количества памяти.
Браузеры могут принимать протокол 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
Это почти наверняка будет правдой, учитывая, что SSL требует дополнительного шага шифрования, который просто не требуется для не-SLL HTTP.
HTTPS имеет издержки шифрования / дешифрования, поэтому он всегда будет немного медленнее. Завершение SSL очень загружает процессор. Если у вас есть устройства для разгрузки SSL, разница в задержках может быть едва заметна в зависимости от нагрузки на ваши серверы.