Chrome ralentiza sobre los sitios https, especialmente los internos

8

Estamos tratando de implementar Google Chrome en nuestra red corporativa, pero descubrimos que demora entre 2 y 4 veces más en cargar una página https (particularmente las nuestras internas) en comparación con IE. ¿Alguien ha experimentado esto y ha encontrado una solución?

Actualizar

Basado en la sugerencia de Handyman5, ejecuté algunos diagnósticos en Chrome y descubrí que la mayor cantidad de tiempo (más del 90% en cada página) se dedicaba a extraer archivos estáticos de la caché y renderizar la página. Sin embargo, si apago SSL en nuestro sitio, esto es casi instantáneo.

¿Alguna idea de por qué sería esto?

Bip bip
fuente
¿Se puede agregar una traza tcpdump? Eso realmente ayudaría. ¿Se está quedando sin IPV6 en su red? De vez en cuando me encuentro con este problema donde el administrador del sistema agrega registros DNS pero no habilita V6 en el punto final remoto
Lmwangi
No estamos ejecutando IPV6, y no creo que los registros DNS sean aplicables ya que estamos accediendo al sitio directamente (es decir, https: // 192.168.0.33/). Intentaré instalar wireshark o una herramienta similar en un escritorio para ver si puedo publicar un rastro.
Beep beep
qué servidores DNS usas /
warren
No parece importar ... DNS interno, Verizon, o incluso cuando se accede al sitio por dirección IP.
Beep beep

Respuestas:

18

Chrome tiene una increíble herramienta de diagnóstico integrada, "about: net-internals" , que está diseñada para ayudar a solucionar problemas de red. En particular, tiene una pestaña "Eventos" que le permite especificar una URL y luego Chrome desglosa todo el proceso de carga, paso a paso, incluida la resolución DNS, los aciertos de caché y las solicitudes de elementos AJAX.

Manitas5
fuente
Wow, nunca supe de esto. Lo probaré, gracias!
Beep beep
Extraño ... Me pregunto si Chrome maneja el almacenamiento en caché en sitios seguros de manera diferente a IE. Después de ejecutar esto y la línea de tiempo en las herramientas del desarrollador de Chrome, parece que el tiempo más largo se dedica al procesamiento de archivos estáticos desde la caché. En un sitio no seguro, este no es el caso: extrae los archivos de caché casi instantáneamente. Por ejemplo, en una página pequeña, tardó 100 ms en recibir el contenido dinámico de la página, pero luego otros 1,9 segundos para extraer JavaScript del caché. En IE, esta página se abre en menos de .5 segundos, y cuando apago SSL se abre aún más rápido en Chrome.
Beep beep
La característica ha sido eliminada. El siguiente texto se muestra en la pestaña Eventos: Se ha eliminado el visor de eventos net-internals y la funcionalidad relacionada. Utilice chrome: // net-export para guardar netlogs y la catapulta externa netlog_viewer para verlos.
MHeld
8

tl; dr Verifica cómo Chrome maneja la verificación y revocación de certificados.

Tuvimos un problema muy similar en una instalación en la que trabajé anteriormente, pero con Firefox. Para que esto sea un problema, debe confirmar que el problema es solo con las páginas https. Si no, hará poca diferencia.

Con Firefox (lo sé, lo sé, puedo leer, apunte próximamente), un grupo de personas tuvo problemas mientras que los usuarios de Internet Explorer (si puede creerlo) no. Habíamos utilizado la infame autoridad de ipsCA porque eran gratuitos para las instituciones educativas, pero finalmente enojaron a Firefox con su vergüenza y el control de sus certificados por parte de OCSP fue el culpable . Resulta que el navegador se estaba demorando debido al procesamiento de las Listas de revocación de certificados debido a la naturaleza de nuestros certificados SSL. Obviamente, como el mejor de nosotros, no mencionó su versión de Chrome, por lo que es difícil decir si fue un problemao sigue siendo un problema. Sin embargo, verificaría la configuración de CRL en Chrome. Hacerlo en Firefox alivió el problema. Además, verifique que sus certificados estén en regla, es decir, si están autofirmados. Lo que lo dejó en uso es que nos alejamos de la firma personal porque los usuarios idiotas de nuestros servicios se quejaban mucho y era gratis. Pensamos que nos estábamos ahorrando un dolor de cabeza, pero lo empeoramos.

songei2f
fuente
Buena idea: nuestras aplicaciones internas todavía están en desarrollo y están autofirmadas, por lo que tal vez ese sea el problema. Vamos a comprar un certificado real, tal vez eso haga la diferencia.
Beep beep
Bueno, desprecio entonces. Este problema sería con certificados firmados de una CA real, pero la CA resulta ser horrible. Probablemente este no sea tu problema entonces.
songei2f
Todavía lo intentaremos, agradezco los comentarios
Beep beep
2

Implementamos Google Chrome internamente, para admitir una aplicación desarrollada a medida (en ASP.NET MVC) pero ejecutándose en HTTP normal.

También tuvimos problemas con las páginas lentas debido al caché. Parece que Chrome extraía todos los archivos estáticos en cada carga de página y no los guardaba en su caché. Terminamos simplemente agregando encabezados caducados a nuestra aplicación para forzar el caché, y funcionó.

Podría seguir esa ruta (modificar sus aplicaciones web para especificar la estrategia de almacenamiento en caché para cada tipo de archivo) o investigar más el comportamiento de almacenamiento en caché predeterminado de Chrome.

Otros parecen tener problemas similares (por ejemplo, http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en ).

Este artículo puede ser útil ya que proporciona un manual sobre el almacenamiento en caché de Chrome: http://gent.ilcore.com/2011/02/chromes-10-caches.html

Lessan Vaezi
fuente
Nuestro problema no es que los archivos se vuelvan a transmitir, sino que la extracción de los archivos en caché (en la memoria del lado del cliente) es realmente lenta. Supongo que nuestros usuarios internos utilizarán IE.
Beep beep
2

Me encontraba con el mismo problema. Después de buscar durante mucho tiempo, descubrí que con la herramienta de monitoreo de procesos ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) Chrome estaba teniendo muchas colisiones al intentar escribir en% TEMP%. Borrar este directorio resolvió el problema para mí.

