Сравнение скорости HTTPS и HTTP
2013-04-25 обновления:
Это популярный вопрос, который получает больше внимания, чем должно. Для того чтобы остановить распространение дезинформации, пожалуйста, сначала прочитайте следующие абзацы и сопроводительную статью:
скорость не должна быть фактором при принятии решения об использовании HTTPS или HTTP. Если ты ... --5-->нужно HTTPS для любой часть вашего сайта (вход, регистрация, кредитные карты и т. д.), вы абсолютно нужен HTTPS для всего этого, все время.
читайте SSL не о шифровании by Трой Хант причины.
Я рассматриваю запуск всего моего веб-сайта электронной коммерции под https. Я решил запустить грубый тест для измерения времени загрузки изображения 156KB через https vs http, потому что я прочитал, что https обременен дополнительными накладными расходами от процесса шифрования.
ориентир был выполняется с помощью Firebug Firefox просто путем транскрибирования" ожидания "и" получения " раз (все остальные разы равны 0), чтобы преуспеть из панели Net при загрузке изображения из пустого кэша.
мои результаты оказались неожиданными:
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
[очевидные] наблюдения из benchmark:
- ответ сервера быстрее, но время загрузки медленнее для https, чем http.
- https быстрее в целом на значительную сумму (~10%).
Кто-нибудь может объяснить, почему это произошло?
Как вы думаете, документ (html, css, javascript) даст разные результаты?
У кого-нибудь есть лучший метод бенчмаркинга загрузок?
Вот тестовый образ:
[тест изображение удалено]
Дополнительная Информация:
- веб-сайт находится на общей учетной записи хостинга через Godaddy.com.
- если вы будете так добры, чтобы запустить свой собственный бенчмарк, не добавляйте поддомен "www"...Я все равно использую root для статического контента.
- использует IIS7 в интегрированном режиме трубопровода.
Edit: бенчмарк для 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.
6 ответов
Если вы посмотрите на свое время, http имеет большее время ожидания и меньшее время приема. https, с другой стороны, имеет меньшее время ожидания и большее время приема. Я бы интерпретировал это как http-порт на общем хост-сервере более занят, поэтому запрос остается дольше в очереди, пока не будет принят сервером. После принятия запросы передаются быстрее, чем https. На https-порту на сервере меньше трафика, поэтому запрос обслуживается быстрее, но занимает больше времени передача.
для любого сравнения https и http вам придется учитывать большее время для рукопожатия каждого запроса https по сравнению с http. Вы должны видеть ухудшение при выполнении многих небольших запросов.
вы также можете принять во внимание, что документы HTTPS будут почти никогда не кэшироваться нигде, кроме браузера пользователей, так что вы можете найти, что хотя для отдельного пользователя разница небольшая, HTTP-документ может быть значительно быстрее для большого количества людей, разделяющих кэш. (Это все еще довольно распространено в некоторых местах для интернет-провайдеров, чтобы поместить своих клиентов через общий прокси-кэш)
Если это то, что вы не против обмена пользователями, конечно.
Я думаю, что быстрее вы видите через HTTPS не случайность.
обратите внимание на две вещи о ваших результатах:
- HTTP всегда быстрее на первом" общем " результате, но медленнее в последующих итогах.
- результаты HTTPS более последовательны.
современные балансировщики нагрузки обычно включают сжатие, когда SSL используется для повышения производительности. Хотя это правда, что начальное SSL-рукопожатие вызывает существенную задержку, механизмы, используемые для поддержания сеанса ("возобновленное рукопожатие" и симметричное шифрование вместо асимметричного шифрования), добавляют только незначительную задержку. В результате, если ваши сеансы не короткие, Вы получаете больше преимуществ производительности от сжатия, чем теряете от обслуживания сеанса.
общепринятое мнение, что SSL вызывает существенную задержку, устарело (если ваши сеансы не являются довольно короткими). Некоторые инженеры Google написал статью объясняя как некоторые предыдущие предположения о SSL больше не верны.
https работает следующим образом: Сначала выполняется 4-стороннее рукопожатие (по крайней мере, если я правильно помню, это было 4way), здесь клиент и сервер согласуют используемый позже алгоритм симметричного шифрования и сертификаты exchange (содержащие открытые ключи).
они обмениваются сеансом (ключ для симметричного enc позже), используя криптографию publickey.
теперь они отправляют сообщения, зашифрованные с помощью ключа сеанса и некоторого алгоритма шифрования (3des, aes, rc4, rc5 и т. д.). Поскольку симметричный шифрование не так дорого операции различия во времени загрузки не так велики.
тот факт, что у вас есть меньше время ожидания связано с тем, что у вас, вероятно, меньше трафика на http-порту или меньше трафика в то время, когда вы сделали запрос https по сравнению с http-запросами.
поэтому для оптимизации производительности вы должны использовать как можно меньше https-соединений, поскольку рукопожатие является относительно дорогой процедурой.
вы получаете доступ к своему сайту через прокси-сервер? Если это так, вы можете увидеть лучшую производительность, потому что прокси-сервер обходится или сводится к обработке начальных запросов на подключение.
прокси-сервер может проверять и кэшировать содержимое при использовании HTTP, что приводит к снижению производительности.
вся разница в скорости, скорее всего, из-за GoDaddy принудительного сжатия HTTP на своих серверах в попытке сохранить пропускную способность, но это то, что не всегда происходит с подключением стиля HTTPS, поскольку он более новый и лучше оптимизирован для запуска.