Quanto a distância e ms podem afetar na velocidade de download?

Question

Vamos considerar A (cliente) e B (servidor) onde A faz o download de B.

• Quanto pode um mau encaminhamento de A para B afeta a velocidade de download?

  A traceroute from A to B returns a path that is 10 hops long, with a round-trip latency of 300ms. It also shows ~10% packet loss at hop four. Under normal conditions, the average round-trip latency between A and B is between 10ms and 30ms.

• Esse tipo de impacto pode reduzir um velocidade de download drasticaly ou contanto como lado e rotas têm o suficiente link para a velocidade máxima de A de B e vice-versa, deve manter o mesma velocidade?

• Além do tracert e da análise de ping de A para B o que mais é usado para identificar o problema?

Se você precisar de informações extras, por favor me avise.

    

Answer 1

Esta questão aborda várias questões relacionadas a várias coisas. Vou tentar respondê-las em ordem e depois fornecer uma explicação mais detalhada.

(parafraseando um pouco):

A traceroute from A to B returns a path that is 10 hops long, with a round-trip latency of 300ms. It also shows ~10% packet loss at hop four. Under normal conditions, the average round-trip latency between A and B is between 10ms and 30ms.

Enfrentando esses pontos na ordem:

1. O número de saltos em um caminho é praticamente irrelevante para uma taxa de transferência efetiva. O que importa é a latência de ponta a ponta, a perda média de pacotes e as configurações nas pilhas TCP em A e B, particularmente relacionadas a janelas TCP. (Mais detalhes abaixo.)
2. 10% de perda de pacotes no salto quatro em um traceroute é improvável que seja sintomático de problemas com a conexão ponta a ponta. Muitos roteadores implementam recursos como controlam o policiamento no avião ou Limitação de taxa de ICMP (particularmente a geração de ICMP "TTL expirou em trânsito "mensagens, nas quais o traceroute se baseia). A única maneira confiável de medir a perda de pacotes é examinar os contadores na pilha TCP ou capturar pacotes do fluxo de dados real usando tcpdump / Wireshark e examinar a captura usando um analisador de protocolo.
3. É muito raro que uma latência de ida e volta para um determinado destino da Internet mude de 10 a 30 ms para 300 ms. Tais mudanças seriam provavelmente o resultado de uma mudança desastrosa na política de roteamento dentro de um ISP, e provavelmente seriam corrigidas o mais rápido possível. Talvez o único caso em que eu possa ver isso ocorrendo normalmente seria em um site que tinha uma única conexão física (Ethernet, DSL, etc) para seu ISP com um backup via satélite.

Com relação ao impacto da latência na velocidade de download, muitas implementações do TCP são configuradas para usar um tamanho de janela de recepção de 64kbytes. Quando você tem uma conexão de alta latência entre dois hosts (mais especificamente um alto produto de atraso de largura de banda , esse tamanho de janela pode limite o seu rendimento efetivo, pois o TCP parará de transmitir dados em buffer até que ele comece a receber ACKs para dados já enviados do extremo remoto.

EDIT: Dependendo de como você configurou o pingplotter, ele pode não estar fornecendo uma representação precisa da perda na sua conexão. Se o pingplotter estiver usando o ICMP, é possível que as redes descartem / desprioritem esse tráfego em tempos de congestionamento, já que ele não é considerado 'tráfego de usuários'. Além disso, quaisquer dados sobre a perda no lúpulo intermediário devem ser considerados suspeitos, pelas razões mencionadas acima.

Se possível, seria interessante ter uma captura de pacotes em execução no seu host (isso pode ser feito com o Wireshark , por exemplo) e analisar a análise no Wireshark relacionada às conversas TCP reais que seus aplicativos estão executando.

    

Answer 2

Sim, alta latência em uma conexão de rede pode certamente impactar na velocidade de download (haverá um impacto menor se a janela TCP for razoavelmente grande, para que a origem possa enviar vários pacotes sem ter que esperar que cada um seja reconhecido ). E qualquer perda significativa de pacotes terá um efeito catastrófico no desempenho, pois toda vez que um pacote for perdido, o download será efetivamente interrompido pela duração do tempo limite de retransmissão TCP.