Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Системное администрирование и сети

HTTPS в 50 раз медленнее, чем HTTP.

На чтение 12 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Запрос Curl с рабочего компьютера
  3. Запрос Curl с сервера linode (по ssh)
  4. Диагностика
  5. Решение
  6. Дифференциальные диагнозы
  7. Ответ или решение
  8. Возможные причины медленной работы HTTPS
  9. Рекомендации по улучшению производительности HTTPS
  10. Заключение

Вопрос или проблема

У меня есть веб-сайт, который использует https для передачи файла javascript клиенту. Веб-сайт – getsimpleapps.com.

Оказывается, этот файл загружается в 52 раза медленнее по сравнению с http (20.08 с – 29.08 с) по сравнению с http (380 мс).

Домашняя страница сайта имеет такую же медлительность, как и файл javascript.

Я недавно переключился с dreamhost на linode и работал над настройкой SSL на новом сервере, пока это не сработало. Я не делал никаких сумасшедших настроек.

Linode работает на Ubuntu 12.04, а сайт основан на стеке (LAMP).

Мой вопрос к сообществу stack overflow: Как мне исправить SSL и HTTPS на моем сервере? Я знаю, что stack overflow заполнен вопросами о медлительности HTTPS, но не даются реальные решения. Урок по ubuntu или руководство по настройке было бы идеальным.

файл: /etc/apache2/sites-enabled/getsimpleapps.com

<VirtualHost *:80>
     ServerAdmin [email protected]
     ServerName getsimpleapps.com
     ServerAlias www.getsimpleapps.com
     DocumentRoot /srv/sites/getsimpleapps.com/public/
     ErrorLog /srv/sites/getsimpleapps.com/logs/error.log
     CustomLog /srv/sites/getsimpleapps.com/logs/access.log combined
</VirtualHost>

<VirtualHost 50.116.58.18:443>
     SSLEngine On
     #SSLCertificateFile /etc/apache2/ssl/www.getsimpleapps.com.crt
     #SSLCertificateKeyFile /etc/apache2/ssl/www.getsimpleapps.com.key
     #SSLCACertificateFile /etc/apache2/ssl/comodo.crt
     SSLCertificateFile /etc/apache2/ssl/dreamhost/dh.crt
     SSLCertificateKeyFile /etc/apache2/ssl/dreamhost/dh.key
     SSLCACertificateFile /etc/apache2/ssl/dreamhost/dh.cer

     ServerAdmin [email protected]
     ServerName getsimpleapps.com
     ServerAlias www.getsimpleapps.com
     DocumentRoot /srv/sites/getsimpleapps.com/public/
     ErrorLog /srv/sites/getsimpleapps.com/logs/error.log
     CustomLog /srv/sites/getsimpleapps.com/logs/access.log combined
</VirtualHost>

Запрос Curl с рабочего компьютера

