มีความแตกต่างของประสิทธิภาพระหว่าง 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.