Chrome ralentit sur les sites https, en particulier les sites internes


8

Nous essayons de déployer Google Chrome sur notre réseau d'entreprise, mais nous constatons qu'il faut 2 à 4 fois plus de temps pour charger une page https (en particulier nos propres pages internes) par rapport à IE. Quelqu'un a-t-il vécu cela et trouvé un correctif?

Mise à jour

Sur la base de la suggestion de Handyman5, j'ai exécuté des diagnostics dans Chrome et constaté que le plus grand temps (plus de 90% sur chaque page) était consacré à l'extraction de fichiers statiques du cache et au rendu de la page. Cependant, si je désactive SSL sur notre site, cela est presque instantané.

Avez-vous des raisons de penser que ce serait le cas?


Pouvez-vous ajouter une trace tcpdump? Cela aiderait vraiment. Utilisez-vous IPV6 sur votre réseau? Je rencontre parfois ce problème où l'administrateur système ajoute des enregistrements DNS mais n'active pas la V6 sur le point d'extrémité distant
Lmwangi

Nous n'exécutons pas IPV6, et je ne pense pas que les enregistrements DNS soient applicables puisque nous accédons directement au site (c'est-à-dire https: // 192.168.0.33/). Je vais essayer d'installer Wireshark ou un outil similaire sur un bureau pour voir si je peux publier une trace.
Bip bip

quels serveurs DNS utilisez-vous /
warren

Cela ne semble pas avoir d'importance ... DNS interne, Verizon, ou même lors de l'accès au site par adresse IP.
Bip bip

Réponses:


18

Chrome dispose d'un formidable outil de diagnostic intégré, "about: net-internals" , conçu pour aider à résoudre les problèmes de réseau. En particulier, il possède un onglet "Événements" qui vous permet de spécifier une URL, puis Chrome décompose le processus complet de son chargement, étape par étape, y compris la résolution DNS, les accès au cache et les demandes d'éléments AJAX.


Wow, je n'ai jamais su ça. Je vais l'essayer, merci!
Bip bip

Bizarre ... Je me demande si Chrome gère la mise en cache sur des sites sécurisés différemment d'IE? Après avoir exécuté cela et la chronologie dans les outils du développeur de Chrome, il semble que le temps le plus long soit consacré au traitement des fichiers statiques à partir du cache. Sur un site non sécurisé, ce n'est pas le cas - il extrait les fichiers cache presque instantanément. Par exemple, sur une petite page, il a fallu 100 ms pour recevoir le contenu dynamique de la page, mais encore 1,9 seconde pour extraire javascript du cache. Dans IE, cette page s'ouvre en moins de 0,5 seconde, et lorsque je désactive SSL, elle s'ouvre encore plus rapidement dans Chrome.
Bip bip

La fonctionnalité a été supprimée. Le texte suivant est affiché sur l'onglet Événements: Le visualiseur d'événements net-internals et les fonctionnalités associées ont été supprimés. Veuillez utiliser chrome: // net-export pour enregistrer les netlogs et la catapulte externe netlog_viewer pour les afficher.
MHeld

8

tl; dr Vérifiez comment Chrome gère la vérification et la révocation des certificats.

Nous avons eu un problème très similaire dans une installation où je travaillais auparavant, mais avec Firefox. Pour que cela soit un problème, vous devez confirmer que le problème concerne uniquement les pages https. Sinon, cela fera peu de différence.

Avec Firefox (je sais, je sais, je peux lire, point à venir), un tas de gens ont eu des problèmes, contrairement aux utilisateurs d'Internet Explorer (si vous pouvez le croire). Nous avions utilisé la tristement célèbre autorité ipsCA parce qu'ils étaient gratuits pour les établissements d'enseignement, mais nous avons finalement énervé Firefox avec leur obscurité et la vérification OCSP de leurs certificats était le coupable . Il s'avère que le navigateur tardait à cause du traitement des listes de révocation de certificats en raison de la nature de nos certificats SSL. Évidemment, en tant que meilleur d'entre nous, vous n'avez pas mentionné votre version de Chrome, donc il est difficile de dire si c'était un problèmeou est toujours un problème. Cependant, je vérifierais la configuration CRL dans Chrome. Le faire dans Firefox a atténué le problème. Vérifiez également que vos certificats sont en règle, c'est-à-dire s'ils sont auto-signés. Ce qui l'a donné à utiliser, c'est que nous nous sommes éloignés de l'auto-signature parce que les utilisateurs idiots de nos services pleurnichaient beaucoup et c'était gratuit. Nous pensions que nous nous épargnions un mal de tête, mais nous avons aggravé la situation.


