O RTT é teoricamente o mesmo, independentemente da origem do ping?

Question

Digamos que você envie um ping do dispositivo 1 para o dispositivo 2. O resultado fornecerá o RTT.

Teoricamente falando (porque muitas variáveis estão realisticamente em jogo), o RTT seria o mesmo fazendo o ping do dispositivo 1 do dispositivo 2?

    

Answer 1

Quando as coisas estão funcionando conforme o esperado, a latência será dominada pela velocidade da luz. Se os dois pontos de extremidade estiverem muito próximos (digamos, no mesmo edifício), o tempo de processamento em quaisquer roteadores e comutadores no caminho pode ser uma contribuição maior do que a latência devido à velocidade da luz.

No entanto, esses fatores serão os mesmos, desde que os pacotes em ambas as direções sigam o mesmo caminho.

Quando há mais de um caminho, os pacotes podem usar roteadores e os switches geralmente usam o ECMP (Equal Cost Multi Path) para decidir a direção a ser enviada para cada pacote. Isso geralmente usa um hash de campos de cabeçalho selecionados para escolher o caminho. Os campos de cabeçalho usados geralmente são um subconjunto de:

• MAC de origem
• MAC de destino
• IP de origem
• IP de destino
• protocolo IP
• Rótulo de fluxo
• Porta de origem
• Porta de destino

Destes, os cinco primeiros serão os mesmos, independentemente da direção em que você está executando o comando ping.

O rótulo de fluxo provavelmente será diferente e poderá fazer com que os pacotes percorram rotas diferentes. No entanto, esse campo só existe no IPv6 e nem todos os roteadores o considerarão ao escolher um caminho.

O ICMP não possui números de porta, portanto, esses campos não seriam considerados. Um roteador poderia usar o campo ID, no entanto, parece improvável que um caso especial seria implementado apenas para pacotes de solicitação / resposta de eco ICMP.

Assim, no geral, é improvável que os pacotes tomem rotas diferentes.

Outra razão mais provável para ver diferentes tempos de ida e volta nas duas direções é o tempo de processamento nos dois endpoints em si. Receber uma solicitação de eco e responder com uma resposta de eco é feito pelo kernel em todos os SOs que conheço e, portanto, acontece muito rapidamente. Mas o próprio comando ping é executado no modo de usuário e estará sujeito a mais latência se estiver sendo executado em uma máquina ocupada. Se as duas máquinas não estiverem igualmente carregadas, você pode esperar que o comando ping na máquina ocupada veja tempos de ida e volta um pouco mais altos por esse motivo.

    

Answer 2

Sim, para qualquer precisão significativa, o RTT será sempre o mesmo. Distância percorrida é o fator dominante na latência, e isso deve ser sempre o mesmo também. É muito incomum ver qualquer um dos casos de borda em que a distância percorrida não seria a mesma, mas uma exceção notável pode ser uma alteração no balanceamento de carga. Alguns roteadores podem usar uma função avançada para decidir em qual rota colocar seu tráfego e isso pode mudar entre as duas medições. Se houver um balanceamento de carga adaptável baseado em agente, você poderá usar uma rota diferente, dependendo de quanto tráfego estava usando vários caminhos disponíveis em sua rota. Estas são geralmente pequenas diferenças, mas em congestionamentos ou durante diferentes momentos do dia elas podem se tornar significativas.

    

Answer 3

Sim, mesmo que cada direção tenha um caminho completamente diferente, os dispositivos L3 (roteadores) não levam em conta se o pacote é uma solicitação de eco ICMP em oposição a uma resposta de eco ICMP, nem levam em conta se o pacote é um TCP SYN ou um TCP SYN-ACK.

Apenas para fins ilustrativos, vamos imaginar que para ir de A para B um pacote tem que passar por 5 saltos e demora 12ms, então para um pacote ir de B para A ele tem que passar por 12 saltos e um grande total de 22ms. O RTT medido neste cenário, independentemente de qual lado você escolher iniciar sua medida, será de 34ms (12ms + 22ms).