Примерно, насколько сильно снизится производительность https по сравнению с http для той же страницы? Предположим, я могу обрабатывать 1000 запросов в секунду для abc.php, насколько это уменьшится при доступе через https? Я знаю, что это может зависеть от оборудования, конфигурации, ОС и т. Д., Но я просто ищу общее практическое правило / оценку.
Для быстрого и грязного теста (т.е. без какой-либо оптимизации!) Я включил простой веб-сайт Ubuntu apache2 по умолчанию (который просто говорит: «Он работает!») С http и https (самозаверяющий сертификат) на локальной виртуальной машине Ubuntu 9.04 и запустил apache ориентир "ab
"с 10 000 запросов (без параллелизма). Клиент и сервер находились на одной машине / виртуальной машине:
Результаты для http ("ab -n 10000 http://ubuntu904/index.html
")
Результаты для https ("ab -n 10000 https://ubuntu904/index.html
"):
Если вы внимательно посмотрите (например, с помощью tcpdump или wirehark) на связь tcp / ip единый запрос вы увидите, что для случая http между клиентом и сервером требуется 10 пакетов, тогда как для https требуется 16: задержка намного выше с https. (Подробнее о важности задержки Вот)
Добавление проверки активности (ab
вариант -k
) к тесту улучшает ситуацию, потому что теперь все запросы используют одно и то же соединение, то есть накладные расходы SSL ниже, но https по-прежнему измеряется медленнее:
Результаты для http с keep-alive ("ab -k -n 10000 http://ubuntu904/index.html
")
Результаты для https с сохранением активности ("ab -k -n 10000 https://ubuntu904/index.html
"):
Вывод:
Я бы сказал, что на современных серверах узким местом будут сеть и приложение, а не шифрование. TLS / SSL в apache будет написан на достаточно оптимизированном языке C, поэтому ваш PHP-код будет затмевать его, особенно если вы собираетесь делать такие вещи, как доступ к базе данных. Обслуживание статических файлов, вероятно, будет иметь большее влияние, поскольку шифрование станет большей частью всего процесса. Я не могу назвать конкретных цифр, но был бы удивлен, если бы они были больше 5%, а может быть, и около пары процентов.
Ничего не предполагайте, проверьте сами! Конечно, в ваших конкретных веб-приложениях.
Я обнаружил, что на современном оборудовании я, скорее всего, буду привязан к вводу-выводу для конкретной транзакции, чем к процессору (вычислениям). Это особенно верно, когда речь идет о сжатии и шифровании. 128-битное шифрование в наши дни является тривиальным делом - я обычно получаю гораздо больше усилий при создании и доставке исходящих страниц, чем при использовании SSL, и я не заметил значительной разницы в производительности между HTTP- и HTTPS-трафиком в течение нескольких лет.
Я поддерживаю рекомендацию для nginx. В моих собственных тестах он хорошо зарекомендовал себя в качестве специального загрузчика SSL.
Конечно, если обработка SSL действительно сильно ударит, вы всегда можете переместить ее за пределы сервера в специальный ящик. Есть хорошая запись об этом с nginx поверх Вот. Это то, что мы сделали на сильно загруженных серверах с балансировкой нагрузки уровня 7.
Я могу подтвердить, что дополнительная нагрузка на шифрование очень мала по сравнению с любыми другими включенными элементами (скрипты, сеть, ...)
По моему опыту, общее правило напрямую связано с размером вашего открытого ключа (например, 2048, 4096 или 8192). Все это занимает значительно больше времени. Однако я почти не могу заметить разницу в среде настольных компьютеров, но на мобильных устройствах вы заметите разницу, поскольку они требуют вычислительной мощности.
В общем, это прискорбно, но SSL всегда и, вероятно, всегда будет иметь огромное снижение производительности.