Bonne pensée - nos applications internes sont toujours en développement et auto-signées, alors c'est peut-être le problème. Nous allons acheter un vrai certificat, peut-être que cela fera une différence.
Bip bip

Eh bien, ne tenez pas compte alors. Ce problème serait lié aux certificats signés d'une véritable autorité de certification, mais l'autorité de certification se révèle merdique. Ce n'est probablement pas votre problème alors.
songei2f

Nous allons toujours l'essayer, j'apprécie les commentaires
Beep beep

2

Nous avons déployé Google Chrome en interne, pour prendre en charge une application développée sur mesure (sur ASP.NET MVC) mais fonctionnant sur HTTP normal.

Nous avons également eu des problèmes avec les pages lentes à cause du cache. Il semble que Chrome tirait tous les fichiers statiques à chaque chargement de page et ne les enregistrait pas dans son cache. Nous avons fini par simplement ajouter des en-têtes expirés à notre application pour forcer le cache, et cela a fonctionné.

Vous pouvez emprunter cette voie (modifier vos applications Web pour spécifier la stratégie de mise en cache pour chaque type de fichier) ou étudier plus en détail le comportement de mise en cache par défaut de Chrome.

D'autres semblent avoir des problèmes similaires (par exemple http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en ).

Cet article peut être utile car il fournit une introduction à la mise en cache de Chrome: http://gent.ilcore.com/2011/02/chromes-10-caches.html


Notre problème n'est pas que les fichiers soient retransmis, mais plutôt que l'extraction à partir des fichiers mis en cache (dans la mémoire côté client) est vraiment lente. Je suppose que nos utilisateurs internes utiliseront IE.
Bip bip


1

En fin de compte, je n'ai pas pu trouver de réponse ici. Tous les tests de surveillance et de profilage montrent que Google Chrome est très lent à charger du contenu statique sécurisé à partir du cache client local. Je ne sais pas pourquoi. Nous avons dû faire basculer tous nos utilisateurs internes sur IE (ce que la plupart des gens ayant des problèmes similaires sur le Web ont fait).


0

Si le serveur principal est un serveur d'applications basé sur java, il existe un bogue java courant qui provoque des tickets de session TLS entraînant un énorme retard. Vous pouvez simuler le bogue en utilisant un tout nouveau openssl s_client et en lui disant d'activer / désactiver les tickets de session.

Le véritable coupable est les extensions JSSE vs TLS avec des valeurs nulles, que les tickets de session utilisent lors de la première requête.


Le back-end est ASP.NET MVC.
Bip bip

0

Toute possibilité que votre serveur manque de données aléatoires. Sous Linux, si vous utilisez /dev/randomet manquez de données aléatoires, votre serveur se bloquera et le chargement de la page aura l'air de se bloquer.

/dev/urandomEst généralement assez bon. Si ce n'est pas le cas, vous pouvez obtenir du matériel qui générera des données aléatoires pour vous.

Je vois que vous exécutez ASP .NET - Je ne peux pas dire si c'est un problème sous Windows, mais ça vaut le coup d'œil.


Ne le pensez pas, car ce n'est que dans Chrome (et dans une certaine mesure dans Firefox). Notre site est incroyablement rapide dans IE, ou dans n'importe quel navigateur si HTTPS est désactivé. Il semble être lié à l'extraction de données du cache côté client. Chrome le fait TRÈS lentement pour un site HTTPS, mais rapidement pour un non-https. Ça n'a aucun sens pour moi.
Bip bip
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.