HTTPS es más de 50 veces más lento que HTTP

8

Tengo un sitio web que usa https para transmitir un archivo javascript al cliente. El sitio web es getsimpleapps.com .

Resulta que este archivo se carga 52 veces más lento con https (20.08s - 29.08s) que con http (380ms).

La página de inicio del sitio comparte la misma lentitud que el archivo javacript.

Recientemente me cambié de dreamhost a linode, y pirateé para que SSL funcione en el nuevo servidor hasta que lo hizo. No hice ninguna configuración loca.

El linode ejecuta Ubuntu 12.04 y el sitio está encima de una pila (LAMP).

Mi pregunta para la comunidad de desbordamiento de pila es: ¿cómo hago para arreglar SSL y HTTPS en mi servidor? Sé que el desbordamiento de la pila está plagado de preguntas sobre la lentitud de HTTPS, pero no se dan soluciones reales. Un tutorial de ubuntu o una guía de configuración sería ideal.


archivo: /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 desde la estación de trabajo 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 desde el servidor linode (a través de 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
ThomasReggi
fuente
1
"It turns out that this file is loading 52% slower with https (20.08s - 29.08s) that with http (380ms)."- ¿eh? ¿Puede verificar sus unidades y gramática allí, por favor? Eso no tiene mucho sentido.
MDMarra
1
Creo que el OP significó 53 veces más lento. El HTTPS se está cargando muy lento.
Tal vez solo dejes caer virtualmin y le permitas configurar todo por ti.
Andrew Smith el
1
Hmm Esto está mal. ¿Hay algo en los registros de Apache que pueda indicar dónde está la desaceleración? En mi servidor, veo que tarda 263 ms para HTTPS y 84 ms para HTTP. La gran diferencia que estás viendo se debe a algo más.
cjc
1
Pegue su configuración de Apache.
Michael Hampton

Respuestas:

3

Tuve el mismo problema, con diferencias de tiempo de respuesta casi idénticas entre HTTP y HTTPS. Resulta que el problema era como en la respuesta de @htmltiger : Apache2 simplemente se estaba quedando sin procesos de trabajo.

Esto hace que las nuevas solicitudes se pongan en cola hasta que un trabajador quede libre y pueda procesar la siguiente [ fuente ]. Supongo que la razón por la que esto solo afecta a HTTPS y no también a HTTPS es que casi todo el tráfico se realiza a través de HTTP y Apache otorga a las solicitudes HTTP y HTTPS la misma prioridad, tomando una solicitud de cada cola. Entonces, cuando la cola HTTPS es mucho más larga, las solicitudes esperan mucho más. De hecho, hay dos colas, ya que la cola es simplemente el mecanismo de la cola de conexión TCP de Linux, y Linux proporciona una cola por puerto.

Diagnósticos

Si este es su problema, se aplicarán los siguientes síntomas:

  • El mejor indicador: en su servidor, apachectl statusmuestra que todos los procesos de trabajo permitidos se están ejecutando. Este es el caso cuando no .se muestran puntos en la línea del marcador del proceso, lo que indica que no queda "Ranura abierta sin proceso actual". La línea podría verse así, por ejemplo:

    KKKKKKRKKKRRCWKKKCCKWKKKKCRCKKKKKKKCKCKKKKWRKKKKWRWKKKKKKCWKKWKKK
    
  • Verá mensajes como este en su registro principal de errores de Apache2 ( /var/log/apache2/error.logno los de dominio específico):

    [mpm_prefork:error] [pid 4715] AH00161: server reached MaxRequestWorkers 
        setting, consider raising the MaxRequestWorkers setting
    
  • Hay muchos procesos en su reserva de Apache. De acuerdo con este artículo en profundidad , puede ver esto desde el unacked:valor en la ss -lti '( sport = :https )'salida. Dependiendo de la versión o configuración de ss, ese valor puede faltar sin embargo.

  • La mayor parte del retraso (digamos, 17 de 20 s) se muestra en la consola de red de Firefox, en la pestaña "Tiempos" para la URL inicial solicitada, como "Bloqueo".

Solución

Esto supone que usa el módulo del servidor MPM prefork en Apache. Sin embargo, es similar para los módulos MPM "evento" y "trabajador": detalles .

  1. Edite /etc/apache2/mods-enabled/mpm_prefork.confy aumente la MaxRequestWorkersconfiguración.

  2. Si lo aumenta más allá del valor predeterminado de 256, también debe establecer ServerLimit en el mismo valor para que su cambio sea efectivo.

  3. Aplicar los cambios: service apache2 reload

  4. Asegúrese de que en el resultado del tablero de resultados apachectl statusla nueva MaxRequestWorkersconfiguración sea efectiva. Tiene que ser equivalente a la longitud de la línea del marcador en caracteres.

  5. Si la configuración aún no es efectiva, busque /etc/apache2directivas de configuración antiguas (y sus sinónimos obsoletos incluso más antiguos) que podrían sobrescribir su cambio:

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

Diagnósticos diferenciales

En caso de que vea que HTTPS es mucho más lento que HTTP pero no todas las veces en una serie de recargas de página (solo en promedio), es posible que tenga una variante de este problema sofisticado , con dos servidores Apache2 ejecutándose en el puerto SSL 443.

Tanius
fuente
0

Intente cambiar el cifrado a RC4-MD5 (buen equilibrio de rendimiento y seguridad), es decir:

SSLCipherSuite RC4-MD5

Salud

HTTP500
fuente
2
La disparidad reportada entre HTTP y HTTPS no es causada por una elección de cifrado. Es otra mala configuración.
cjc
@cjc Me gustaría ver si hace la diferencia ... no puede hacer daño intentarlo.
HTTP500
@ HTTP500 poner esto en httpd.conf? ¿Qué hay de SSLProtocol all?
ThomasReggi
@ThomasReggi, simplemente colóquelo debajo de su SSLEngine On line. Sugeriría: SSLProtocol all -SSLv2
HTTP500
¡¿Qué?! ahora es mucho más rápido No reinicié apache2 ¿está bien?
ThomasReggi
0

Tuve un problema similar para un servidor ocupado pero el aumento de MaxRequestWorkers a 400 en mpm_prefork.conf lo solucionó.

htmltiger
fuente
-1

Resulta que mi problema era que mis claves eran de otro servidor. Necesitaba obtener un nuevo certificado y configurarlo con nuevas claves.

ThomasReggi
fuente