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

Tengo el siguiente problema: cuando recupero una página de Hackage , recibo 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 para 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 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; es 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?

"30 segundos" y "después de dos minutos" son un tono muerto para 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 ya que el servidor no está haciendo verificaciones DNS
• el script ejecuta una consulta DNS y se atasca .
• después de 30 segundos, el tiempo de espera predeterminado expira y el script continúa (ahora está "Desconocido")
• en consultas posteriores, el hit DNS negativo todavía se almacena en caché y la etapa 1 se pasa en muy poco tiempo
• después de que expire el tiempo de espera negativo (RFC 2308), y eso es cualquier cosa entre 2 y 5 minutos, se emite una nueva consulta en la próxima conexión, y la historia se repite.

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

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

Otra posible causa podría ser que el DNS de ISP1 esté siendo bloqueado por Hackage por alguna razón (probablemente equivocada) (en mi conjunto, la razón sería "un netadmin de activación feliz", y podría nombrar nombres). En ese caso, le resultaría mucho más difícil diagnosticar, ya que cualquier prueba a través de ISP2 no devolvería nada inusual; tendrías que escalar esto a Hackage.

El problema suena como un problema con "MTU". Si buscas en google "windows setting mtu", deberías encontrar una serie de respuestas que te mostrarán cómo probar esta teoría y reducir tu MTU según corresponda. (Si estuviera utilizando un enrutador Linux, podría producir un comando de IPTables para hacer esto dinámicamente por usted, pero no "hago" Windows).

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

Efectivamente, hay una pequeña pausa indetectable mientras se vuelve a ensamblar el paquete, pero en ninguna parte mientras sea suyo. También he verificado todas las direcciones IP y el HTML, y todo es correcto y parece extremadamente simple e inofensivo.

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

Lo que puede hacer para reducir las posibilidades es:

1. Intente conectarse a otro paquete haskell.org y vea si hay un retraso similar
2. Intente usar otro enrutador de su lugar con varias computadoras que usan diferentes adaptadores de red
3. Intente que alguien en su área que use el mismo ISP repita la conexión
4. Intente que alguien en su área que use otro ISP repita la conexión
5. Con esta información, si aún no tiene una explicación para este retraso, comuníquese con el Soporte de su ISP para preguntar qué está pasando.

[EDITAR]

Noté que haskell.org envía un ETag , por lo que eso explica por qué el primer acceso es lento pero los siguientes son rápidos: porque mientras el ETag sea válido, la página en realidad proviene del caché de su navegador.

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

Suena como un problema del servidor. Se cargó rápido para mí. Para probar si el servidor no le gusta, intente acceder a él desde un proxy, como TOR u 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. Es un problema con el servidor.

Otra prueba: borra tu caché de DNS. Podría estar buscando la dirección IP de haskell.org lleva mucho tiempo. ipconfig /flushdns. También intente ping hackage.haskell.orgdesde la línea de comandos para ver cuánto tiempo lleva buscar la dirección IP.

Otra prueba: abra 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.