☰

Gran retraso al recuperar una página de un sitio en particular

tag-icon • tag-icon http
Gran retraso al recuperar una página de un sitio en particular

Tengo el siguiente problema: cuando recupero una página deHackear, obtengo un gran retraso (unos 30 segundos). Las solicitudes adicionales son rápidas, pero si no me conecto durante un par de minutos, el problema vuelve.

Lo interesante de este problema es:

  • es específico de este sitio en particular (Hackage). No tengo un problema similar con ningún otro sitio (y visito bastantes);
  • parece ser específico de mi ISP: cuando me conecto desde otros lugares, no hay tal problema;

  • no está relacionado con DNS o problemas de conectividad; de hecho, la conexión TCP se establece rápidamente; es la respuesta HTTP la que tarda demasiado, como se puede ver en la siguiente captura de paquetes de muestra:

      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

    (captura de paquetes en formato pcap-ng). Esta captura muestra lo que sucede durante un simple curl http://hackage.haskell.org/packages/hackage.html.

Tampoco importa que esté detrás de un enrutador; ocurre lo mismo cuando me conecto directamente. El tipo de conexión es PPPoE.

Reproduje el problema en 3 computadoras que ejecutan Linux y Windows.

¿Cómo diagnosticar tal problema?

Respuesta1

"30 segundos" y "después de dos minutos" son la viva imagen de un problema de DNS para mí.

Si suponemos que la página a la que se está conectando hace algo así como una consulta DNS en la IP de conexión, y esa consulta falla por algún motivo, verá:

  • Conexión TCP casi instantánea desdeel servidorno está haciendo comprobaciones de DNS
  • el script ejecuta una consulta DNSy se queda atascado.
  • después de 30 segundos, el tiempo de espera predeterminado expira y el script continúa (ahora eres "Desconocido")
  • en consultas posteriores, el resultado DNS negativo todavía se almacena en caché y la etapa 1 se pasa en muy poco tiempo
  • después de que expira el tiempo de espera negativo (RFC 2308), y eso es entre 2 y 5 minutos, se emite una nueva consulta en la siguiente conexión y la historia se repite.

...y estos son exactamente los síntomas que estás describiendo.

Podría intentar ejecutar una consulta DNS desde otro ISP (por ejemplo, ISP2) en la IP que obtiene del ISP1. No es una prueba del 100%, pero espero que haya una alta probabilidad de que la consulta demore 30 segundos en completarse. Eso significaría que el servidor DNS del ISP1 está teniendo problemas para responder consultas.desde fuera.

Otra posible causa podría ser que Hackage bloquee el firewall del DNS del ISP1 por alguna razón (probablemente errónea) (enmitraje, la razón sería "un administrador de red fácil de disparar", y podría nombrar nombres). En ese caso, le resultaría mucho más difícil diagnosticar, ya que cualquier prueba realizada a través del ISP2 no arrojaría nada inusual; Tendrías que escalar esto a Hackage.

Respuesta2

El problema parece un problema con "MTU". Si busca en Google "configuración de Windows mtu", debería obtener una serie de respuestas que le mostrarán cómo probar esta teoría y reducir su MTU según corresponda. (Si estuviera usando un enrutador Linux, podría generar un comando IPTables para hacer esto dinámicamente por usted, pero no "hago" Windows).

Respuesta3

He repetido la captura de sus paquetes, que por mi parte se ven así:

Capturar imagen

Efectivamente, hay una pequeña pausa indetectable mientras se vuelve a ensamblar el paquete, pero no tan larga como la suya. También verifiqué todas las direcciones IP y el HTML, y todo es correcto y parece extremadamente simple e inofensivo.

En resumen, no hay ninguna razón para este retraso en lo que a Internet se refiere. La conclusión es que hay un problema con tu ISP.

Lo que puedes hacer para reducir las posibilidades es:

  1. Intente conectarse aotro paquete de haskell.orgy ver si hay un retraso similar
  2. Intente usar otro enrutador de su casa con varias computadoras usando diferentes adaptadores de red
  3. Intente tener a alguien en su área que use elmismoISP repite la conexión
  4. Intente tener a alguien en su área que useotroISP repite la conexión
  5. Con esta información, si aún no tienes explicación para este retraso, contacta con el Soporte de tu ISP para preguntar qué está pasando.

[EDITAR]

Me di cuenta de que haskell.org envía unetiqueta ET, eso explica por qué el primer acceso es lento pero los siguientes son rápidos: porque mientras la ETag sea válida, la página en realidad proviene de la memoria caché de su navegador.

Lo extraño aquí es por qué el ISP no es lento al transmitir una solicitud ETag. Una explicación podría ser que durante un tiempo limitado satisfacen la solicitud desde su propio caché, en lugar de ir a haskell.org.

Respuesta4

Suena como un problema del servidor. A mí me cargó rápido. Para comprobar si no le agradas al servidor, intenta acceder a él desde un proxy, como TOR o HideMyAss.com. Si es rápido, entonces hay un problema entre haskell.org y tu casa.

Otra prueba que puede ejecutar es encontrar un recurso en esa vista, como un archivo HTML, un archivo CSS o un archivo XML, y pasar ese enlace a un validador HTML, etc. Si los servicios de terceros tardan mucho en recuperarse, entonces es un problema con el servidor.

Otra prueba: borre su caché de DNS. Podría ser que buscar la dirección IP de haskell.org lleve mucho tiempo. ipconfig /flushdns. Pruebe también ping hackage.haskell.orgdesde la línea de comando para ver cuánto tiempo lleva buscar la dirección IP.

Otra prueba: abre una sesión de navegación privada con Chrome (y otros) para evitar el envío de cookies.

Otra prueba: abra F12 en Chrome u Opera, vaya a la pestaña Red y luego vaya al sitio para ver la hora de cada recurso.

información relacionada