Retard important lors de la récupération d'une page à partir d'un site particulier

11

J'ai le problème suivant: lorsque je récupère une page de Hackage , j'obtiens un délai important (environ 30 secondes). Les autres demandes sont rapides, mais si je ne me connecte pas pendant quelques minutes, le problème revient.

Ce qui est intéressant à propos de ce problème, c'est:

  • il est spécifique à ce site particulier (Hackage) - je n'ai pas de problème similaire avec un autre site (et j'en visite pas mal);
  • cela semble être spécifique à mon FAI - lorsque je me connecte depuis d'autres endroits, il n'y a pas un tel problème;

  • ce n'est pas lié à des problèmes de DNS ou de connectivité - en fait, la connexion TCP est établie rapidement; c'est la réponse HTTP qui prend trop de temps, comme le montre l'exemple de capture de paquets suivant:

      1 0.000000000 192.168.1.101 -> 66.193.37.204 TCP 66 41518 > http [SYN] Seq=0 Win=13600 Len=0 MSS=1360 SACK_PERM=1 WS=16
  2 0.205708000 66.193.37.204 -> 192.168.1.101 TCP 66 http > 41518 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1440 SACK_PERM=1 WS=128
  3 0.205759000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=1 Ack=1 Win=13600 Len=0
  4 0.205846000 192.168.1.101 -> 66.193.37.204 HTTP 158 GET /packages/hackage.html HTTP/1.1 
  5 0.406461000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [ACK] Seq=1 Ack=105 Win=5888 Len=0
  6 28.433860000 66.193.37.204 -> 192.168.1.101 TCP 1494 [TCP segment of a reassembled PDU]
  7 28.433904000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=1441 Win=16480 Len=0
  8 28.434211000 66.193.37.204 -> 192.168.1.101 HTTP 1404 HTTP/1.1 200 OK  (text/html)
  9 28.434228000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=2791 Win=19360 Len=0
 10 28.434437000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [FIN, ACK] Seq=105 Ack=2791 Win=19360 Len=0
 11 28.635146000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [FIN, ACK] Seq=2791 Ack=106 Win=5888 Len=0
 12 28.635191000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=106 Ack=2792 Win=19360 Len=0

    ( capture de paquets au format pcap-ng ). Cette capture montre ce qui se passe pendant un simple curl http://hackage.haskell.org/packages/hackage.html.

Peu importe que je sois derrière un routeur - c'est la même chose lorsque je me connecte directement. Le type de connexion est PPPoE.

J'ai reproduit le problème sur 3 ordinateurs fonctionnant sous Linux et Windows.

Comment diagnostiquer un tel problème?

http 
— Roman Cheplyaka
source
Salut, je pense que vous devez utiliser un navigateur avec des outils de développement activés pour voir la boîte de dialogue de niveau HTTP plutôt que la boîte de dialogue de niveau IP. Nous devons voir ce qui cause le retard et vous ne pouvez le faire qu'en regardant l'ensemble total des interactions HTTP pour la page. Au lieu de cela, vous pouvez utiliser GMetrix .
— Julian Knight
L'exécution de GMetrix sur le site m'a donné de très bons résultats avec quelques attentes importantes qui pourraient vous orienter dans la bonne direction.
— Julian Knight
@JulianKnight: il y a un lien vers le fichier de capture complet dans la question - il contient toutes les informations
— Roman Cheplyaka
Votre lien est un PCAP, je fais référence à quelque chose à un niveau beaucoup plus élevé. Veuillez nous faire rapport en utilisant soit une analyse de développeur basée sur un navigateur, soit GMetrix, soit les deux.
— Julian Knight
1
@JulianKnight: permettez-moi de répéter - CSS n'est pas pertinent ici, et nous parlons d'un délai de 30 secondes pour une seule requête HTTP.
— Roman Cheplyaka

Réponses:

5

"30 secondes" et "au bout de deux minutes" sont pour moi une sonnerie morte pour un problème DNS.

