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

Question

Eu tenho o seguinte problema: quando eu recupero uma página do Hackage , recebo um grande atraso (cerca de 30 segundos). Outras solicitações são rápidas, mas se eu não me conectar a ela durante alguns minutos, o problema voltará.

O que é interessante sobre esse problema é:

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

• não está relacionado a problemas de DNS ou conectividade - na verdade, a conexão TCP é estabelecida rapidamente; é a resposta HTTP que leva muito tempo, como pode ser visto na captura de pacote de amostra a seguir:

    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 simples curl http://hackage.haskell.org/packages/hackage.html .

Também não importa que eu esteja atrás de um roteador - é o mesmo quando me conecto diretamente. O tipo de conexão é PPPoE.

Eu reproduzi o problema em 3 computadores que executam o Linux e o Windows.

Como diagnosticar tal problema?

    

Answer 1

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

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

• Conexão TCP quase instantânea, já que o servidor não está fazendo verificações de DNS
• o script executa uma consulta de DNS e fica preso .
• após 30 segundos, o tempo limite padrão expira e o script continua (você está agora "Desconhecido")
• nas consultas subsequentes, o hit de DNS negativo ainda é armazenado em cache e o estágio 1 é passado sem tempo
• depois que o tempo limite negativo expira (RFC 2308), e isso é algo entre 2 e 5 minutos, uma nova consulta é emitida na próxima conexão e a história é repetida.

... 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 é 100% prova, mas espero uma alta probabilidade de a consulta levar 30 segundos para ser concluída. Isso significaria que o servidor DNS do ISP1 está tendo problemas para responder às consultas do lado de fora .

Outra possível causa poderia ser o DNS do ISP1 ser bloqueado pelo Hackage por algum motivo (provavelmente errado) (em meu outfit, o motivo seria "um netadmin feliz", e eu poderia nomear 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ê procurar no google "windows setting mtu" você deve encontrar um número de respostas que lhe mostrarão como testar essa teoria e diminuir o 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 a captura dos seus pacotes, que parecem assim do meu lado:

Efetivamenteháumapequenapausaindetectávelenquantoopacoteéremontado,masemnenhumlugar,desdequeoseu.EutambémverifiqueitodososendereçosIPeoHTML,etudoestácorretoepareceextremamentesimpleseinofensivo.

Emsuma,nãohárazãoparaesteatraso,noquedizrespeitoàInternet.AconclusãoéqueexisteumproblemacomoseuISP.

Oquevocêpodefazerparadiminuiraspossibilidadesé:

1. Tenteconectar-seao outro pacote haskell.org e veja se há um atraso semelhante
2. Tente usar outro roteador do seu lugar com vários computadores usando diferentes adaptadores de rede
3. Tente ter alguém na sua área que use o mesmo ISP para repetir a conexão
4. Tente ter alguém na sua área que use outro ISP para repetir a conexão
5. Com essas informações, se ainda não houver explicação para esse atraso, entre em contato com o suporte do seu ISP para perguntar o que está acontecendo.

[EDITAR]

Notei que haskell.org envia uma ETag , isso explica por que o primeiro acesso é lento, mas os próximos são rápidos: Porque enquanto o ETag é válido, a página realmente vem do cache do seu navegador.

A parte estranha aqui é porque o ISP não está lento ao transmitir uma solicitação ETag. Uma explicação pode ser que, por um tempo limitado, satisfazem a solicitação de seus próprio cache, em vez de ir para haskell.org.

    

Answer 4

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

Outro teste que você pode executar é encontrar um recurso nessa visão, como arquivo HTML, arquivo CSS ou arquivo XML, e passar esse link para um validador de HTML, etc. Se os serviços de terceiros levarem muito tempo para buscar , então é um problema com o servidor.

Outro teste: limpe seu cache de DNS. Poderia estar procurando endereço IP haskell.org leva muito tempo. %código%. Tente também ipconfig /flushdns na 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 a F12 no Chrome ou no Opera, acesse a guia Rede e acesse o site para ver a hora de cada recurso.