Grande atraso ao buscar uma página de um site específico

11

Tenho o seguinte problema: ao recuperar uma página do Hackage , recebo um grande atraso (cerca de 30 segundos). Solicitações adicionais são rápidas, mas se eu não conectar a ela por 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 nenhum outro site (e visito alguns);
parece ser específico para meu ISP - quando eu me conecto de outros lugares, não há esse problema;

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

  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.

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

Como diagnosticar esse problema?

http

— Roman Cheplyaka
fonte

Olá, acho que você precisa usar um navegador com ferramentas de desenvolvedor ativadas para ver a caixa de diálogo de nível HTTP em vez da caixa de diálogo de nível IP. Precisamos ver o que está causando o atraso e você só pode fazer isso observando o conjunto total de interações HTTP da página. Em vez disso, você pode usar o GMetrix .

— Julian Knight

A execução do GMetrix no site me deu bons resultados com algumas expetativas significativas que podem apontar na direção certa.

— Julian Knight

@JulianKnight: há um link para o arquivo de captura completa na questão - que tem todas as informações

— Roman Cheplyaka

Seu link é um PCAP, estou me referindo a algo em um nível muito mais alto. Por favor, reporte usando uma análise de desenvolvedor baseada em navegador ou GMetrix ou ambos.

— Julian Knight

1

@ JulianKnight: deixe-me repetir - CSS é irrelevante aqui, e estamos falando de um atraso de 30 segundos para uma única solicitação HTTP.

— Roman Cheplyaka

5

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

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

Conexão TCP quase instantânea, pois o servidor não está fazendo verificações de DNS
o script executa uma consulta DNS e fica preso .
após 30 segundos, o tempo limite padrão expira e o script continua (você agora é "Desconhecido")
nas consultas subseqüentes, o resultado negativo do DNS ainda é armazenado em cache e o estágio 1 é passado rapidamente.
após o tempo limite negativo expirar (RFC 2308), ou seja, entre 2 e 5 minutos, uma nova consulta é emitida na próxima conexão e a história se repete.

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

Você pode tentar executar uma consulta DNS de outro ISP (por exemplo, ISP2) no IP obtido do ISP1. Não é 100% prova, mas espero uma alta probabilidade de que a consulta leve 30 segundos para ser concluída. Isso significaria que o servidor DNS do ISP1 está tendo problemas para responder a consultas externas .

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

— LSerni
fonte

Isso parece muito plausível! Deixe-me verificá-lo.

— Roman Cheplyaka 28/02

Pela primeira causa, tentei usar haskell usando um proxy anônimo e foi rápido, o que pode indicar que essa causa é improvável. Para o segundo, a mesma pausa é esperada ao acessar o haskell a partir de qualquer ISP, portanto, também é improvável. O DNS ainda pode ser a causa, mas pode ser mais complicado de explicar.

— harrymc

@harrymc: é muito simples, na verdade. Os servidores DNS do meu ISP responsáveis pelo DNS reverso estão inoperantes. Portanto, tenta executar o tempo limite de resolução inversa. Tente isto: dig +trace -x 80.90.233.38. Tenho 95% de certeza de que essa é a causa, apenas aguardando a confirmação de que o hackage realmente executa pesquisas reversas no DNS.

— Roman Cheplyaka

0

Problema parece um problema com "MTU". Se você pesquisar no "windows setting mtu" do google, você deverá apresentar várias respostas que mostrarão como testar essa teoria e diminuir o 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.)

— davidgo
fonte

De acordo com o guia do Wireshark, o "segmento TCP de uma PDU remontada" na verdade não corresponde à fragmentação do IP, mas apenas indica que a resposta contém validamente vários pacotes, como seria de esperar de uma página da web.

— Julian Knight

Não parece ser MTU. Eu testei isso conectando diretamente via Ethernet e configurando o mtu para 1000. O problema persistiu.

— Roman Cheplyaka

0

Repeti sua captura de pacotes, que tem a seguinte aparência:

capturar imagem

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

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

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

Tente conectar-se a outro pacote haskell.org e veja se há um atraso semelhante
Tente usar outro roteador do seu local com vários computadores usando adaptadores de rede diferentes
Tente ter alguém na sua área que use o mesmo ISP e repita a conexão
Tente ter alguém na sua área que use outro ISP e repita a conexão
Com essas informações, se você ainda não tem explicação para esse atraso, entre em contato com o Suporte do seu ISP para perguntar o que está acontecendo.

[EDITAR]

Notei que o haskell.org envia um ETag , o que 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 é por que o ISP não é lento ao transmitir uma solicitação ETag. Uma explicação pode ser que, por um tempo limitado, eles atendam à solicitação de seu próprio cache, em vez de acessar o haskell.org.

— harrymc
fonte

1. É o mesmo para todas as páginas de hackers. 2. Como eu disse, tentei isso em vários computadores e com vários roteadores (e sem um). 4. O problema não existe se eu usar outro ISP na minha área.

— Roman Cheplyaka 28/02

Agora, o problema do ISP realmente parece a única solução plausível, mas que tipo de problema pode ser? Eles provavelmente nem suspeitam da existência de hackers, por isso não pode ser intencional. Se eu disser a eles, "ei, esse site não funciona para mim (mas todos os outros funcionam)", eles não ouvirão.

— Roman Cheplyaka 28/02

Eu adicionei acima uma explicação por que apenas o primeiro acesso é lento. O ponto 3 ainda precisa de uma resposta antes de falar com o ISP. O problema deles pode estar relacionado ao software de segurança que eles empregam, sendo, por algum motivo, muito lento para verificar a validade do haskell.org.

— harrymc

Etag é irrelevante, já que eu uso o curl para testar. De qualquer forma, a resposta sobre DNS reverso provavelmente é a correta.

— Roman Cheplyaka

-2

Parece um problema no 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, existe um problema entre o haskell.org e sua casa.

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

Outro teste: limpe o cache do DNS. Pode estar demorando muito para procurar o endereço IP do haskell.org. 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 a F12 no Chrome ou Opera, vá para a guia Rede e, em seguida, vá para o site para ver a hora de cada recurso.

— Chloe
fonte

Ao usar um proxy, o problema desaparece. Suas outras sugestões já foram abordadas na própria pergunta.

— Roman Cheplyaka

O servidor não gosta de você. Ele está limitando seu IP por qualquer motivo. Não há nada que você possa fazer.

— Chloe