Interruption irrégulière d'Internet: certaines images et JS ne se chargent pas


11

première fois sur ServerFault, et j'ai une belle petite énigme.

Depuis quelques mois maintenant, nous avons des problèmes avec notre connectivité Internet.

Environnement:

Servers: 2 Terminal Servers as an RDSFarm running Windows Server 2008 R2
Browser: Internet Explorer 9
Test/debug browser: Chrome
AntiVirus: Avast 7.0.1455

Problème:

À intervalles irréguliers, les sites Web refusent de se charger, ce qui donne une erreur indiquant que la page n'était pas accessible ou que certaines images ne se chargent pas complètement. De plus, après l'inspection, les fichiers serveral .js ne parviennent pas à être chargés.

entrez la description de l'image ici

Résultats et ce que nous avons essayé:

Première impression:

Lorsque j'utilise Chrome pendant cet intervalle, le site renvoie un net :: Error 101 ou Error 103 après quelques rafraîchissements. À d'autres moments, s'il ne donne pas l'erreur, plusieurs images ne sont pas visibles et affichent une image X. IE dit simplement que la page ne peut pas être affichée.

entrez la description de l'image ici

Utilisation des outils de développement Chrome:

Cela montre dans la console que plusieurs ressources ne sont pas disponibles, mais lorsque je clique avec le bouton droit sur les images manquantes et sélectionne "Afficher l'image", elles s'affichent. Lorsque j'ouvre les images via une URL directe, elles s'affichent également.

entrez la description de l'image ici

Audit via Chrome Developer Tools:

J'ai effectué un audit sur une page lorsqu'elle était à l'état bogué et j'ai découvert que certains fichiers .js ne se chargeaient pas avec certains fichiers .png, .jpg et .gif. Différentes images se chargent pour Chrome et IE.

entrez la description de l'image ici entrez la description de l'image ici

Fichiers JS obscurcis et Avast:

Après avoir vérifié cela, j'ai découvert que la plupart de ces fichiers .js sont des fichiers JS obscurcis, et puisque nous exécutons Avast 7.0.1455, je me demandais si le bouclier Web n'a pas gâché les choses.

Là encore, cela ne se produit que sur le premier TS, pas sur le second.

J'ai donc désactivé WebShield pendant une journée et voir si quelque chose s'était amélioré. Ce ne fut pas le cas. Retour à la case départ.

Aucune expiration du cache sur les fichiers:

Plusieurs de ces fichiers qui ne sont pas chargés ont été signalés comme n'ayant pas d'expiration du cache.

Mise en cache:

L'un de nos administrateurs système a changé la taille du cache IE à 10 Mo il y a quelque temps, ce qui, à mon avis, pourrait être à l'origine du problème. Il l'a changé à 65 Mo environ, mais les gens ont toujours des problèmes avec leurs images. Cela se produit également sur 1 TS, et également dans Chrome, donc je ne pense pas que la stratégie de groupe dictant que le cache affecterait Chrome, n'est-ce pas?

entrez la description de l'image ici

Problème de réseau: je pensais également que cela pourrait être un problème de réseau ou de routage, mais les deux serveurs TS sont sur la même carte réseau en équipe, et l'autre fonctionne très bien.

Aidez-moi!

Si quelqu'un a des conseils sur la recherche de problèmes ou a besoin de plus d'informations, veuillez m'aider. Cela me dérange depuis plusieurs semaines maintenant.

MODIFIER ET METTRE À JOUR

Le problème persiste toujours, et uniquement sur nos 2 serveurs Terminal Server.

Voici ce que moi et un collègue avons fait jusqu'à présent:

  • Désactivez l'Antivirus pendant une journée sur un serveur, pour voir si cela ne s'est pas produit. Le problème est toujours survenu.

  • Vérification de la taille MTU
    C'est le paramètre par défaut (j'ai oublié la valeur exacte: P) Un problème est toujours survenu.

  • Mises à jour Windows installées, IE10 Problème toujours survenu.

  • Vérifié s'il y avait des procurations.
    L'AV place un proxy en tant que soi-disant WebShield. Nous avons désactivé le service et le programme sur un serveur pendant une journée. Le problème est toujours survenu.

  • Réinstallation de l'équipe NIC alors qu'elle se gâchait. (A également réinstallé les pilotes NIC) Un problème est toujours survenu.

  • Stratégies de groupe vérifiées Apparemment, dans les deux serveurs Terminal Server, il y avait une stratégie de machine locale qui activait le mode Préférence dans IE, qui avait fait une personnalisation étrange. Désactivé cela, et ... Un problème est toujours survenu.

C'est maintenant même allé dans la mesure où les gens ont des problèmes pour télécharger et télécharger des fichiers à partir de SharePoint, et de nombreux sites que nous utilisons ne fonctionnent pas à cause de cela.

Intuitions

C'est soit à cause de WebShield qui coupe la connexion lorsqu'il trouve quelque chose de particulier, mais cela ne devrait pas se produire lorsque l'AV est éteint.

Il se pourrait que les redirections soient gâchées d'une manière ou d'une autre, ou qu'il y ait quelque chose avec le cache. Étrange cependant, le même problème se produit dans Chrome ainsi que dans IE9 et IE10.

Si quelqu'un a des idées, ce serait grandement apprécié.