Si nous supposons que la page à laquelle vous vous connectez fait quelque chose comme une requête DNS sur l'IP de connexion et que cette requête échoue pour une raison quelconque, vous verrez:

  • Connexion TCP presque instantanée car le serveur ne fait pas de vérifications DNS
  • le script exécute une requête DNS et se bloque .
  • après 30 secondes, le délai par défaut expire et le script continue (vous êtes maintenant "Inconnu")
  • sur les requêtes suivantes, le hit DNS négatif est toujours mis en cache et l'étape 1 est passée en un rien de temps
  • après expiration du délai négatif (RFC 2308), c'est-à-dire entre 2 et 5 minutes, une nouvelle requête est émise à la connexion suivante et l'histoire se répète.

... et ce sont exactement les symptômes que vous décrivez.

Vous pouvez essayer d'exécuter une requête DNS à partir d'un autre FAI (disons, ISP2) sur l'IP que vous obtenez à partir d'ISP1. Ce n'est pas une preuve à 100%, mais je m'attends à une forte probabilité que la requête prenne 30 secondes. Cela signifierait que le serveur DNS ISP1 a des problèmes pour répondre aux requêtes de l'extérieur .

Une autre cause possible pourrait être que le DNS d'ISP1 soit protégé par un pare-feu par Hackage pour une raison (probablement erronée) (dans ma tenue, la raison serait "un netadmin déclencheur" et je pourrais nommer des noms). Dans ce cas, vous auriez beaucoup plus de mal à diagnostiquer, car tout test via ISP2 ne retournerait rien d'inhabituel; vous devez faire remonter cela à Hackage.

— LSerni
source
Cela semble très plausible! Laissez-moi le vérifier.
— Roman Cheplyaka
Pour la première cause, j'ai essayé d'aller à haskell en utilisant un proxy anonyme et c'était rapide, ce qui pourrait éventuellement indiquer que cette cause est peu probable. Pour le second, la même pause est alors à prévoir lors de l'accès à haskell depuis n'importe quel FAI, il est donc également peu probable. Le DNS pourrait toujours être la cause, mais il pourrait être plus compliqué à expliquer.
— harrymc
@harrymc: c'est très simple, en fait. Les serveurs DNS de mon FAI qui sont responsables du DNS inversé sont en panne. Donc, les tentatives de faire un délai de résolution inverse. Essayez ceci: dig +trace -x 80.90.233.38. Je suis sûr à 95% que c'est la cause, attendant simplement la confirmation que le piratage effectue effectivement des recherches DNS inversées.
— Roman Cheplyaka
0

Le problème ressemble à un problème avec "MTU". Si vous utilisez Google "windows setting mtu", vous devriez trouver un certain nombre de réponses qui vous montreront comment tester cette théorie et baisser votre MTU, le cas échéant. (Si vous utilisiez un routeur Linux, je pourrais produire une commande IPTables pour le faire dynamiquement pour vous, mais je ne "fais" pas Windows.)

— davidgo
source
Selon le guide Wireshark, le «segment TCP d'une PDU réassemblée» ne correspond en fait pas à la fragmentation IP mais indique simplement que la réponse contient valablement plusieurs paquets comme vous pouvez vous y attendre d'une page Web.
— Julian Knight
Il ne semble pas que ce soit MTU. J'ai testé cela en me connectant directement via Ethernet et en définissant mtu à 1000. Le problème persistait.
— Roman Cheplyaka
0

J'ai répété la capture de vos paquets, qui se présente de cette façon de mon côté:

capturer l'image

Effectivement, il y a une pause mineure indétectable pendant que le paquet est réassemblé, mais nulle part aussi longtemps que le vôtre. J'ai également vérifié toutes les adresses IP et le HTML, et tout est correct et semble extrêmement simple et sans danger.

Bref, il n'y a aucune raison à ce retard en ce qui concerne Internet. La conclusion est qu'il y a un problème avec votre FAI.

