Сравнение скорости HTTPS и HTTP

Обновление 2013-04-25:

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

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

Пожалуйста, прочитайте SSL не о шифровании Troy Hunt по причинам почему.

Я считаю, что я запускаю весь сайт электронной коммерции под https. Я решил запустить сырой тест, чтобы измерить время загрузки изображения в 156 КБ через https vs http, потому что я прочитал, что https обременен дополнительными служебными данными из процесса шифрования.

Бенчмарк был выполнен с использованием Firefox Firebug, просто переписав время ожидания "Ожидание" и "Прием" (все остальные 0) в Excel с панели "Сеть" при загрузке изображения из пустого кеша.

Мои результаты были неожиданными:

http: 11.233 seconds
Waiting     Receiving   Total 
1.56        0.88        2.44 
1.55        0.101       1.651 
1.53        0.9         2.43 
1.71        0.172       1.882 
1.9         0.93        2.83 

https: 9.936 seconds
Waiting     Receiving  Total
0.867       1.59       2.457
0.4         1.67       2.07
0.277       1.5        1.777
0.536       1.29       1.826
0.256       1.55       1.806

[Очевидное] Наблюдения из эталона:

Ответ сервера выполняется быстрее, но время загрузки медленнее для https, чем http.
https быстрее в целом на значительное количество (~ 10%).

Может ли кто-нибудь объяснить, почему это произойдет?
Считаете ли вы, что документ (html, css, javascript) даст разные результаты?
У кого-нибудь есть лучший метод загрузки бенчмаркинга?

Вот тестовое изображение:

[тестовое изображение удалено]

Дополнительная информация:

Веб-сайт находится на общей учетной записи хостинга через Godaddy.com.
Если вы так добры, чтобы запустить свой собственный тест, не добавляйте субдомен "www"... Я все равно использую root для статического контента.
Использует IIS7 в интегрированном режиме трубопровода.

Изменить: эталон для 1px GIF (35 байт) ниже:

http: 2.666 seconds
Waiting     Receiving  Total
0.122       0.31       0.432
0.184       0.34       0.524
0.122       0.36       0.482
0.122       0.34       0.462
0.126       0.64       0.766


https: 2.604 seconds
Waiting     Receiving  Total
0.25        0.34       0.59
0.118       0.34       0.458
0.12        0.34       0.46
0.182       0.31       0.492
0.134       0.47       0.604

Результаты: https все еще быстрее; хотя тривиально в этом случае.

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

Итак, на Godaddy, размещенном на хостинге около 6:00 вечера, на моем конкретном сервере содержимое, переданное через https, происходит быстрее, чем через http.

Ответ 1

Если вы посмотрите на свое время, у http больше времени ожидания и меньше времени приема. С другой стороны, https имеет меньшее время ожидания и большее время приема. Я бы это интерпретировал, поскольку порт http на сервере хостинга более занят, поэтому запрос остается дольше в очереди до тех пор, пока сервер не будет принят. После принятия запросы передаются быстрее https. На порту https на сервере меньше трафика, поэтому запрос обслуживается быстрее, но занимает больше времени.

Для любого сравнения https и http вам нужно будет принять во внимание большее время для рукопожатия каждого запроса для https по сравнению с http. Вы должны видеть ухудшение при выполнении множества небольших запросов.

Ответ 2

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

Если это то, что вы не возражаете против совместного использования пользователями.

Ответ 3

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

Обратите внимание на две вещи о ваших результатах:

HTTP всегда быстрее при первом "итоговом" результате, но медленнее в последующих итогах.
Результаты HTTPS более согласованы.

Современные балансировки нагрузки обычно включают сжатие, в то время как SSL используется для повышения производительности. Хотя верно, что первоначальное рукопожатие SSL связано с существенной задержкой, механизмы, используемые для поддержания сеанса ( "возобновленное рукопожатие" и симметричное шифрование вместо асимметричного шифрования) добавляют лишь незначительную задержку. В результате, если ваши сеансы не являются короткими, вы получаете больше преимуществ от сжатия, чем потеряете из обслуживания сеанса.

Традиционная мудрость, что SSL несет существенную задержку, устарела (если только ваши сеансы не очень короткие). Некоторые инженеры Google написал статью, объясняющую, как некоторые предыдущие предположения о SSL больше не верны.

Ответ 4

https работает следующим образом: Сначала выполняется 4-стороннее рукопожатие (по крайней мере, если я правильно помню это было 4way), здесь клиент и сервер соглашаются о симметричном алгоритме шифрования, который используется позже и обмениваются сертификатами (содержащими открытые ключи).

Они обмениваются сеансом (ключ для симметричного enc позже) с использованием publickey crypto.

Теперь они отправляют сообщения, зашифрованные ключом сеанса и некоторым алгоритмом шифрования (3des, aes, rc4, rc5 и т.д.). Поскольку симметричные шифрования не являются такими дорогостоящими операциями, различия во времени загрузки не так велики.

Тот факт, что у вас меньше времени ожидания, заключается в том, что у вас, вероятно, меньше трафика на порт http или меньше трафика в то время, когда вы делали запрос https по сравнению с http-запросами.

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

Ответ 5

Вы получаете доступ к своему сайту через прокси? Если это так, вы можете видеть более высокую производительность, поскольку прокси-сервер обходит или сводится только к обработке начальных запросов CONNECT.

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

Ответ 6

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