thomas@workstation:~$ time curl -Iv https://getsimpleapps.com/
* About to connect() to getsimpleapps.com port 443 (#0)
*   Trying 50.116.58.18... connected
* Connected to getsimpleapps.com (50.116.58.18) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: OU=Domain Control Validated; OU=Provided by New Dream Network, LLC; OU=DreamHost Basic SSL; CN=getsimpleapps.com
*    start date: 2012-02-23 00:00:00 GMT
*    expire date: 2013-02-22 23:59:59 GMT
*    subjectAltName: getsimpleapps.com matched
*    issuer: C=GB; ST=Greater Manchester; L=Salford; O=Comodo CA Limited; CN=PositiveSSL CA
*    SSL certificate verify ok.
> HEAD / HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: getsimpleapps.com
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Thu, 02 Aug 2012 20:31:39 GMT
Date: Thu, 02 Aug 2012 20:31:39 GMT
< Server: Apache/2.2.22 (Ubuntu)
Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.3.10-1ubuntu3.2
X-Powered-By: PHP/5.3.10-1ubuntu3.2
< Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2298c7e45da25e4aaf80f7a1e36ed4a006%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A13%3A%2250.75.209.154%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A81%3A%22curl%2F7.21.4+%28universal-apple-darwin11.0%29+libcurl%2F7.21.4+OpenSSL%2F0.9.8r+zlib%2F1.2.5%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343939499%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7D80bf8ae5040fc47780ccd59f1fb8b267; expires=Thu, 02-Aug-2012 22:31:39 GMT; path=/
Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2298c7e45da25e4aaf80f7a1e36ed4a006%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A13%3A%2250.75.209.154%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A81%3A%22curl%2F7.21.4+%28universal-apple-darwin11.0%29+libcurl%2F7.21.4+OpenSSL%2F0.9.8r+zlib%2F1.2.5%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343939499%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7D80bf8ae5040fc47780ccd59f1fb8b267; expires=Thu, 02-Aug-2012 22:31:39 GMT; path=/
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Content-Type: text/html
Content-Type: text/html

< 
* Connection #0 to host getsimpleapps.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

real    0m29.078s
user    0m0.018s
sys 0m0.005s

Запрос Curl с сервера linode (по ssh)

thomas@vannevar:~$ time curl -Iv https://getsimpleapps.com/happy-ending/api/script.js?shop=holstee.myshopify.com
* About to connect() to getsimpleapps.com port 443 (#0)
*   Trying 50.116.58.18... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: OU=Domain Control Validated; OU=Provided by New Dream Network, LLC; OU=DreamHost Basic SSL; CN=getsimpleapps.com
*    start date: 2012-02-23 00:00:00 GMT
*    expire date: 2013-02-22 23:59:59 GMT
*    subjectAltName: getsimpleapps.com matched
*    issuer: C=GB; ST=Greater Manchester; L=Salford; O=Comodo CA Limited; CN=PositiveSSL CA
*    SSL certificate verify ok.
> HEAD /happy-ending/api/script.js?shop=holstee.myshopify.com HTTP/1.1
> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: getsimpleapps.com
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Thu, 02 Aug 2012 20:43:30 GMT
Date: Thu, 02 Aug 2012 20:43:30 GMT
< Server: Apache/2.2.22 (Ubuntu)
Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.3.10-1ubuntu3.2
X-Powered-By: PHP/5.3.10-1ubuntu3.2
< Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2204a54136cab08f9fdc5f082ebb8e739a%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A12%3A%2250.116.58.18%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A97%3A%22curl%2F7.22.0+%28i686-pc-linux-gnu%29+libcurl%2F7.22.0+OpenSSL%2F1.0.1+zlib%2F1.2.3.4+libidn%2F1.23+librtmp%2F2.3%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343940210%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7De7d7b8e2ca69b34c531ba7472b4b21b7; expires=Thu, 02-Aug-2012 22:43:30 GMT; path=/
Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2204a54136cab08f9fdc5f082ebb8e739a%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A12%3A%2250.116.58.18%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A97%3A%22curl%2F7.22.0+%28i686-pc-linux-gnu%29+libcurl%2F7.22.0+OpenSSL%2F1.0.1+zlib%2F1.2.3.4+libidn%2F1.23+librtmp%2F2.3%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343940210%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7De7d7b8e2ca69b34c531ba7472b4b21b7; expires=Thu, 02-Aug-2012 22:43:30 GMT; path=/
< Content-Type: text/javascript
Content-Type: text/javascript
* no chunk, no close, no size. Assume close to signal end

< 
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

real    0m25.991s
user    0m0.015s
sys 0m0.022s

У меня была такая же проблема, с почти идентичными различиями во времени ответа между HTTP и HTTPS. Оказалось, проблема была в том, что ответ @htmltiger: Apache2 просто исчерпал рабочие процессы.

Это приводит к тому, что новые запросы ставятся в очередь, пока работник не освободится и не сможет обработать следующий [источник]. Я полагаю, причина, по которой это затрагивает только HTTPS, а не также и HTTP, в том, что почти весь ваш трафик идет по HTTP, и Apache дает HTTP и HTTPS запросам одинаковый приоритет, беря по одному запросу из каждой очереди по очереди. Поэтому, когда очередь HTTPS значительно длиннее, запросы ждут значительно дольше. На самом деле есть две очереди, так как очередь – это просто механизм очереди TCP в Linux, и Linux предоставляет одну очередь на порт.

Диагностика

Если это ваша проблема, то применимы следующие симптомы:

  • Лучший индикатор: на вашем сервере apachectl status показывает, что все допустимые рабочие процессы работают. Это происходит, когда не показаны точки . в линии табло процессов, что указывает на отсутствие “Открытого слота без текущего процесса”. Линия может выглядеть, например, так:

    KKKKKKRKKKRRCWKKKCCKWKKKKCRCKKKKKKKCKCKKKKWRKKKKWRWKKKKKKCWKKWKKK

  • Вы видите такие сообщения в основном журналы ошибок Apache2 (/var/log/apache2/error.log, а не конкретные для домена):

    [mpm_prefork:error] [pid 4715] AH00161: server reached MaxRequestWorkers 
    setting, consider raising the MaxRequestWorkers setting

  • В вашем Apache много процессов в очереди. Согласно этой углубленной статье, вы можете увидеть это по значению unacked: в выводе ss -lti '( sport = :https )'. Тем не менее, в зависимости от версии или конфигурации ss, это значение может отсутствовать.

  • Большая часть задержки (скажем, 17 из 20 с) отображается в консоли сети Firefox, в разделе “Времена” для начального запрашиваемого URL как “Блокировка”.

Решение

Это предполагает, что вы используете модуль сервера prefork MPM в Apache. Однако это аналогично для модулей MPM “event” и “worker” – подробности.

  1. Отредактируйте /etc/apache2/mods-enabled/mpm_prefork.conf и увеличьте настройку MaxRequestWorkers.

  2. Если вы увеличиваете его выше значения по умолчанию 256, вам также нужно установить ServerLimit на то же значение, чтобы ваши изменения стали эффективными.

  3. Примените изменения: service apache2 reload

  4. Убедитесь в выводе табло apachectl status, что новое значение MaxRequestWorkers эффективно. Оно должно быть эквивалентно длине строки табло в символах.

  5. Если настройка еще не эффективна, поищите в /etc/apache2 старые директивы конфигурации (и их ещё более старые устаревшие синонимы), которые могут перекрывать ваши изменения:

    grep -R MaxRequestWorkers /etc/apache2/*
grep -R MaxClients /etc/apache2/*

Дифференциальные диагнозы

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

Оказалось, что моя проблема заключалась в том, что мои ключи были с другого сервера. Мне нужно было получить новый сертификат и настроить его с новыми ключами.

У меня была похожая проблема на загруженном сервере, но увеличение MaxRequestWorkers до 400 в mpm_prefork.conf решило ее.

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

Попробуйте изменить шифр на RC4-MD5 (хороший баланс производительности и безопасности), т.е.: 

SSLCipherSuite RC4-MD5

Удачи

Ответ или решение

Проблема с производительностью: HTTPS значительно медленнее HTTP на вашем сайте

При переходе на HTTPS вы заметили проблему с производительностью, где время загрузки некоторых ресурсов, таких как JavaScript-файлы на вашем сайте, увеличилось более чем в 50 раз по сравнению с HTTP. Это явление может быть вызвано различными факторами, включая настройки вашего сервера, конфигурацию SSL/TLS и даже уровень нагрузки на сервер.

Возможные причины медленной работы HTTPS

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

  2. Конфигурация сервера:

    • Неправильные настройки сервера, такие как слишком маленькое количество рабочих процессов в Apache, могут приводить к тому, что запросы HTTPS накапливаются в очереди. Если все рабочие процессы заняты обработкой запросов HTTP, новые запросы HTTPS могут ожидать освобождения рабочих процессов, что и вызывает задержку.
    • Проверьте параметры MaxRequestWorkers и ServerLimit в вашей конфигурации Apache. Если эти значения слишком низкие, увеличьте их. Например, вы можете установить MaxRequestWorkers на 400, если ваша серверная инфраструктура это позволяет.

  3. Проблемы с сертификатами: Убедитесь, что SSL-сертификаты и ключи соответствуют вашему домену. Если вы используете неподходящие сертификаты (например, с другого сервера), это может вызывать дополнительно задержки при установлении соединения.

  4. Логи и уровень детализации: Попробуйте понизить уровень логирования Apache. Высокие уровни логирования (например, LogLevel trace8) могут приводить к дополнительным затратам на поддержку этих логов, замедляя обработку запросов.

  5. Первая выборка и обмен ключами: Процесс установки соединения TLS (включая рукопожатие и обмен ключами) обычно занимает больше времени, чем простое HTTP-соединение. Если ваш сервер перегружен, это может добавить дополнительную задержку.

Рекомендации по улучшению производительности HTTPS

  1. Настройка Apache:

    • Убедитесь, что в конфигурации mpm_prefork.conf (или аналогичном для вашего MPM) установлены адекватные рычаги регулировки, такие как MaxRequestWorkers и ServerLimit.
    • Проведите тестирование с помощью apachectl status для проверки статуса рабочих процессов. Идеально, чтобы на дисплее не было "свободных слотов".

  2. Оптимизация шифрования: Используйте современные и быстрые криптографические алгоритмы. Для этого можете попробовать следующее:

    SSLCipherSuite High:!aNULL:!MD5

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

  3. Использование HTTP/2: Убедитесь, что ваш сервер поддерживает и использует HTTP/2. Этот протокол значительно ускоряет загрузку за счет мультиплексирования запросов в рамках одного соединения.

  4. Мониторинг и сбор данных: Используйте инструменты мониторинга производительности для отслеживания время ответа сервера на запросы HTTPS. Это поможет вам легко идентифицировать узкие места.

  5. Руководства и ресурсы: Не забудьте ознакомиться с рекомендациями по оптимизации HTTPS на сайте Mozilla Developer Network и Apache HTTP Server.

Заключение

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

apache-2.2 https ssl ubuntu
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности