Есть ли различия в производительности между ping и ping6?

Question

Я заметил, что команда ping6 была значительно медленнее, чем команда ping в MacOS 10.12.

Используя команду 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

Используя обычную команду 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

Я не могу понять, почему использование IPv6 будет медленнее, чем IPv4, поэтому есть ли причина, почему использование ping6 будет медленнее, чем использование ping?

обновленный

Я удалил пример проверки связи с удаленным именем хоста. Это не имело значения, так как я не могу быть уверен, что машины, которые были достигнуты, одинаковы в обоих тестах. Это также может привести к ответам, не относящимся к моему основному вопросу.

Answer 1

Реализация бинарных файлов ping и ping6 не совсем одинакова.

Кроме того, ни один из них не сообщает измеренное время tcpdump .

Вот один пример, хотя я сделал несколько для себя. Вот команда tcpdump я использовал:

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

Это показывает дельту временной метки 0,033 мс между первым пакетом IPV6 и ответом.

Однако ping6 сообщил, что время приема-передачи составляет 0,109 мс.

 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

Этот tcpdump показывает фактическое RTT 0,034 мс, но ping сообщает RTT 0,080 мс.

ping и ping6 - это два разных двоичных файла ; По своей более длинной адресации IPv6 потребует немного больше тактов ЦПУ, чтобы справиться с ними, даже если они были идентичными двоичными файлами во всех других отношениях (это не так).

Тем не менее, захват пакетов предполагает, что сетевые стеки моего Mac mini сравнительно быстрые; отключены вычисления времени прохождения сигнала ping и ping6 , что больше ping6 чем, как я ожидаю, будет намного проще ping .

Answer 2

Вы пингуете 2 разных сервера, попробуйте пинговать эти 2 сервера google для сравнения, так как вы можете видеть, что IPv6 намного быстрее, если его правильно поддерживать.

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

Answer 3

У IPv6, как протокола, нет веской причины быть значительно быстрее или медленнее, чем IPv4. Я думаю, что IPv6 может быть немного медленнее из-за его более длинных адресов, вызывающих немного больше накладных расходов, но это все.

Быстрее ли IPv4 или IPv6 в данном потоке трафика, почти всегда из-за различий в топологии / пути сети и относительного качества реализаций IPv4 и IPv6 на конечных точках и промежуточных блоках.

Несколько лет назад IPv6 часто был медленнее, чем IPv4, потому что путь обработки IPv4 в большинстве маршрутизаторов часто оптимизировался аппаратно ("быстрый путь"), тогда как путь обработки IPv6 все делался программно.

В настоящее время IPv6 часто быстрее, чем IPv4, потому что он не проходит через NAT, в то время как IPv4 часто должен проходить через шлюзы NAT, которые могут быть перегружены. Но сегодня все еще существуют сетевые пути, где IPv4 будет быстрее, чем IPv6. Это действительно во многом зависит от топологии сети и качества аппаратного и программного обеспечения конечных точек и промежуточных блоков.

Помните, что когда вы запрашиваете у DNS адреса IPv4 и IPv6 для заданного имени хоста, нет никакой гарантии, что все эти адреса будут находиться в одном физическом окне. Это особенно актуально при работе с известными веб-сайтами, которые используют CDN. И даже если они переходят в один и тот же физический блок, нет гарантии, что IPv4 и IPv6 будут использовать один и тот же маршрут через сеть. Фактически, на пути IPv4 довольно часто присутствуют шлюзы NAT, но не путь IPv6.

Случай, который вы задокументировали, когда петлевые эхо-запросы macOS отличаются друг от друга в случае IPv4 и IPv6, интересен. Кажется, что эти два случая должны быть намного ближе по скорости, чем то, что вы видите.