Existem diferenças de desempenho entre o ping e o ping6?

3

Percebi que o comando ping6 foi significativamente mais lento que ping no MacOS 10.12.

Usando o comando ping6 :

  ❯ ping6 localhost
  PING6(56=40+8+8 bytes) ::1 --> ::1
  16 bytes from ::1, icmp_seq=0 hlim=64 time=0.088 ms
  16 bytes from ::1, icmp_seq=1 hlim=64 time=0.092 ms
  16 bytes from ::1, icmp_seq=2 hlim=64 time=0.137 ms
  16 bytes from ::1, icmp_seq=3 hlim=64 time=0.117 ms
  16 bytes from ::1, icmp_seq=4 hlim=64 time=0.116 ms
  16 bytes from ::1, icmp_seq=5 hlim=64 time=0.112 ms
  16 bytes from ::1, icmp_seq=6 hlim=64 time=0.149 ms
  16 bytes from ::1, icmp_seq=7 hlim=64 time=0.116 ms
  16 bytes from ::1, icmp_seq=8 hlim=64 time=0.119 ms
  16 bytes from ::1, icmp_seq=9 hlim=64 time=0.125 ms
  ^C
  --- localhost ping6 statistics ---
  10 packets transmitted, 10 packets received, 0.0% packet loss
  round-trip min/avg/max/std-dev = 0.088/0.117/0.149/0.017 ms

Usando o comando regular ping :

  ❯ ping localhost
  PING localhost (127.0.0.1): 56 data bytes
  64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.048 ms
  64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.040 ms
  64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.070 ms
  64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.071 ms
  64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.077 ms
  64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.083 ms
  64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.109 ms
  64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.076 ms
  64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.040 ms
  64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.068 ms
  ^C
  --- localhost ping statistics ---
  10 packets transmitted, 10 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 0.040/0.068/0.109/0.020 ms

Não consigo imaginar por que usar o IPv6 seria mais lento que o IPv4, então, há alguma razão pela qual usar ping6 seria mais lento do que usar ping ?

Atualizado

Eu removi o exemplo de ping de um nome de host remoto. Não foi relevante, pois não posso ter certeza de que as máquinas que são alcançadas são as mesmas em ambos os testes. Também poderia levar a respostas não relacionadas à minha pergunta principal.

    
por dashdashzako 19.04.2017 / 23:57

3 respostas

1

A implementação dos binários ping e ping6 não é a mesma.

Além disso, nenhum relata o tempo medido em tcpdump .

Aqui está um exemplo, embora eu tenha feito vários para mim mesmo. Aqui está o comando tcpdump que usei:

tcpdump -i lo0 -t 5 -nqK

 00:00:00.000000 IP6 ::1 > ::1: ICMP6, echo request, seq 0, length 16
 00:00:00.000033 IP6 ::1 > ::1: ICMP6, echo reply, seq 0, length 16

Isso mostra um delta de timestamp de 0,033 ms entre o primeiro pacote IPV6 e a resposta.

ping6 , no entanto, comunicou o tempo de ida e volta como 0,109 ms .

 00:00:00.000000 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 17569, seq 0, length 64
 00:00:00.000034 IP 127.0.0.1 > 127.0.0.1: ICMP echo reply, id 17569, seq 0, length 64

Este tcpdump mostra um RTT real de 0,034 ms , mas ping informa um RTT de 0,080 ms .

ping e ping6 são dois binários diferentes; O IPv6 é, por natureza, seu endereçamento mais longo, vai demorar um pouco mais para lidar com os ciclos da CPU, mesmo se eles fossem binários idênticos de todas as outras formas (eles não são).

No entanto, a captura de pacotes sugere que as pilhas de rede do meu Mac mini são relativamente rápidas; são os cálculos de tempo de ida e volta ping e ping6 que estão desativados, ping6 a mais do que o que espero ser muito mais simples ping .

    
por 23.04.2017 / 06:36
1

Você está fazendo ping em 2 servidores diferentes tentando executar ping nesses 2 servidores do Google por causa da comparação, como você pode ver, o IPv6 é muito mais rápido quando é suportado corretamente.

IPv6: 2001: 4860: 4860 :: 8888

IPv4: 8.8.8.8

64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=61 time=3.71 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=61 time=1.67 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=61 time=1.62 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=4 ttl=61 time=3.34 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=5 ttl=61 time=2.63 ms

Reply from 8.8.8.8: bytes=32 time=23ms TTL=59
Reply from 8.8.8.8: bytes=32 time=24ms TTL=59
Reply from 8.8.8.8: bytes=32 time=8ms TTL=59
Reply from 8.8.8.8: bytes=32 time=12ms TTL=59
    
por 20.04.2017 / 00:53
1

Não há realmente uma boa razão para o IPv6, como protocolo, ser significativamente mais rápido ou mais lento que o IPv4. Eu acho que o IPv6 pode ser um pouco mais lento devido a seus endereços mais longos causando um pouco mais de sobrecarga, mas é sobre isso.

Se o IPv4 ou o IPv6 é mais rápido em um determinado fluxo de tráfego, quase sempre é devido a diferenças na topologia / caminho da rede e a qualidade relativa das implementações IPv4 e IPv6 nos terminais e caixas do meio.

Vários anos atrás, o IPv6 era mais lento que o IPv4 porque o caminho de manuseio do IPv4 na maioria dos roteadores era muitas vezes otimizado por hardware ("caminho rápido") enquanto o caminho de manuseio do IPv6 era feito em software.

Atualmente, o IPv6 é frequentemente mais rápido que o IPv4 porque não passa por nenhum NAT, enquanto o IPv4 geralmente tem que passar por gateways NAT que podem ser sobrecarregados. Mas ainda existem caminhos de rede hoje em que o IPv4 será mais rápido que o IPv6. Isso realmente depende bastante da topologia da rede e da qualidade do hardware e software dos endpoints e middleboxes.

Tenha em atenção que quando solicita ao DNS os endereços IPv4 e IPv6 de um determinado nome de anfitrião, não há garantia de que todos esses endereços vão para a mesma caixa física. Isto é especialmente verdadeiro quando se lida com sites de grande nome que usam CDNs. E mesmo se eles forem para a mesma caixa física, não há garantia de que o IPv4 e o IPv6 usarão a mesma rota na rede. De fato, é bastante comum que existam gateways NAT no caminho IPv4, mas não no caminho IPv6.

O caso documentado de pings de loopback do macOS sendo tão diferentes no caso IPv4 vs IPv6 é interessante. Parece que esses dois casos devem estar muito mais próximos do que você está vendo.

    
por 20.04.2017 / 01:53