Les journaux IIS affichent sc-win32-status = 64 mais uniquement via certains réseaux

J'ai une application ASP.NET fonctionnant sur un server client (W2k3, IIS6, .NET 2.0). FWIW, il s'agit d'une instance de test , elle n'a pas encore été transférée dans la production . Donc, il ne fonctionne pas sous SSL, l'équilibrage de charge, etc.

Lorsque j'arrive à l'une des pages de leur server depuis notre bureau, la page est frappée une fois. En vérifiant les journaux IIS (c: WINDOWS \ system32 \ LogFiles \ W3SVC1), affichez un GET pour cette page, puis appuyez sur un button sur la page et le file journal affiche un POST. Cela semble fonctionner correctement jusqu'à présent.

Maintenant, lorsque je passe à distance dans le réseau du client et j'habite la page d'une de ses machines locales, le file journal affiche un GET, puis je presse le button sur la page et le journal affiche deux POST à ​​la même seconde. Le premier affiche l'état (sc-status, sc-substatus, sc-win32-status) 200 0 64, le second montre 200 0 0.

Dans le file journal, les deux POST sont identiques. Fondamentalement, le journal ressemble à ceci (sauf que j'ai masqué certaines données):

  #Fields: date time s-ip cs-méthode cs-uri-tige cs-uri-query s-port cs-nom d'user c-ip cs (User-Agent) sc-status sc-substatus sc-win32-status 
 2009-08-11 20:19:32 xxxx GET /File.aspx - 80 - aaaa Mozilla / 4.0 + (compatible; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +. NET + CLR + 3.5.21022; +. NET + CLR + 3.5.30729; +. NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0) 200 0 0
 2009-08-11 20:19:45 xxxx POST /File.aspx - 80 - yyyy Mozilla / 4.0 + (compatible; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +. NET + CLR + 3.5.21022; +. NET + CLR + 3.5.30729; +. NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0) 200 0 64
 2009-08-11 20:19:45 xxxx POST /File.aspx - 80 - yyyy Mozilla / 4.0 + (compatible; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +. NET + CLR + 3.5.21022; +. NET + CLR + 3.5.30729; +. NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0) 200 0 0

Le problème est que la page est frappée deux fois. La database exécute une opération pour la première requête, puis la seconde requête détecte qu'une opération en double est effectuée et lance un message d'erreur. Les users pensent que leur fonctionnement a échoué, mais il a effectivement réussi.

La description d'erreur de sc-win32-status 64 est: "Le nom de réseau spécifié n'est plus disponible". Cela m'amène à croire, étant donné que les deux requests POST montrent un état HTTP de 200, que le server réussit à répondre à la request, mais le client n'est jamais informé et renvoie la request.

  • Comment puis-je résoudre ce problème?

  • Des idées que cela pourrait causer ce comportement sur leur réseau interne uniquement?

  • Je dois mentionner que cela se produit dans deux sites clients distincts, mais ne se produit pas dans six de nos autres sites clients, ni dans notre bureau, ni en se connectant à l'un de nos huit clients sur le Web.

  • Ce qui pourrait rendre cette reproduction 100% du time sur leur réseau local mais 0% du time ailleurs?

Mise à jour: j'ai trouvé un très petit nombre de requests POST dupliquées avec sc-win32-status de 995 au lieu de 64 tel que rapporté à l'origine. La description d'erreur de sc-win32-status = 995 est: "L'opération d'E / S a été interrompue en raison d'une sortie de thread ou d'une request d'application". Cela n'a aucun sens (count tenu du fait que j'ai un access complet au code). Je ne comprends toujours pas comment ou pourquoi ce problème se produit, mais le nouveau code d'erreur m'amène à croire que ce n'est peut-être pas un problème de réseau et je suis en train d'étudier la possibilité d'un bogue de code random.

3 Solutions collect form web for “Les journaux IIS affichent sc-win32-status = 64 mais uniquement via certains réseaux”

Voici ma compréhension du problème jusqu'à présent:

  • sc-win32-status 64 signifie "Le nom du réseau spécifié n'est plus disponible".
  • Une fois que IIS a envoyé la réponse finale au client, généralement il attend un message ACK du client.
  • Parfois, les clients réinitialisent la connection au lieu d'envoyer l'ACK final au server. Ceci n'est pas une connection gracieuse proche, donc IIS enregistre le code "64".
  • Beaucoup de clients réinitialisent la connection lorsqu'ils sont terminés, pour libérer la socket au lieu de la laisser dans TIME_WAIT / CLOSE_WAIT.
  • Les proxies ont tendance à le faire plus que d'autres.

Mise à jour: J'ai trouvé des informations intéressantes ici et ici , donc j'ai fondamentalement re-écrit la page pour m'assurer qu'il n'y avait pas de mauvais balisage, etc. et … le problème est maintenant terminé! C'était juste un coup dans l'obscurité, et je ne pouvais pas vraiment dire ce que c'était que cela a résolu le problème, car cela affectait seulement certains de nos clients dans des circonstances très spécifiques …

J'ai rencontré ce même problème lors de l'utilisation de files binarys gzipped à partir d'IIS6 via un server proxy. Je n'éprouvais aucun problème en allant directement au site.

J'ai trouvé que c'était la cause dans mon cas en exécutant Fiddler sur une machine client et en inspectant la réponse. Fiddler avertit que la réponse est codée et se plaint que le numéro magique sur le file gzip n'était pas correct.

J'ai désactivé la compression gzip pour les files binarys dans mon code et le problème s'est arrêté.

Je ne suis pas expert, mais j'ai rencontré un problème similaire qui ne s'est produit que lors de l'utilisation d'une adresse IP plutôt que d'un nom d'hôte.

Peut-être que ça aide un peu …

Tapis.

  • Comment sélectionner l'interface réseau sur un server FlexNet?
  • Virtualbox, réseau privé et access depuis la machine hôte
  • Problème de configuration des VLAN standard sur BNT G8264 et ESXi 5.5
  • Ping à partir du sous-réseau sur IPSec
  • Créer un réseau local / 16 (255.255.0.0)
  • Serveurs derrière l'équilibreur de charge
  • 2 x DL 380p génération 8 + HP Infiniband 10Gb / 40Gb 544FLR-QSFP 649282-B21
  • Comment puis-je appliquer des routes préférentiels avec BGP & Quagga?
  • Question sur le réseau
  • Conseils sur l'architecture d'entreprise
  • kvm, ne peut pas accéder aux invités de l'hôte externe
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.