มีความแตกต่างของประสิทธิภาพระหว่าง ping และ ping6 หรือไม่


3

ฉันสังเกตเห็น 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?

Updated

ฉันได้ลบตัวอย่างของการส่งชื่อโฮสต์ระยะไกลแล้ว มันไม่เกี่ยวข้องเนื่องจากฉันไม่สามารถมั่นใจได้ว่าเครื่องที่เข้าถึงจะเหมือนกันในการทดสอบทั้งสองและอาจนำไปสู่คำตอบที่ไม่เกี่ยวข้องกับคำถามหลักของฉัน


เดา: เนื่องจากคุณกำลังกระตุกโลคอลโฮสต์เท่านั้นเหตุผลอาจแตกต่างกันในเครือข่ายสแต็คของระบบปฏิบัติการโดยที่เคส IPv4 ได้รับการปรับให้เหมาะสมที่สุด
dirkt

คำตอบ:


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 ms ระหว่างแพ็กเก็ต IPV6 แรกและการตอบกลับ

ping6 อย่างไรก็ตามรายงานเวลาไปกลับเป็น 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

นี้ tcpdump แสดง RTT จริงของ 0.034 ms แต่ ping รายงาน RTT ของ 0.080 ms .

ping และ ping6 เป็นสองไบนารีที่แตกต่างกัน IPv6 คือโดยธรรมชาติของการกำหนดที่อยู่ที่นานกว่านั้นจะใช้รอบ CPU เพิ่มอีกนิดหน่อยเพื่อจัดการแม้ว่ามันจะเป็นไบนารีที่เหมือนกันในทุก ๆ ทาง

อย่างไรก็ตามการจับแพ็คเก็ตแสดงให้เห็นว่าสแต็คเครือข่ายของ Mac mini ของฉันค่อนข้างเร็ว มันเป็น ping และ ping6 การคำนวณเวลาไปกลับที่ปิด ping6 มากกว่าสิ่งที่ฉันคาดหวังว่าจะง่ายกว่านี้มาก ping.


นี่เป็นการบอกว่าการจัดการ IPV6 (อย่างน้อยใน Macs ของเรา) และ ping6 ไบนารีช้ากว่า v4 รุ่นไหม?
dashdashzako

อืมมมไม่มี ระยะเวลาที่ใช้ในการตอบกลับมีความคล้ายคลึงกับ IPv4 และ IPv6 ความแตกต่างอยู่ในเวลาที่รายงานโดย ping และ ping6 ไบนารี คนที่มีทักษะในการทำโปรไฟล์ไบนารี่ / ระบบมากกว่าที่ฉันอาจจะเข้าใจได้ว่าทำไมมันถึงเป็นแบบนี้ ... โดยใช้ /usr/bin/time -l ในแต่ละกระบวนการจะแสดงสัญญาณที่ได้รับมากขึ้น page reclaimsและ 'เปิดสวิตช์บริบท' ping6 กว่า ping.
Nevin Williams

1

คุณกำลังกระตุกเซิร์ฟเวอร์ที่แตกต่างกัน 2 เซิร์ฟเวอร์ลอง Ping เซิร์ฟเวอร์ 2 ตัวนี้เพื่อเปรียบเทียบเพราะคุณจะเห็นว่า 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

Google DNS ไม่ใช่ตัวอย่างที่ดีเพราะใช้ Anycast
Daniel B

BTW, ::1 คือ IPv6 localhost (ตรวจสอบด้วย ip -6 addr ) ดังนั้นเขาจึงส่งเสียง "เซิร์ฟเวอร์" เดียวกันนั่นคือเครื่องของเขาเอง
dirkt

1

ไม่มีเหตุผลที่ดีจริงๆสำหรับ IPv6 ซึ่งเป็นโปรโตคอลที่จะเร็วกว่าหรือช้ากว่า IPv4 อย่างมาก ฉันเดาว่า IPv6 อาจช้าลงเล็กน้อยเนื่องจากที่อยู่ที่ยาวขึ้นทำให้ค่าใช้จ่ายเพิ่มขึ้นเล็กน้อย แต่นั่นเป็นเรื่องของมัน

ไม่ว่า IPv4 หรือ IPv6 นั้นเร็วกว่าในทราฟฟิกที่ให้มาเกือบทุกครั้งหรือไม่เพราะความแตกต่างในทอพอโลยีเครือข่าย / พา ธ และคุณภาพสัมพัทธ์ของการใช้งาน IPv4 และ IPv6 บนจุดปลายและมิดบ็อกซ์

เมื่อหลายปีก่อน IPv6 นั้นบ่อยครั้ง ช้าลง มากกว่า IPv4 เพราะเส้นทางการจัดการ IPv4 ในเราเตอร์ส่วนใหญ่มักจะปรับแต่งฮาร์ดแวร์ ("พา ธ ด่วน") ในขณะที่เส้นทางการจัดการ IPv6 นั้นทำในซอฟต์แวร์ทั้งหมด

ปัจจุบัน IPv6 มักจะเป็น ได้เร็วขึ้น มากกว่า IPv4 เพราะมันไม่ผ่าน NATs ใด ๆ ในขณะที่ IPv4 มักจะต้องผ่านเกตเวย์ NAT ซึ่งสามารถโหลดได้มากเกินไป แต่ปัจจุบันยังมีเส้นทางเครือข่ายที่ IPv4 จะเร็วกว่า IPv6 มันขึ้นอยู่กับโครงสร้างเครือข่ายและคุณภาพของฮาร์แวร์และซอฟต์แวร์ของอุปกรณ์ปลายทางและมิดบ็อกซ์

ระวังว่าเมื่อคุณขอ DNS สำหรับที่อยู่ IPv4 และ IPv6 ของชื่อโฮสต์ที่ระบุไม่มีการรับประกันว่าที่อยู่เหล่านั้นทั้งหมดจะไปที่กล่องทางกายภาพเดียวกัน นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งเมื่อต้องรับมือกับเว็บไซต์ชื่อใหญ่ที่ใช้ CDN และแม้ว่าพวกเขาจะไปที่กล่องทางกายภาพเดียวกันไม่มีการรับประกันว่า IPv4 และ IPv6 จะใช้เส้นทางเดียวกันทั่วทั้งเครือข่าย จริงๆแล้วมันค่อนข้างธรรมดาที่จะมี NAT เกตเวย์ในเส้นทาง IPv4 แต่ไม่ใช่เส้นทาง IPv6

กรณีที่คุณทำเอกสารเกี่ยวกับการส่ง Ping ไปยัง macOS นั้นแตกต่างกันมากในกรณี IPv4 กับ IPv6 นั้นน่าสนใจ ดูเหมือนว่าทั้งสองกรณีควรมีความเร็วใกล้กว่าที่คุณเห็น


ใช่นี่เป็นพฤติกรรมพิเศษที่ฉันสนใจและฉันได้อัปเดตคำถามเพื่อสะท้อนสิ่งนั้น
dashdashzako
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.