Ce que vous pouvez faire pour réduire les possibilités est le suivant:

  1. Essayez de vous connecter à un autre package haskell.org et voyez s'il y a un délai similaire
  2. Essayez d'utiliser un autre routeur depuis chez vous avec plusieurs ordinateurs utilisant différentes cartes réseau
  3. Essayez d'avoir quelqu'un dans votre région qui utilise le même FAI répéter la connexion
  4. Essayez d'avoir quelqu'un dans votre région qui utilise un autre FAI pour répéter la connexion
  5. Avec ces informations, si vous n'avez toujours aucune explication à ce retard, contactez le support de votre FAI pour savoir ce qui se passe.

[ÉDITER]

J'ai remarqué que haskell.org envoie un ETag , ce qui explique pourquoi le premier accès est lent mais les suivants sont rapides: Parce que tant que l'ETag est valide, la page provient en fait du cache de votre navigateur.

La partie étrange ici est la raison pour laquelle le FAI n'est pas lent lors de la transmission d'une demande ETag. Une explication pourrait être que pendant un temps limité, ils satisfont la demande de leur propre cache, plutôt que d'aller sur haskell.org.

— harrymc
source
1. C'est la même chose pour toutes les pages de piratage. 2. Comme je l'ai dit, j'ai essayé cela sur plusieurs ordinateurs et avec plusieurs routeurs (et sans un). 4. Le problème n'existe pas si j'utilise un autre FAI dans ma région.
— Roman Cheplyaka
Maintenant, le problème du FAI ressemble en effet à la seule solution plausible, mais quel genre de problème peut-il être? Ils ne soupçonnent probablement même pas l'existence d'un piratage, il ne peut donc pas être intentionnel. Si je leur dis: "hé, ce site ne fonctionne pas pour moi (mais tous les autres le font)", ils n'écouteront pas.
— Roman Cheplyaka
J'ai ajouté ci-dessus une explication pourquoi seul le premier accès est lent. Le point 3 a encore besoin d'une réponse avant de parler au FAI. Leur problème pourrait être lié au logiciel de sécurité qu'ils utilisent, étant pour une raison quelconque très lent à vérifier la validité de haskell.org.
— harrymc
Etag n'est pas pertinent, car j'utilise curl pour les tests. Quoi qu'il en soit, la réponse à propos du DNS inversé est probablement la bonne.
— Roman Cheplyaka
-2

Cela ressemble à un problème de serveur. Il s'est chargé rapidement pour moi. Pour tester si le serveur ne vous aime pas, essayez d'y accéder à partir d'un proxy, tel que TOR ou HideMyAss.com. Si c'est rapide, alors il y a un problème entre haskell.org et votre maison.

Un autre test que vous pouvez exécuter consiste à trouver une ressource sur cette vue, comme un fichier HTML, un fichier CSS ou un fichier XML, et à transmettre ce lien à un validateur HTML, etc. Si les services tiers prennent beaucoup de temps à récupérer, alors il est un problème avec le serveur.

Autre test: vider votre cache DNS. Il se peut que la recherche de l'adresse IP de haskell.org prenne beaucoup de temps. ipconfig /flushdns. Essayez également à ping hackage.haskell.orgpartir de la ligne de commande pour voir combien de temps il faut pour rechercher l'adresse IP.

Autre test: ouvrir une session de navigation privée avec Chrome (et autres) pour éviter d'envoyer des cookies.

Autre test: ouvrez F12 dans Chrome ou Opera, accédez à l'onglet Réseau, puis accédez au site pour voir l'heure de chaque ressource.

— Chloe
source
Lorsque vous utilisez un proxy, le problème disparaît. Vos autres suggestions sont déjà traitées dans la question elle-même.
— Roman Cheplyaka
Le serveur ne vous aime pas. Il limite votre adresse IP pour une raison quelconque. Vous ne pouvez rien faire.
— Chloé
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.