Grande atraso ao buscar uma página de um determinado site

Question

Estou com o seguinte problema: quando recupero uma página doHackeamento, recebo um grande atraso (cerca de 30 segundos). Outras solicitações são rápidas, mas se eu não me conectar a ele durante alguns minutos, o problema volta.

O que é interessante sobre esse problema é:

• é específico para este site específico (Hackage) - não tenho problema semelhante com nenhum outro site (e visito alguns);
• parece ser específico do meu ISP - quando me conecto de outros lugares, não existe esse problema;

• não está relacionado a problemas de DNS ou de conectividade — na verdade, a conexão TCP é estabelecida rapidamente; é a resposta HTTP que demora muito, como pode ser visto no seguinte exemplo de captura de pacote:

    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 pacotes no formato pcap-ng). Esta captura mostra o que acontece durante um arquivo curl http://hackage.haskell.org/packages/hackage.html.

Também não importa se estou atrás de um roteador – é a mesma coisa quando me conecto diretamente. O tipo de conexão é PPPoE.

Reproduzi o problema em 3 computadores que rodam Linux e Windows.

Como diagnosticar tal problema?

Answer 1

"30 segundos" e "depois de dois minutos" são um sinal morto para um problema de DNS para mim.

Se supormos que a página à qual você está se conectando faz algo como uma consulta DNS no IP de conexão e essa consulta falha por algum motivo, você verá:

• Conexão TCP quase instantânea desdeo servidornão está fazendo verificações de DNS
• o script executa uma consulta DNSe fica preso.
• após 30 segundos, o tempo limite padrão expira e o script continua (agora você é "Desconhecido")
• nas consultas subsequentes, o acerto negativo do DNS ainda é armazenado em cache e o estágio 1 é aprovado em pouco tempo
• após o tempo limite negativo expirar (RFC 2308), e isso é algo entre 2 e 5 minutos, uma nova consulta é emitida na próxima conexão e a história se repete.

...e estes são exatamente os sintomas que você está descrevendo.

Você pode tentar executar uma consulta DNS de outro ISP (digamos, ISP2) no IP obtido do ISP1. Não é uma prova 100%, mas espero uma grande probabilidade de que a consulta demore 30 segundos para ser concluída. Isso significaria que o servidor DNS ISP1 está tendo problemas para responder às consultasde fora.

Outra causa possível poderia ser o DNS do ISP1 sendo protegido por firewall pelo Hackage por algum motivo (provavelmente equivocado) (emmeuoutfit, o motivo seria "um netadmin no gatilho", e eu poderia citar nomes). Nesse caso, você teria muito mais dificuldade em diagnosticar, pois qualquer teste através do ISP2 não retornaria nada incomum; você teria que escalar isso para o Hackage.

Answer 2

O problema parece um problema com "MTU". Se você pesquisar no Google "windows setting mtu", deverá encontrar uma série de respostas que mostrarão como testar essa teoria e diminuir seu MTU conforme apropriado. (Se você estivesse usando um roteador Linux, eu poderia produzir um comando IPTables para fazer isso dinamicamente para você, mas eu não "faço" o Windows.)

Answer 3

Repeti sua captura de pacotes, que fica assim do meu lado:

Efetivamente, há uma pequena pausa indetectável enquanto o pacote é remontado, mas em nenhum lugar tão longo quanto o seu. Também verifiquei todos os endereços IP e HTML, e tudo está correto e parece extremamente simples e inofensivo.

Em suma, não há razão para este atraso, no que diz respeito à Internet. A conclusão é que há um problema com o seu ISP.

O que você pode fazer para restringir as possibilidades é:

1. Tente se conectar aoutro pacote haskell.orge veja se há um atraso semelhante
2. Tente usar outro roteador do seu local com vários computadores usando adaptadores de rede diferentes
3. Tente ter alguém na sua área que use omesmoISP repete a conexão
4. Tente ter alguém na sua área que useoutroISP repete a conexão
5. Com essas informações, caso ainda não tenha explicação para esse atraso, entre em contato com o Suporte do seu ISP para perguntar o que está acontecendo.

[EDITAR]

Percebi que haskell.org envia umETag, isso explica por que o primeiro acesso é lento, mas os próximos são rápidos: porque enquanto a ETag for válida, a página na verdade vem do cache do seu navegador.

A parte estranha aqui é por que o ISP não fica lento ao transmitir uma solicitação ETag. Uma explicação pode ser que, por um tempo limitado, eles satisfazem a solicitação de seu próprio cache, em vez de acessar haskell.org.

Answer 4

Parece um problema de servidor. Carregou rápido para mim. Para testar se o servidor não gosta de você, tente acessá-lo a partir de um proxy, como TOR ou HideMyAss.com. Se for rápido, há um problema entre haskell.org e sua casa.

Outro teste que você pode executar é encontrar um recurso nesse local, como arquivo HTML, arquivo CSS ou arquivo XML, e passar esse link para um validador HTML, etc. é um problema com o servidor.

Outro teste: limpe o cache DNS. Pode ser que procurar o endereço IP de haskell.org leve muito tempo. ipconfig /flushdns. Tente também ping hackage.haskell.orgna linha de comando para ver quanto tempo leva para procurar o endereço IP.

Outro teste: abra uma sessão de navegação privada com o Chrome (e outros) para evitar o envio de cookies.

Outro teste: abra F12 no Chrome ou Opera, vá na aba Rede e depois vá no site para ver o tempo de cada recurso.