Vous pouvez rencontrer des problèmes de performances Web lorsque vous utilisez Internet Explorer 6 pour accéder à une application Web hébergée sur Internet Information Services 6.0

Traductions disponibles Traductions disponibles
Numéro d'article: 922703 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Symptômes

Envisagez le scénario suivant :
  • Vous utilisez l'authentification intégrée de Windows dans un environnement d'application Microsoft Internet Information Services 6.0 (IIS 6.0).
  • Vous utilisez Microsoft Internet Explorer 6 pour accéder à une application Web hébergée sur IIS 6.0.
Dans cette situation, vous pouvez rencontrer des problèmes de performances de l'application Web.

Remarque Ce problème ne se produit pas si l'authentification anonyme est utilisée comme protocole d'authentification. Ce problème ne se produit pas non plus si vous utilisez un navigateur client différent d'Internet Explorer 6, par exemple Mozilla Firefox.

Cause

Ce problème se produit car le client Internet Explorer 6 réinitialise régulièrement les connexions TCP.

Si vous analysez une trace réseau capturée au cours de la communication peu performante entre le client et le serveur, la trace indique que la connexion TCP est réinitialisée après que le client reçoit une réponse HTTP 200 pour la ressource demandée. Le client effectue les requêtes GET avec un en-tête et une valeur HTTP ETag. Lorsque le serveur IIS 6.0 reçoit la requête, il compare la valeur ETag et détermine qu'elle correspond à la valeur actuelle du fichier demandé, à l'exception du numéro de version.

Remarque Les en-têtes ETag suivent le format suivant :

horodatage_fichier:numéro_version

Par exemple, le client Internet Explorer envoie une demande avec une valeur ETag de 0222d5bffcbc41:301a, puis le serveur envoie une réponse HTTP 200 avec une valeur ETag de 0222d5bffcbc41:3246.

Le numéro d'horodateur_fichier de la requête est le même que celui considéré par IIS 6.0 comme étant la valeur actuelle pour la ressource demandée. Toutefois, étant donné que le numéro numéro_version de la requête est différent, IIS 6.0 renvoie la version actuelle du fichier plutôt que d'indiquer à Internet Explorer de fournir sa propre copie mise en cache. Internet Explorer comprend un code spécifique qui compare le numéro d'horodateur_fichier sur une réponse HTTP 200 avec l'horodateur de la copie locale mise en cache. La connexion est réinitialisée si ces deux numéros sont identiques. Ceci est dû au fait que le client Internet Explorer s'attend à recevoir un rapport d'état 304 si le contenu est le même.

En d'autres termes, le serveur IIS 6.0 envoie une réponse HTTP 200 car il suppose que les numéros de version différents signifient que la ressource demandée par le client et par la version client pré-existante de cette ressource résidant dans le cache du navigateur ne sont pas les mêmes versions. Toutefois, Internet Explorer considère qu'il s'agit de la même version parce que le numéro d'horodateur_fichier est le même. De plus, Internet Explorer suppose qu'il reçoit une réponse HTTP 200 par erreur. Dans ce scénario, Internet Explorer réinitialise la connexion TCP.

Contournement

Si vous utilisez un ordinateur Microsoft Windows Server 2003

Pour contourner ce problème, Microsoft vous recommande de coder de manière irréversible (codage en dur) le numéro de version sur le serveur Web et de synchroniser la version de fichier pour tous les clients Internet Explorer. Tous les clients Internet Explorer auront alors des versions de tous les différents fichiers requis pour exécuter l'application. Vous devez vous assurer que le serveur et tous les clients sont synchronisés.

Remarque Si vous exécutez un environnement de ferme Web IIS 6.0, vous devrez coder en dur le même numéro de version pour tous les serveurs IIS 6.0 de la ferme.

