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

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

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

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

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

Обновление Июня 2015

обновления на Давайте шифровать-прибытие сентябрь 2015:

• давайте зашифруем расписание запуска (16 июня , 2015)
• давайте зашифруем корневые и промежуточные сертификаты (4 июня 2015)
• проект Давайте зашифруем Соглашение подписчика (21 мая 2015)

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

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

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

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

• почему HTTPS для всего? (стандарт только HTTPS)
• давайте шифровать (Internet Security Research Group)
• HTTPS везде (Электронных Границ Foundation)

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

спасибо Крис - автор HTTP vs HTTPS Test benchmark-для его комментариев ниже.

текущий верхний ответ не совсем корректна.

как указывали здесь другие, https требует рукопожатия и, следовательно, делает больше TCP/IP roundtrips.

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

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

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

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

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

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

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

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

Я могу сказать вам (как пользователь удаленного доступа), что одна и та же страница через 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 kb):

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

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

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

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

СРАВНЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ HTTP И HTTPS

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

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

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

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

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

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

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

здесь, похоже, есть неприятный крайний случай: Ajax над перегруженным wifi.

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

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

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

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

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

Это почти наверняка будет верно, учитывая, что SSL требует дополнительного шага шифрования, который просто не требуется не SLL 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 (Ver. 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