Yousef
fuente
1
También solucioné el problema para mí
Jakob Kruse
1

Al final, no pude encontrar una respuesta aquí. Todas las pruebas de monitoreo y creación de perfiles muestran que Google Chrome tarda mucho en cargar contenido estático seguro desde la memoria caché del cliente local. No tengo idea de por qué. Tuvimos que hacer que todos nuestros usuarios internos cambiaran a IE (que es lo que hizo la mayoría de las personas con problemas similares en la web).

Bip bip
fuente
0

Si el servidor es un servidor de aplicaciones basado en Java, hay un error común de Java que causa que los tickets de sesión TLS causen un gran retraso. Puede simular el error utilizando un openssl s_client realmente nuevo y diciéndole que habilite / deshabilite los tickets de sesión.

El verdadero culpable son las extensiones JSSE vs. TLS con valores nulos, que los tickets de sesión usan en la primera solicitud.

Covener
fuente
El back-end es ASP.NET MVC.
Beep beep
0

Cualquier posibilidad de que su servidor se quede sin datos aleatorios. En Linux, si usa /dev/randomy se queda sin datos aleatorios, su servidor se bloqueará y la carga de la página parecerá que se bloquea.

Por /dev/urandomlo general es lo suficientemente bueno. Si ese no es el caso, puede obtener hardware que generará datos aleatorios para usted.

Veo que está ejecutando ASP .NET: no puedo comentar si es un problema en Windows, pero vale la pena echarle un vistazo.

Martin M.
fuente
No lo creo, ya que solo está en Chrome (y hasta cierto punto en Firefox). Nuestro sitio es increíblemente rápido en IE o en cualquier navegador si HTTPS está desactivado. Parece estar relacionado con la extracción de datos del caché del lado del cliente. Chrome lo hace MUY lentamente para un sitio HTTPS, pero rápidamente para anon-https. No tiene ningún sentido para mí.
Beep beep