Merci à HopelessN00b de m'avoir aidé!

MISE À JOUR:

Nous obtenons des erreurs dans l'Observateur d'événements comme celui-ci sur l'un de nos TS d'origine:

Error: (04/04/2013 08:44:42 AM) (Source: Application Error) (User: )
Description: Faulting application name: iexplore.exe, version: 9.0.8112.16470, time stamp: 0x510c8801
Faulting module name: MSHTML.dll, version: 9.0.8112.16470, time stamp: 0x510c9046
Exception code: 0xc0000005
Fault offset: 0x002d0174
Faulting process id: 0x21728
Faulting application start time: 0xiexplore.exe0
Faulting application path: iexplore.exe1
Faulting module path: iexplore.exe2
Report Id: iexplore.exe3

Et parfois, cela apparaît, mais apparemment, c'est parce que certains terminaux WYSE sont trop anciens (les remplacer par des Raspberry Pi bientôt, espérons-le).

Error: (04/04/2013 11:21:46 AM) (Source: TermDD) (User: )
Description: The Terminal Server security layer detected an error in the protocol stream and has disconnected the client.
Client IP: [IP REDACTED].

J'espère que cela t'aides.


1
Cela me rappelle des problèmes que nous avons vus sous un angle complètement différent, essentiellement liés à la configuration MTU, quelque part l'encapsulation des paquets n'avait pas été prise en considération et les paquets fragmentés n'étaient pas correctement réassemblés, donc quelque chose de plus grand qu'un seul le paquet ne serait tout simplement pas chargé ... si la page était https, rien du tout ne se chargerait.
NickW

1
Pas de problème, j'essaierais de l'exécuter quelque part entre le TS et la ou les machines qui ont des problèmes. Peut-être que votre réseau peut refléter le port où le TS est connecté (ou la machine à partir de laquelle vous testez) afin que vous puissiez y coller une machine avec wirehark pour voir le trafic.
NickW

1
Ouais, ça ne devrait pas causer beaucoup de problèmes.
NickW

1
BTW, vous avez examiné quelque chose comme ça à droite: community.spiceworks.com/topic/…
NickW

4
il y a deux choses que j'essaierais quand cela se produit. Si ce n'est que le domaine et JS, vérifiez les routes vers les serveurs sur lesquels ils se trouvent (le pathping est assez soigné là-bas) - car si ce ne sont que quelques éléments, cela vaut la peine de déterminer ce qui est commun et pourquoi ils échouent. Il y a aussi une légère chance que ce soit une mauvaise configuration du FAI - mon FAI à la maison l'a fait, et c'était une douleur dans le cul à retrouver, et a été corrigé de manière entièrement aléatoire un jour
Journeyman Geek

Réponses:


0

Essayez sans coller les cartes réseau. Configurez une seule carte réseau et voyez si les choses fonctionnent toujours. Dans le cas où il s'assure que la configuration de votre port de commutateur et la configuration de Teaming sont alignées.


Il me semble que cela devrait être un commentaire plutôt qu'une réponse. Bonne idée cependant. J'ai vu une cause défectueuse de l'équipe NIC, beaucoup de problèmes étranges de mon temps.
HopelessN00b

Lors de la réinstallation de l'équipe NIC, nous avons essayé de fonctionner sans équipe, sur une seule carte réseau. Ça n'a pas marché non plus.
blaa

0

Pour diagnostiquer le problème sans message d'erreur précis, vous devez exécuter:

  • tcpdump côté client (Wireshark a un bel affichage)
  • tcpdump côté serveur (voir ce que le serveur envoie réellement).
  • attendez que le problème se produise
  • examinez les paquets et voyez où la communication est interrompue. Si vous avez besoin d'aide pour examiner la trace, écrivez-la dans un fichier.

Je soupçonne que vous trouverez une requête DNS sans réponse. Si votre FAI filtre votre trafic via un proxy, vous devriez pouvoir en trouver des traces dans le trafic, notamment en comparant la capture côté serveur à la capture côté client.

S'il y a un problème de qualité du réseau, vous pourrez peut-être l'observer plus directement avec traceroute. Si le vidage du réseau montre que les communications se sont bien déroulées, mais que le navigateur ne peut pas afficher les données fournies, votre problème est lié aux problèmes de bureau sur le serveur Terminal Server.

Vous devez exécuter la capture de paquets sur le serveur Terminal Server qui établit la connexion du navigateur qui ne fonctionne pas.


0

Le problème a été "résolu" par le FAI. Toutes les images et JS et autres apparaissent normalement maintenant pour une bonne semaine. Le seul site externe ne pouvant pas être atteint a été résolu par le FAI en plaçant un proxy entre tous.

Malheureusement, la raison exacte pour laquelle cela s'est produit ou comment cela s'est produit reste un mystère, mais il y a fort à parier que mon FAI a changé quelque chose qui a fait l'affaire.

Merci à tous pour le soutien, et bien que beaucoup de réponses aient été très utiles, je ne peux pas choisir l'une d'entre elles pour être la bonne, donc la mienne.

Merci encore pour tout votre temps et vos efforts, et j'espère que personne d'autre n'aura à faire face à une telle étrangeté de réseautage.


1
J'espérais voir quelque chose comme ça un jour!
NickW
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.