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

8

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

Оказывается, этот файл загружается в 52 раза медленнее при использовании протокола https (20,08–29,08 с), чем при http (380 мс).

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

Я недавно переключился с Dreamhost на Linode и взломал, чтобы заставить SSL работать на новом сервере, пока он не сделал. Я не делал никаких сумасшедших настроек.

Линод работает под управлением Ubuntu 12.04, а сайт находится на вершине стека (LAMP).

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

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

<VirtualHost *:80>
     ServerAdmin admin@getsimpleapps.com
     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 admin@getsimpleapps.com
     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>

Завиток с местной рабочей станции

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

Завиток с линодного сервера (через 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
apache-2.2 ubuntu ssl https ThomasReggi
источник
1
"It turns out that this file is loading 52% slower with https (20.08s - 29.08s) that with http (380ms)."- а? Можете ли вы еще раз проверить свои единицы и грамматику там, пожалуйста. Это не имеет особого смысла.
MDMarra
1
Я думаю, что ОП означало в 53 раза медленнее. HTTPS загружается очень медленно.
Может быть, вы просто добавите на него virtualmin и позволите ему все настроить для себя.
Эндрю Смит
1
Хм. Это не верно. Есть ли в журналах Apache что-нибудь, что может указывать на замедление? Я вижу, что на моем сервере это занимает 263 мс для HTTPS и 84 мс для HTTP. Очень большая разница, которую вы видите, связана с чем-то другим.
CJC
1
Пожалуйста, вставьте свою конфигурацию Apache.
Майкл Хэмптон

Ответы:

3

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

Это приводит к тому, что новые запросы помещаются в очередь до тех пор, пока работник не освободится и не сможет обработать следующий [ источник ]. Я полагаю, что причина, по которой это влияет только на HTTPS, а не на HTTPS, заключается в том, что почти весь ваш трафик проходит через 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 - подробности .

  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.

tanius
источник
0

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

SSLCipherSuite RC4-MD5

ура

HTTP500
источник
2
Сообщаемое несоответствие между HTTP и HTTPS не вызвано выбором шифра. Это какая-то другая неверная конфигурация.
CJC
@cjc Я хотел бы посмотреть, если это что-то меняет ... попробовать не повредит.
HTTP500
@ HTTP500 положить это в httpd.conf? Как насчет SSLProtocol all?
ThomasReggi
@ThomasReggi, просто поместите его под своим SSLEngine On line. Я бы предложил: SSLProtocol all -SSLv2
HTTP500
Какая?! сейчас намного быстрее Я не перезагружал apache2 это нормально?
ThomasReggi
0

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

htmltiger
источник
-1

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

ThomasReggi
источник