Como é que este tempo de ping reportado de uma hora pode ser real?

15
Recentemente, passei o feriado do banco da Páscoa com meus pais, que moram em uma área muito rural no Reino Unido. Eles têm uma conexão de internet ADSL (terrível), que é percorrida por vários quilômetros de cobre desonesto e é periodicamente interrompida quando agricultores próximos revertem seus tratores para as linhas telefônicas.

Percebi que o roteador estava repetidamente descartando o handshake pptp e renegociando-o, eliminando a conexão com eficiência. Isso foi frustrante. Então, em uma tentativa de evitar enlouquecer, eu disse a ele para dobrar a margem SNR mínima aceitável e o aperto de mão para velocidades mais baixas:

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
U.S. Robotics Wireless MAXg ADSL Gateway
Login: ***********
Password: 
> sh


BusyBox v1.00 (2006.02.17-20:30+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

# adsl configure --snr 200; exit 
Connection closed by foreign host.

Isso melhorou as coisas, e a coisa ficou com um tubo (um pouco) estável, embora incrivelmente lento, para o mundo externo:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=3236.679 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=3699.541 ms
...

A essa altura, a vida real interveio e passei várias horas brincando com gatos, olhando para gifs de gatos no meu telefone, falando com minha família , etc. Esqueci que tinha deixou este processo de ping em execução e voltou cerca de um dia depois para acessar ctrl-c .

As estatísticas de resumo mostradas me piscaram:

--- 8.8.8.8 ping statistics ---
103074 packets transmitted, 100564 packets received, 2.4% packet loss
round-trip min/avg/max/stddev = 32.986/3034.479/3600577.732/87527.276 ms

Como você pode ver, o tempo máximo de resposta registrado para um pacote ICMP fazendo um pequeno salto transatlântico para o servidor DNS do Google é de 3600577.732 ms . Isso é quase exatamente uma hora , e certamente muito mais longo que o tempo limite padrão de ping .

Como na Terra pode ser isso? É preciso? Qual roteador ficará satisfeito em manter um pacote por sessenta minutos antes de enviá-lo a caminho? Por que esse pacote não foi descartado? É o resultado de um estouro do contador de pacotes de 8 bits combinado com grandes latências?

Por fim, gostaria de saber se existe algum código de conduta no Reino Unido declarando que as conexões ADSL dos consumidores devem ter menos latência e melhor gerenciamento de tráfego que as ferramentas RFC 1149 e RFC 2549 ;-).

    
por Landak 30.03.2016 / 10:38

2 respostas

4

O pacote ICMP e a resposta para o ping têm, cada um, 32 bytes de comprimento por isso parece para um ping de uma hora que cada byte estava levando quase um minuto para transmitir.

Isso só é explicável por uma contagem de repetição de erros muito generosa (seu fazer?), juntamente com roteador muito lento e uma espera dolorosa ou tenta novamente para cada um e cada byte transmitido.

O Internet Protocol (IP) transmite dados por datagramas e tenta não enviar parciais. Depois que a transmissão for iniciada, ela aguardará por padrão por 200 milissegundos para mais bytes serem adicionados ao datagrama. Passado esse tempo, o software / firmware enviará o que tiver como um datagrama. No caso do tempo de ping de uma hora, a carga útil do pacote pode ter sido tão pequeno quanto um byte. Enquanto os dados ainda estiverem chegando, a conexão não será encerrada pelos dois lados participantes.

O que você pode fazer:

  • Se outros telefones, fax ou outros dispositivos estiverem conectados à mesma linha telefônica, verifique se eles estão protegidos por filtros DSL . Certifique-se de não colocar um filtro na linha que vai para o seu modem DSL.
  • Experimente outro roteador - uma vez que você tenha um dispositivo ruim, não há nada que você possa fazer a não ser descartá-lo e obter algo melhor.
  • Se não houver outro roteador disponível, entre em contato com o provedor - eles podem executar testes úteis do lado deles.
  • Se o ISP não encontrar nada, tente exigir um roteador / modem substituto.
  • Se o mesmo problema ocorrer com outro roteador, entre em contato com o empresa de telefonia.

Pode ser bastante complicado localizar um switch problemático, como pode ser com o companhia telefônica, mas o ISP também pode ter seus próprios switches. Normalmente, um problema com um switch é em toda a área que ajuda a localizar o interruptor com defeito. Mas em uma área rural onde não há muitos assinantes usando esse switch, isso pode não ser detectado. Se alguns vizinhos estiverem usando o mesmo ISP, tente descobrir qual é a conexão deles é como.

    
por 01.04.2016 / 20:55
0

Eu vejo este caso muito relacionado ao gerenciamento de congestionamento de dados, embora um gerenciamento muito ruim seja qual for o motivo. No meu entender, há buffer de pacote ao longo do sistema de transmissão - mal gerenciado, o que causa essa anomalia nos pacotes de solicitação / resposta de eco ICMP.

Portanto, a combinação de ter uma política de gerenciamento de congestionamento ruim com uma sessão de ping aberta por horas pode resultar, obviamente, em um cenário tão estranho.

Mais informações sobre o gerenciamento de congestionamentos aqui .

    
por 04.04.2016 / 17:31