HTTPS est plus de 50 fois plus lent que HTTP

8

J'ai un site Web qui utilise https pour transmettre un fichier javascript au client. Le site Web est getsimpleapps.com .

Il s'avère que ce fichier se charge 52 fois plus lentement avec https (20.08s - 29.08s) qu'avec http (380ms).

La page d'accueil du site partage la même lenteur que le fichier javacript.

Je suis récemment passé de dreamhost à linode, et j'ai piraté le fonctionnement de SSL sur le nouveau serveur jusqu'à ce qu'il le fasse. Je n'ai pas fait de configuration folle.

Le linode exécute Ubuntu 12.04 et le site est au sommet d'une pile (LAMP).

Ma question à la communauté de débordement de pile est la suivante: comment procéder pour corriger SSL et HTTPS sur mon serveur? Je sais que le débordement de pile est jonché de questions concernant la lenteur de HTTPS mais aucune vraie solution n'est donnée. Un tutoriel ubuntu ou un guide de configuration serait idéal.

fichier: /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>

Curl à partir du poste de travail local

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 depuis le serveur linode (via 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
source
1
"It turns out that this file is loading 52% slower with https (20.08s - 29.08s) that with http (380ms)."- hein? Pouvez-vous vérifier vos unités et votre grammaire, s'il vous plaît. Cela n'a pas beaucoup de sens.
— MDMarra
1
Je pense que le PO signifiait 53 fois plus lent. Le HTTPS se charge très lentement.
Peut-être que vous déposez simplement virtualmin dessus et lui permettez de tout configurer pour vous.
— Andrew Smith
1
Hmm. C'est faux. Y a-t-il quelque chose dans les journaux Apache qui peut indiquer où se situe le ralentissement? Sur mon serveur, je vois qu'il faut 263 ms pour HTTPS et 84 ms pour HTTP. La très grande différence que vous voyez est due à autre chose.
— cjc
1
Veuillez coller votre configuration Apache.
— Michael Hampton

Réponses:

3

J'ai eu le même problème, avec des différences de temps de réponse presque identiques entre HTTP et HTTPS. Il s'avère que le problème était comme dans la réponse de @htmltiger : Apache2 était simplement à court de processus de travail.

Cela provoque la mise en file d'attente de nouvelles demandes jusqu'à ce qu'un travailleur devienne libre et puisse traiter la suivante [ source ]. Je suppose que la raison pour laquelle cela n'affecte que HTTPS et pas également HTTPS est que presque tout votre trafic est sur HTTP et Apache donne aux requêtes HTTP et HTTPS la même priorité, en prenant une demande de chaque file d'attente à son tour. Ainsi, lorsque la file d'attente HTTPS est beaucoup plus longue, les demandes attendent beaucoup plus longtemps. En effet, il y a deux files d'attente, car la file d'attente est simplement le mécanisme de file d'attente de connexion TCP Linux, et Linux fournit une file d'attente par port.

Diagnostique

Si tel est votre problème, les symptômes suivants s'appliquent:

  • Le meilleur indicateur: sur votre serveur, apachectl statusmontre que tous les processus de travail autorisés sont en cours d'exécution. C'est le cas quand aucun point .n'est affiché dans la ligne du tableau de bord du processus, ce qui indique qu'il ne reste "aucun emplacement ouvert sans processus en cours". La ligne pourrait ressembler à ceci par exemple:

    KKKKKKRKKKRRCWKKKCCKWKKKKCRCKKKKKKKCKCKKKKWRKKKKWRWKKKKKKCWKKWKKK

  • Vous voyez des messages comme celui-ci dans votre journal d'erreurs Apache2 principal ( /var/log/apache2/error.log, pas ceux spécifiques au domaine):

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

  • Il existe de nombreux processus dans votre backlog Apache. Selon cet article détaillé , vous pouvez le voir à partir de la unacked:valeur en ss -lti '( sport = :https )'sortie. Selon la version ou la configuration de ss, cette valeur peut être manquante.

  • La plupart du retard (disons, 17 sur 20 s) est affiché dans la console réseau Firefox, dans l'onglet "Timings" de l'URL initiale demandée, comme "Blocking".

Solution

Cela suppose que vous utilisez le module serveur préfork MPM dans Apache. Il en est de même pour les modules MPM "événement" et "travailleur" - détails .

  1. Modifiez /etc/apache2/mods-enabled/mpm_prefork.confet augmentez le MaxRequestWorkersparamètre.

  2. Si vous l'augmentez au-delà de la valeur par défaut de 256, vous devez également définir ServerLimit à la même valeur pour que votre modification soit effective.

  3. Appliquez les modifications: service apache2 reload

  4. Assurez-vous dans la sortie du tableau de bord apachectl statusque le nouveau MaxRequestWorkersparamètre est effectif. Elle doit être équivalente à la longueur de la ligne du tableau de bord en caractères.

  5. Si le paramètre n'est pas encore effectif, recherchez les /etc/apache2anciennes directives de configuration (et leurs synonymes obsolètes encore plus anciens) qui pourraient remplacer votre modification:

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

Diagnostics différentiels

Dans le cas où vous voyez HTTPS être beaucoup plus lent que HTTP mais pas à chaque fois dans une série de rechargements de page (juste en moyenne), alors vous pourriez avoir une variante de ce problème de fantaisie , avec deux serveurs Apache2 fonctionnant sur le port SSL 443.

— tanius
source
0

Essayez de changer le chiffrement en RC4-MD5 (bon équilibre entre performances et sécurité), c'est-à-dire:

SSLCipherSuite RC4-MD5

À votre santé

— HTTP500
source
2
La disparité signalée entre HTTP et HTTPS n'est pas causée par un choix de chiffrement. C'est une autre mauvaise configuration.
— cjc
@cjc J'aimerais voir si cela fait une différence ... ça ne peut pas faire de mal d'essayer.
— HTTP500
@ HTTP500 mettre cela dans httpd.conf? Et alors SSLProtocol all?
— ThomasReggi
@ThomasReggi, mettez-le sous votre SSLEngine On line. Je suggère: SSLProtocol all -SSLv2
— HTTP500
Quoi?! c'est beaucoup plus rapide maintenant. Je n'ai pas redémarré apache2, ça va?
— ThomasReggi
0

J'ai eu un problème similaire pour un serveur occupé mais l'augmentation de MaxRequestWorkers à 400 dans mpm_prefork.conf l'a corrigé.

— htmltiger
source
-1

Il s'avère que mon problème était que mes clés provenaient d'un autre serveur. J'avais besoin d'obtenir un nouveau certificat et de le configurer avec de nouvelles clés.

— ThomasReggi
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.