Aléatoire TCP RST sur certains sites Web, qu'est-ce qui se passe?
Version courte: une machine Windows Server 2012 sur mon réseau obtient des RST persistantes mais intermittentes TCP lors de la connexion à certains sites Web. Dunno d'où ils viennent. Consultez le journal Wireshark pour mes analyses et mes questions.
Version longue:
Nous gérons un proxy Web de mise en cache sur l'un de nos serveurs pour servir notre petit bureau. Un collègue a déclaré avoir obtenu une "page de réinitialisation de la connexion" ou 'ne peut pas être affiché par des erreurs lors de la connexion à certains sites, mais que ce rafraîchissant la corrige habituellement.
J'ai vérifié le comportement du navigateur, puis plus directement en essayant un navigateur non proxé sur le serveur lui-même. Mais Pings & Tracerout à des sites gênants ne montrent aucun problème, les problèmes semblaient être limités aux connexions TCP.
J'ai ensuite fait un script pour tester les sites affectés en leur envoyant des demandes http HEAD directement via Curl & Vérification de la fréquence à laquelle ils réussissent. Un test typique ressemble à ceci: (Ceci est sans-résonance, fonctionnant directement sur le serveur Bad)
C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0 Response Code: NULL (0%)
20:22:02: Length: 0 Response Code: NULL (0%)
20:22:22: Length: 0 Response Code: NULL (0%)
20:22:42: Length: 0 Response Code: NULL (0%)
20:23:02: Length: 3173 Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174 Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0 Response Code: NULL (28.57%)
20:24:03: Length: 3171 Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173 Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172 Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0 Response Code: NULL (45.45%)
À long terme, seulement environ 60% des demandes réussissent, le reste ne renvoie rien, avec un code d'erreur de courbure de: "Erreur de courbure (56): Échec lors de la réception des données de la peer" Le mauvais comportement est cohérent pour les sites Web i Test (Aucun site n'a jamais été "mieuxvenu") et c'est assez persistant, je suis désormais dépannée pendant une semaine maintenant et les collègues signalent que le problème a été présent depuis des mois apparemment.
J'ai testé le script de demande HEAD sur d'autres machines de notre réseau: Aucun problème, toutes les connexions passent à tous les sites de ma liste de tests. Ensuite, j'ai mis en place un proxy sur mon bureau personnel et lorsque j'exécute les demandes HEAD du serveur problématique, cependant, toutes les connexions passent. Donc, quel que soit le problème, c'est très spécifique à ce serveur.
Ensuite, j'ai essayé d'isoler quels sites Web présentent le comportement de réinitialisation de la connexion:
- Aucun de nos sites intranet (192.168.x.x) Drop Connections.
- Aucun site IPv6, j'ai testé les connexions gouttes. (Nous sommes dual-pile)
- Seule une petite minorité de sites Internet IPv4 Drop Connections.
- Chaque site qui utilise Cloudflare comme CDN (que j'ai testé) abandonne des connexions. (Mais le problème ne semble pas être exclusif aux sites de Cloudflare)
Cet angle ne se développait pas vraiment utile, alors ensuite j'ai installé Wireshark pour examiner ce qui se passait quand une demande a échoué. A échoué HEAD Les demandes ressemblent à ceci: (Capture d'écran plus grande ici: http://imgur.com/tnfrutx )
127 48.709776000 192.168.1.142 192.33.31.56 TCP 66 52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000 192.33.31.56 192.168.1.142 TCP 66 http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000 192.168.1.142 192.33.31.56 TCP 54 52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000 192.168.1.142 192.33.31.56 HTTP 234 HEAD / HTTP/1.1
131 48.740917000 192.33.31.56 192.168.1.142 TCP 60 http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000 192.33.31.56 192.168.1.142 TCP 60 http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000 192.33.31.56 192.168.1.142 TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
La façon dont je lis ça (corrige-moi si je me trompe, ce n'est pas vraiment ma région) est que:
- Nous ouvrons une connexion TCP au serveur Web
- webserver ACK
- Http HEAD demande est envoyé
- Il existe un paquet RST, marqué à partir de l'IP du serveur Web, qui tue la connexion.
- Webserver envoie ACK
- Webserver (essaie) pour répondre à la requête HEAD avec des données HTTP valides (la réponse de l'octet 951 contient l'en-tête HTTP correct)
- WebServer retransmits (plusieurs fois sur plusieurs secondes) la réponse HTTP valide, mais elle ne peut pas réussir puisque la connexion a été la RST
Donc, si le serveur Web a envoyé une RST valide, pourquoi continue-t-il d'essayer de remplir la demande? Et si le serveur Web n'avait pas généré la TVD, ce que le diable a fait?
Choses que j'ai essayées qui n'ont eu aucun effet:
- Désactiver NIC Association
- Modification de l'adaptateur réseau (le remplacement NIC était connu pour fonctionner)
- Affectation d'une adresse IP statique.
- Désactiver IPv6.
- Désactiver les cadres jumbo.
- Branchez le serveur directement dans notre modem une nuit, contourner nos commutateurs et notre routeur.
- Éteindre le pare-feu Windows.
- Réinitialisation des paramètres TCP via Netsh
- Désactivation pratiquement tous les autres services sur le serveur. (Nous l'utilisons surtout comme un serveur de fichiers, mais il y a Apache & A Couple DB's)
- Couper la tête sur le bureau (à plusieurs reprises)
Je soupçonne quelque chose sur le serveur Générez les paquets RST, mais pour la vie de moi, je ne peux pas le trouver. Je me sens comme si je savais: pourquoi est-ce juste ce serveur? OR pourquoi seuls certains sites Web? Cela aiderait beaucoup. Pendant que je suis toujours curieux, je suis de plus en plus enclin à Nuke de l'orbite et du départ.
Idées/suggestions?
-Merci
Votre Capture de paquet avait quelque chose d'inhabituel: les bits ECN ont été définis dans le paquet Syn Syn.
Notification de congestion explicite Une extension du protocole IP permettant aux hôtes de réagir plus rapidement à la congestion du réseau. Il a été introduit pour la première fois sur Internet il y a 15 ans, mais il y a eu des problèmes graves noté quand il a été déployé pour la première fois. Le plus sérieux d'entre eux était que de nombreux pare-feu soit des paquets de goutte ou renvoyez une TVD Lors de la réception d'un paquet SYN avec le jeu de bits ECN.
En conséquence, la plupart des systèmes d'exploitation désactivés par l'ECN par défaut, au moins pour les connexions sortantes. En conséquence, je soupçonne que beaucoup de sites (et de fournisseurs de pare-feu!) Jamais jamais Correction de leurs pare-feu .
Jusqu'à ce que Windows Server 2012 soit libéré. Microsoft activé ECN par défaut Démarrage de cette version du système d'exploitation.
Malheureusement, personne n'a eu la mémoire récente effectuée de manière significative des réponses des sites Internet à l'ECN, il est donc difficile de déterminer si les problèmes considérés au début des années 2000 sont encore existants, mais je soupçonne fortement qu'elles soient et que votre trafic est au moins une partie du temps, passant par un tel équipement.
Après avoir activé ECN sur mon bureau, puis sur WireShark, il ne s'agissait que de quelques secondes avant d'avoir pris un exemple d'un hôte à partir de laquelle j'ai eu une première à un paquet avec Syn et ECN set, bien que la plupart des hôtes semblent bien fonctionner. Peut-être que je vais aller scanner Internet moi-même ...
Vous pouvez essayer de désactiver ECN sur votre serveur pour voir si le problème s'efforce. Cela vous rendra également incapable d'utiliser DCTCP, mais dans un petit bureau, il est très peu probable que vous le faisiez ou si vous avez besoin de le faire.
netsh int tcp set global ecncapability=disabled