Pour synchroniser les valeurs des numéros de version entre les clients et le serveur, procédez comme suit.
  1. Codage manuel en dur de la valeur ETag dans la métabase IIS 6.0

    Windows Server 2003 Service Pack 1 (SP1) offre la possibilité de modifier le numéro de version ETag sur IIS 6.0.
    Remarque Vous pouvez rencontrer un problème lorsque vous modifiez la valeur ETag. Dans ce cas, vous devrez installer un correctif pour résoudre ce problème. Pour plus d'informations sur ce correctif, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
    900245 La valeur du champ ETAG est mise à jour lorsque vous modifiez une propriété de métabase dans IIS 6.0
    Après avoir installé le correctif, vous pouvez coder en dur le numéro de version ETag. Toutefois, le paramètre du numéro de version ETag n'est pas défini dans l'espace de noms Active Directory Service Interfaces (ADSI). Par conséquent, vous devez utiliser l'outil Metabase Explorer (Explorateur de métabase) pour définir la valeur par ID de propriété. Pour télécharger et installer Metabase Explorer, reportez-vous au site Web de Microsoft à l'adresse suivante (en anglais) : 
    http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/993a8a36-5761-448f-889e-9ae58d072c09.mspx?mfr=true
    Remarque L'outil Metabase Explorer est inclus dans les outils du Kit de ressources IIS 6.0.

    Pour coder manuellement en dur le numéro de version ETag, procédez comme suit :
    1. Ouvrez Metabase Explorer, développez LM dans le volet gauche, puis développez W3SVC.
    2. Dans le volet droit, double-cliquez sur l'enregistrement ID 2039.
    3. Dans la zone Valeur, tapez un nombre compris entre 1 et 4294967295. Le nombre exact que vous utilisez n'a pas d'importance, à condition qu'il soit situé dans la plage spécifiée. Pour plus d'informations, reportez-vous à la page Web de Microsoft à l'adresse suivante (en anglais) :
      http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ef7f9d58- 2a96-4bd8-8ac1-2a67b43284f1.mspx
    4. Cliquez sur Appliquer, puis sur OK.
    Remarque Si vous exécutez des serveurs IIS 6.0 dans un environnement de ferme Web IIS 6.0, répétez les étapes 1a à 1d sur tous les serveurs IIS 6.0 de la ferme. Assurez-vous que vous ajoutez la même valeur de numéro de version sur tous les serveurs.
  2. Effacer le cache du navigateur client dans Internet Explorer

    Si les navigateurs client sont trop nombreux pour effacer le cache manuellement, vous pouvez sélectionner Activer l'expiration de contenu dans IIS 6.0, puis spécifier que le contenu expire immédiatement. Dans cette situation, vous devez laisser l'option Activer l'expiration de contenu activée uniquement jusqu'à ce que tous les clients reçoivent un contenu actualisé. Ensuite, vous devez désactiver l'option Activer l'expiration de contenu pour donner à Internet Explorer la possibilité de fournir à nouveau le contenu mis en cache. Pour activer l'expiration de contenu, procédez comme suit :
    1. Ouvrez les services Internet (IIS).
    2. Dans le volet gauche, développez ordinateur_local, puis cliquez sur Sites Web.
    3. Cliquez avec le bouton droit sur Sites Web, puis cliquez sur Propriétés.
    4. Sous l'onglet En-têtes HTTP, activez la case à cocher Activer l'expiration de contenu, puis cliquez sur l'option Expirer immédiatement.
    5. Arrêtez et redémarrez tous les services IIS 6.0.
    Remarque Un client devra peut-être effectuer deux requêtes après l'activation de la case à cocher Activer l'expiration de contenu pour mettre à jour le cache Internet Explorer.

Si vous n'utilisez pas un ordinateur Windows Server 2003

Pour contourner ce problème, activez l'option Activer l'expiration de contenu dans IIS 6.0 à l'aide de la procédure décrite dans la section « Effacer le cache du navigateur client dans Internet Explorer » et laissez-la activée. En outre, désactivez la mise en cache dans Internet Explorer ou définissez des en-têtes de contrôle du cache dans l'application Web. Pour plus d'informations sur la façon d'empêcher la mise en cache Web, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
311006 Comment faire pour empêcher la mise en cache Web dans Windows 2000

Statut

Ce problème a été résolu dans Microsoft Internet Explorer 7.

Plus d'informations

