Les forums sont fermés. Ils restent présent pour consultation et archivage.
Vous pouvez désormais poser vos questions directement dans les commentaires en bas de chaque page du site.
Alors n'hésitez pas à participer

pourquoi IE8 envoit autant de commandes TCP RST

Bonjour, D'abord, une petite mise en contexte de mon problème : Je travaille sur un module développé par mon entreprise pouvant être configuré en utilisant un navigateur. Malheureusement, il n'est pour l'instant utilisable qu'avec IE.(oublions firefox, chrome, safari, etc. bien qu'à moyen terme je propose à mon entreprise de refaire les pages web pour être conpatible avec ces navigateurs!). Jusqu'à présent, les pages de configurations se chargeaient comme un charme avec IE6 et IE7. Mais depuis que IE8 est disponible, le chargement est devenu fastidieux. Des éléments refusent de se charger et parfois certaines pages refusent tout simplement de répondre. Le résultat est non professionnel et j'ai le mandat, au minimum, d'expliquer pourquoi le module répond difficilement avec IE8. En observant l'échanges de commandes TCP entre IE8 et mon module, je constate que IE8 envoi souvent des commandes TCP RST forçant la retransmission des fichiers plusieurs fois. Dans le cas de IE6 et IE7, le flag RST était peu ou pas du tout envoyé durant le chargement. Je ne sais pas si c'est ce qui cause que les pages web soient difficile à visionner sur IE8, mais jusqu'à présent c'est ma principale piste. Est-ce que quelqu'un sait ce qui peut pousser IE8 à envoyer tant de RST alors que IE6 et 7 en envoyait pas (ou plutôt, seulement lorsque c'est réellement nécessaire...) Merci d'avance!

Les RST ne forcent pas à retélécharger des informations. Ils servent à mettre fin à la connexion TCP entre le client et le serveur. C'est pas propre au sens TCP mais c'est tout à fait (à mon avis) adapté à la situation. Lorsqu'on surfe le web, on a pas besoin de maintenir une session TCP entre le client et le serveur. On economise ainsi des ressources machine et réseau. Alors, dès que tu commences a lire des pages, ton explorateur met fin à la connexion. Il le fait avec un RST car il économise ainsi des messages réseau (et donc la aussi des ressources). Un message RST est plus rapide qu'une négociation de fin de connexion. Maintenant I8 gérant plus de connexions simultanées, il est possible qu'en proportion, on retrouve plus de RST. Mais ce comportement est le même sous IE 6 et 7 et surtout, c'est un comportement normal (sic).

Merci de ton avis, Je trouve quand même curieux que IE8 envoie des RST alors que le module n'a pas terminé d'envoyer un fichier(et comme le fichier est incomplet, le navigateur doit nécessairement le redemander). J'ai trouvé quelques mentions d'un "lookhead download" de IE sur internet, peut-être que c'est cette fonctionnalité qui fait en sorte de terminer abruptement une connexion pour en commencer une nouvelle pour accélérer l'affichage d'une page. Je constate facilement que les fichiers sont incomplet en utilisant la fonctionnalité de Wireshark "Follow TCP Stream". Le fichier en cours de transmission est tronqué par un message RST( alors que les # de Ack et # de séquence sont correctement respecté). Si au moins IE8 laissait la chance à mon module de transmettre ses fichiers au complet avant de terminer la connexion... Ce que permettait IE6 et 7.

Je voudrais aussi préciser que j'ai pensé à l'incompatibilité de la page avec la nouvelle version de IE8, cependant, si cela avait été le cas, la page web, à mon avis, ne fonctionnerait pas, ou du moins, réagirait mal, mais réagirait mal toujours de la même façon. Or, lorsqu'une page web a de la difficulté à s'exécuter, je n'ai qu'à rafraîchir la page web quelques fois et je finis généralement(mais pas toujours) par obtenir une page web parfaitement utilisable. On pourrait soupçonner que du côté du module, la gestion du TCP/IP n'est pas complètement fonctionnelle (en effet, je ne peux en être sûr à 100% puisque je n'étais pas présent lors de la conception de ce module...), cependant, comme j'ai précisé dans mon premier message, le module réagit parfaitement sous IE6 et IE7. Ainsi, j'arrive à la conclusion que tout ce qui peut influencer le module est sa communication TCP/HTML avec IE8, et comme IE8 ne cesse d'envoyer des RST durant la transmission des données, je continu à douter. Je ne suis pas un spécialiste du TCP, loin de là. Mes cours à l'université sont loin sur ce sujet, mais je peux lire un RFC et constater que IE8 semble ne pas respecter ce protocole à la lettre (en tout cas que qui concerne le RST). Mais je peux me tromper bien entendu!

Atta je dis de la m#$*+#... Il envoit un RST lorsqu'on ferme la fenetre pas lors de connexion. Donc il y a ben est bien un problème si tu vois des RST hors de ce cadre là.

Je me disais aussi que ces RST n'étaient pas normal... Je continu toujours mes investigations... Qu'est-ce que je donnerais pour connaître quelqu'un de l'équipe IE chez Microsoft!

Je crois avoir trouvé la cause de mon problème. Je la décris ici même si elle ne s'appliquera sans doute pas à personne étant donné que le problème était du côté de mon module. Peut-être que ma solution pourra en aiguiller d'autres! Comme j'ai expliqué dans les précédents messages, j'ai remarqué que IE8 envoyait beaucoup de "resets connections". En observant les paquets TCP, j'ai remarqué que mon module ne répondait pas dans certaines conditions à demandes d'ouvertures de sockets de IE8 (SYN) qui générait des RST après quelques milisecondes d'attente. Après trop de RST, IE8 semble abandonner la partie et affiche une "page indisponible" à l'écran. Après avoir étudié le code de la stack IP de mon module, j'ai remarqué que les SYN étaient bel et bien reçu et traité par mon module, mais rejetés en cours de traitement faute de socket disponible. J'ai augmenté le nombre de socket dans mon module, recompilé le code, et mon problème était réglé (ou contourné, sans doute!). IE8 est donc plus gourmand en socket que ses prédécesseurs! J'ai maintenant plus de respect envers ceux qui sont capable de coder une stack IP et la gestion du TCP, c'est rudement complexe...