Si vous analysez une trace du Moniteur réseau capturée sur le client ou sur le serveur et que cette trace relève du scénario de performances réduites, vous pouvez observer la séquence suivante :
  1. Le client envoie la requête GET au serveur IIS 6.0 et la requête inclut un en-tête If-None-Match avec une valeur horodateur_fichier:numéro_version. Cette requête ressemble à la suivante :
    HTTP: GET Request from Client
    HTTP: Request Method =GET
    HTTP: Uniform Resource Identifier =/MARRS/webService.htc
    HTTP: Protocol Version =HTTP/1.1
    HTTP: Accept = */*
    HTTP: Accept-Encoding =gzip, deflate
    HTTP: If-Modified-Since =Tue, 16 Nov 2004 17:11:48 GMT
    HTTP: If-None-Match ="0222d5bffcbc41:301a" 
    HTTP: User-Agent =Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET 
    CLR 1
    HTTP: Host =nnoma-wwapp02m
    HTTP: Connection =Keep-Alive
    HTTP: Authorization =Negotiate 
    TlRMTVNTUAADAAAAGAAYAG4AAAAKAQoBhgAAAAoACgBIAAAAEgASA
    HTTP: Cookie =ASP.NET_SessionId=uqnwgpygpf0dh2iwysznat55
    
    Remarque Certaines des variables HTTP de ces exemples peuvent être différentes dans votre environnement.
  2. Le serveur reçoit la requête et envoie une réponse HTTP 200 avec les données demandées. Puisque le client a envoyé l'en-tête If-None-Match, le serveur IIS 6.0 doit inclure un en-tête de réponse ETag et une valeur d'en-tête dans sa réponse. Cette réponse ressemble à la suivante :
    HTTP: Response to Client; HTTP/1.1; Status Code = 200 - OK
    HTTP: Protocol Version =HTTP/1.1
    HTTP: Status Code = OK
    HTTP: Reason =OK
    HTTP: Content-Length =51622
    HTTP: Content-Type =text/x-component
    HTTP: Last-Modified =Tue, 16 Nov 2004 17:11:48 GMT
    HTTP: Accept-Ranges =bytes
    HTTP: ETag ="0222d5bffcbc41:3246"
    HTTP: Server =Microsoft-IIS/6.0
    HTTP: X-Powered-By = ASP.NET
    HTTP: Date =Tue, 27 Sep 2005 12:18:27 GMT
    HTTP: Data: Number of data bytes remaining = 1202 (0x04B2)
    
  3. Le client reçoit la réponse. La réponse affiche un état HTTP 200, au lieu de l'état HTTP 304 attendu par le navigateur. Par conséquent, le navigateur envoie un paquet TCP RST pour réinitialiser la connexion. Internet Explorer procède ainsi car il suppose que le serveur a envoyé la réponse HTTP 200 par erreur. Le paquet TCP RST ressemble au suivant :
    TCP: Control Bits: .A.R.., 
    TCP: Source Port = 0x0747
    TCP: Destination Port = World Wide Web HTTP
    TCP: Sequence Number = 3840808344 (0xE4EE1598)
    TCP: Acknowledgement Number = 3150159894 (0xBBC3A016)
    TCP: Data Offset = 20 bytes
    TCP: 0101.... = Data Offset (20 bytes)
    TCP: ....0000 = Reserved bits
    TCP: Flags = 0x14 : .A.R..
    TCP: ..0..... = No urgent data
    TCP: ...1.... = Acknowledgement field significant
    TCP: ....0... = No Push function
    TCP: .....1.. = Reset the connection
    TCP: ......0. = No Synchronize
    TCP: .......0 = Not the end of the data
    TCP: Window = 0 (0x0)
    TCP: Checksum = 0xF26C
    TCP: Urgent Pointer = 0 (0x0)
    
    Pour plus d'informations sur le protocole TCP (Transmission Control Protocol), reportez-vous au site Web de Microsoft à l'adresse suivante (en anglais) :
    http://www.faqs.org/rfcs/rfc793.html

Propriétés

Numéro d'article: 922703 - Dernière mise à jour: vendredi 13 avril 2007 - Version: 2.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Internet Explorer 6.0
  • Microsoft Internet Information Services 6.0
Mots-clés : 
kbtshoot kbprb KB922703
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com