ทำไม traceroute ใช้เวลานานกว่าปิงมาก?

16

จะอธิบายเรื่องนี้อย่างไร

C:\Documents and Settings\Administrator>tracert google.com

Tracing route to google.com [64.233.189.104]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     7 ms    <1 ms    <1 ms  reserve.cableplus.com.cn [218.242.223.209]
  3   108 ms   135 ms   163 ms  211.154.70.10
  4     *        *        *     Request timed out.
  5     2 ms     *        1 ms  211.154.64.114
  6     1 ms     1 ms     1 ms  211.154.72.185
  7     1 ms     1 ms     1 ms  202.96.222.77
  8     2 ms     1 ms     2 ms  61.152.81.145
  9     1 ms     2 ms     1 ms  61.152.86.54
 10     1 ms     1 ms     1 ms  202.97.33.238
 11     2 ms     2 ms     2 ms  202.97.33.54
 12     2 ms     1 ms     2 ms  202.97.33.5
 13    33 ms    33 ms    33 ms  202.97.61.50
 14    34 ms    34 ms    34 ms  202.97.62.214
 15    34 ms   186 ms    37 ms  209.85.241.56
 16    35 ms    35 ms    44 ms  66.249.94.34
 17    34 ms    34 ms    34 ms  hkg01s01-in-f104.1e100.net [64.233.189.104]

Trace complete.

เวลาเฉลี่ยควรเป็น: 1 + 7 + 108 + 2 + 1 + 1 + 1 + 2 + 1 + 1 + 2 + 33 +34 + 34 +34 +34 +34 +34 +34 +34 ซึ่งมากกว่าที่มาก ping

C:\Documents and Settings\Administrator>ping google.com

Pinging google.com [64.233.189.104] with 32 bytes of data:

Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241

Ping statistics for 64.233.189.104:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 34ms, Maximum = 34ms, Average = 34ms

ping networking

— splattne
แหล่งที่มา

3

คำตอบที่ไม่ดีมากมายในคำถามนี้ ทุกคนเตือนฉันในทางของyoutube.com/watch?v=SXmv8quf_xM

— Tom O'Connor

16

คุณไม่สามารถเพิ่มตัวเลขทั้งหมดเข้าด้วยกันได้ นั่นคือเวลา ping ของแต่ละฮ็อปบนเส้นทางสู่ google ดังนั้นแต่ละขาของเส้นทางจะยาวขึ้นและห่างออกไปมากขึ้นและคุณจะเห็นเวลา ping ที่ต่างกัน หากคุณดูเวลา ping ล่าสุดใน tracert (34 ms) และเวลาที่คุณได้รับเมื่อคุณออก ping (34ms) สิ่งเหล่านี้จะเหมือนกัน โปรแกรม tracert ไม่ช้ากว่า ping

ฉันขอแนะนำให้อ่านวิธีการทำงานของ traceroute:
http://en.wikipedia.org/wiki/Traceroute

— einstiien
แหล่งที่มา

farther and farther awayมันไม่ได้

ฉันไม่เข้าใจว่าคุณหมายถึงอะไร ที่อยู่ IP แต่ละรายการใน traceroute คือที่อยู่ของเราเตอร์ตัวต่อไปที่อยู่ระหว่างคุณกับ Google ในทอพอโลยีเครือข่าย "แบบลอจิคัล" สิ่งเหล่านี้จะหายไปเมื่อคุณดำเนินการตามรายการ นอกจากนี้ส่วนใหญ่จะอยู่ห่างจากที่ตั้งทางภูมิศาสตร์ของคุณมากขึ้น แม้ว่าสิ่งนี้จะไม่เป็นจริงเสมอไปเนื่องจากบางครั้งเส้นทางดูเหมือนจะกระโดดไปรอบ ๆ แผนที่ "ไม่จำเป็น" แต่ประเด็นของฉันคือระยะทางกายภาพและกระโดดหลายครั้งเพิ่มเวลา ping

— einstiien

ลองกระตุกแต่ละโหนดในเส้นทาง คุณควรมีจำนวนรวมเท่ากัน (โดยประมาณ)

— Chris Nava

1

บางที PHP อยู่ผิดไซต์ stackoverflow และหมายความว่าไกลขึ้นหมายถึงระยะทางกายภาพในขณะที่ต่อไปจะเหมาะสมกว่าสำหรับระยะทางเครือข่าย english.stackexchange.com

— dunxd

12

คุณสามารถดู ping เหมือนไดรฟ์จากนิวยอร์กไปยังซานฟรานซิสโก ใช้เวลาประมาณ 200 ชั่วโมง (im จากสวิตเซอร์แลนด์และไม่คุ้นเคยกับระยะทางในสหรัฐอเมริกา)

แต่คนขับต้องกลับมานิวยอร์กเพื่อบอกคุณว่าเขาอยู่ในซานฟรานซิสโก คุณดูที่นาฬิกาและตอนนี้คุณคำนวณว่าเขาใช้เวลา 400 ชั่วโมงสำหรับระยะทาง ตอนนี้นั่นคือสิ่งที่ Ping ทำ สิ่งที่ Traceroute ทำคือ: บอกคนขับรถของคุณว่าเขาควรขับรถจากนิวยอร์กไปยังซานฟรานซิสโกและทุกครั้งที่เขามาถึงทางแยกเขาควรกลับมาและบอกชื่อของคุณ ดังนั้นเขาจึงเดินทางไปและสี่แยกแรกอยู่ในนิวยอร์ก ดังนั้นเขาจึงค่อนข้างเร็วด้วยการขับรถกลับมาหาคุณและบอกชื่อทางแยกให้คุณ แต่เมื่อเขาอยู่ห่างไกลเขาจะใช้เวลานานกว่าจะกลับมาหาคุณ และอื่น ๆ ...

ดังนั้นหากคุณนับจำนวนชั่วโมงการขับขี่ทั้งหมดที่เขาเดินทางเขาจะต้องใช้เวลานานกว่าในการรายงานสี่แยกมากกว่าถ้าเขาต้องขับรถไปที่ซานฟรานซิสโก หวังว่าสิ่งนี้จะช่วยคุณ ...

— Bona
แหล่งที่มา

2

การเปรียบเทียบที่ดีกว่าคือคุณส่งไดรเวอร์ 30 ตัวโดยบอกให้พวกเขาแต่ละคนมุ่งหน้าไปยังนิวยอร์ก แต่แต่ละคนจะต้องหันกลับมาที่สี่แยกแรกทางแยกที่สองทางแยกที่สามและอื่น ๆ ทั้งหมด ทางขึ้นไปถึงทางแยกสามสิบทาง (หวังว่าจะมีน้อยกว่า 30 ระหว่าง SF และ NY)

— Jed Daniels

0

อันที่จริงแล้วโดยทั่วไปแล้วเนื่องจาก PING ส่งคำขอ ICMP ผ่านเครือข่ายไปยัง DNS และอุปกรณ์ของเครือข่ายอื่น

อย่างไรก็ตาม Traceroute ส่งชุดข้อมูลจำนวนมากโดยมี TTL สั้นมาก

เพื่อเป็นตัวอย่างเมื่อคุณพยายามเข้าร่วม www.google.com จากที่นั่งของคุณ traceroute ส่ง paquet ไปที่ www.google.com โดยตั้งค่า TTL เป็น 1 และรอคำตอบจากอุปกรณ์เครือข่ายที่พบครั้งแรก

จากนั้น Traceroute จะแสดง IP ของอุปกรณ์เครือข่ายแรกบนหน้าจอของคุณและหลังจากนั้นจะทำสิ่งเดียวกัน แต่คราวนี้ด้วยการตั้งค่า TTL เป็น 2 เป็นต้น

ในตอนท้าย Traceroute รออีกประมาณครึ่งเพราะในแต่ละการส่งจะรอคำตอบจากอุปกรณ์เครือข่าย

— ดร
แหล่งที่มา

0

traceroute มักจะบอกคุณไปยังปลายทางเฉลี่ยไม่การสะสมของเวลา, ที่อยู่, ในกรณีของคุณก็ 34ms ด้วยและpingtraceroute

หาก traceroute กำลังทำสิ่งที่คุณแนะนำเอาท์พุทของมันจะอ่านไม่ได้เลยทีเดียว

หากคุณเพียงแค่สนใจเวลาตอบสนองของจุดหมายปลายทางpingก็เพียงพอแล้วtracerouteสำหรับเมื่อคุณต้องการแก้ไขข้อบกพร่องบางอย่างบนเส้นทางไปยังปลายทาง ยิ่งไปกว่านั้นฮ็อพทั้งหมดระหว่างคุณและปลายทางคือเราเตอร์และส่วนใหญ่แล้วเราเตอร์มีลำดับความสำคัญในสิ่งที่ต้องทำนั่นคือแพ็กเก็ตเส้นทางแรกและจากนั้นตอบ ping หรือ traceroute (นั่นคือกรณีแรก ตอบicmp echo replyและในกรณีที่สองกicmp time exceeded) และมักจะตอบช้ากว่า (เมื่อตอบคำถามทั้งหมด)

— เสื่อ
แหล่งที่มา

0

เพื่อลูกหลานเนื่องจากไม่มีคำตอบที่ถูกต้องชัดเจนมาก ...

-

แต่ละครั้งที่แสดงใน traceroute คือเวลาทั้งหมดจากเครื่องของคุณ (หรือเครื่องที่ทำ traceroute ... ) ไปยังโหนดที่มีเฉพาะ

กล่าวอีกนัยหนึ่งเวลาที่แสดงบนโหนดที่ 2 ไม่ใช่เวลาระหว่างโหนด 1 และ 2 แต่จะรวมเวลาทั้งหมดระหว่างแหล่งที่มาโหนดแรกและโหนดที่สองทั้งหมดรวมกัน

โดยเฉลี่ยแล้วเวลาที่แสดงในแต่ละโหนดควรตรงกับเวลาที่คุณจะได้รับถ้าคุณจะ ping โหนดนั้น "โดยตรง" (มันไม่ได้ตรงกว่า traceroute ในความเป็นจริง ... โดยปกติจะเป็นไปตามเส้นทางเดียวกัน ในอินเตอร์เน็ต).

เพียงจำไว้ว่ามีสิ่งเช่น "ขัดขวางความล่าช้า" วิธีที่ถูกต้องที่สุดในการค้นหาแหล่งที่มาของความล่าช้าใด ๆ คือการเรียกใช้ traceroute โดยทำซ้ำโดยใช้ไฟล์แบตช์ (หากคุณใช้ Windows) และค้นหาโหนดที่ใกล้ที่สุด (ตัวเลขน้อยที่สุด) ที่มีตัวเลขสูงในเวลาที่กำหนด

-

สำหรับไฟล์แบตช์ให้เปิด Notepad และพิมพ์ 3 บรรทัดเหล่านี้:

:start
tracert -d www.google.com
goto start

จากนั้นบันทึกเป็น "Trace.bat" แต่ให้แน่ใจว่าได้เปลี่ยนประเภทไฟล์ในกล่องโต้ตอบการบันทึกเป็น "ไฟล์ทั้งหมด" ก่อนที่จะบันทึกหรือจะยังคงบันทึกเป็นไฟล์ข้อความ

เมื่อเปิดขึ้นสิ่งนี้จะเรียกใช้ traceroutes (ไปยัง google) อย่างต่อเนื่อง คุณสามารถหยุดมันได้โดยกด ctrl + c ขณะที่คุณเลือกหน้าต่าง

-

แน่นอนคุณสามารถเปลี่ยนตำแหน่งที่ traceroute ใช้โดยเปลี่ยน "www.google.com" เป็นที่อยู่ใดก็ได้ที่คุณต้องการ

คุณยังสามารถลบตัวเลือก "-d" หากคุณต้องการดูชื่อโฮสต์ที่ได้รับการแก้ไข แต่สิ่งนี้จะทำให้ traceroute ใช้เวลานานขึ้นเนื่องจากการรับชื่อโฮสต์ดังกล่าวจากเซิร์ฟเวอร์ DNS สำหรับแต่ละโหนด (นี่ไม่ได้เปลี่ยนผลลัพธ์จริงด้วยตนเองอย่างไรก็ตาม )

สุดท้ายหากคุณพบโหนดที่มีเวลาสูงและต้องการเรียกใช้ traceroutes เป็นโหนดนั้นในกรณีที่โหนดอื่นก่อนที่จะมีปัญหาคุณสามารถเปลี่ยน "www.google.com" เป็นที่อยู่ IP หรือชื่อโฮสต์ของโหนดนั้นหรือ คุณสามารถใช้ตัวเลือก -h เพื่อระบุจำนวนโหนดที่จะค้นหาเช่น ...

:start
tracert -d -h 5 www.google.com
goto start

— Laike Endaril
แหล่งที่มา

หมายเหตุสำคัญคือโหนดตอบกลับด้วย ICMP แต่จุดประสงค์หลักของเราเตอร์คือการกำหนดเส้นทางแพ็คเก็ตและการสร้างการตอบกลับ ICMP นั้นอยู่ไกลจากรายการสิ่งที่ทำ เราเตอร์จะกำหนดเส้นทางและจะส่งข้อความ ICMP เมื่อถึงเวลา นั่นคือเหตุผลที่เวลากลางอาจนานกว่าเส้นทางแบบเต็ม เราเตอร์ระดับกลางอาจยุ่งกว่าโหนดปลายทางมาก

— Ron Maupin

ใช่ลำดับความสำคัญของ QOS ของ ICMP มักจะต่ำกว่า แต่บ่อยครั้งเมื่อคุณเรียกใช้ traceroute นั่นเป็นเพราะปัญหามีอยู่แล้ว (คุณมี spikes ที่ล่าช้าหรือ ping ไม่ดีในเกม) และโหนดที่คุณกล่าวถึง ( สิ่งที่ไม่ว่าง) คือคอขวดที่คุณกำลังมองหา

— Laike Endaril

ฉันไม่ได้หมายถึงลำดับความสำคัญของ QoS ฉันหมายถึงอุปกรณ์ที่สร้างการตอบกลับ ICMP จริงๆแล้วโหนดอาจเป็นแพ็กเก็ตเราติ้งไม่ว่างเกินไปที่จะหลีกเลี่ยงการส่งข้อความ ICMP ก่อนที่โหนดเดิมจะหมดเวลา เราเตอร์จะกำหนดเส้นทางแพ็กเก็ตก่อนตัดสินใจส่งข้อความ ICMP นั่นไม่เกี่ยวข้องกับ QoS

— Ron Maupin

QoS เป็นคำที่กำหนดอย่างหลวมตัวและฉันคิดว่ามันจะรวมกิจกรรมทั้งหมดที่ใช้ชุดทรัพยากรเดียวกันแทนที่จะแยกกิจกรรมที่ต้องการความสนใจเป็นพิเศษ (สร้างแพ็คเก็ตการตอบสนอง) แต่ไม่ว่าจะด้วยวิธีใดก็ตามไม่เปลี่ยนความจริงที่ว่าเราเตอร์ดังกล่าวมีภาระหนักเกินไปและถูกผูกไว้เพื่อทำให้เกิดปัญหาดังนั้นช่วงเวลาที่สูงจาก traceroute ยังคงเป็นตัวบ่งชี้ที่ดีสำหรับปัญหาของคุณ ... ข้อยกเว้นที่เป็นไปได้ของการรับส่งข้อมูลจำนวนมากที่มีลำดับความสำคัญสูงกว่า ICMP ของคุณ แต่มีลำดับความสำคัญต่ำกว่าการรับส่งข้อมูลปกติของคุณ

— Laike Endaril

-1

เนื่องจาก tracert ใช้แพ็คเก็ต UDP เช่น ping ใช้ ICMP pakets ภายใต้ Linux มีtraceroute -Iตัวเลือกให้ทำ ICMP traceroute

ในการทดสอบของคุณเวลาในการเชื่อมต่อกับ google นั้นเหมือนกันใน traceroute และ ping: 34ms เราเตอร์ทั้งหมดที่อยู่ตรงกลางมีเวลาของตนเองในการตอบรับ แต่ไม่ส่งผลกระทบต่อเวลาโอนสุดท้าย

http://en.wikipedia.org/wiki/Tracerouteอธิบายทั้งหมดใน Traceroute

— Dom
แหล่งที่มา

3

ที่จริงบน Windows, tracertใช้ ICMP tracerouteโดยค่าเริ่มต้นแตกต่างจากลินุกซ์

— phoebus

tracert ใช้ระยะเวลา ICMP ICMP เป็นโปรโตคอล IP 1, UDP คือ 17.

— dbasnett

@ dbasnett เดิมที traceroute ส่งแพ็กเก็ตขาออกเป็น UDP และแพ็กเก็ตส่งคืนนั้นแน่นอนว่า ICMP TTL มีข้อความเกิน Windows และตอนนี้โปรแกรม traceroute อื่น ๆ ใช้ ICMP echo ร้องขอแพ็คเก็ตสำหรับการส่งออก โดยทั่วไปเมื่อผู้คนอ้างถึง UDP traceroute หรือ ICMP traceroute มันเป็นแพ็กเก็ตขาออกเหล่านี้ที่พวกเขาอ้างถึงเนื่องจากกลไกทั้งสองพึ่งพา ICMP TTL เกินกว่าข้อความที่กลับมาถึงผู้ส่งจากเส้นทางตามเส้นทาง

— Jed Daniels

-1

คุณสามารถเพิ่ม traceroute ของคุณโดยการปิดการค้นหา reverse DNS ซึ่งมักจะล้มเหลว: tracert -d www.google.com

— Mathieu Chateau
แหล่งที่มา

สิ่งนี้ไม่ทำให้การเดินทางไป - กลับเร็วขึ้นเท่าไหร่ อย่างไรก็ตามจะทำให้เร็วขึ้นในการแสดงผลลัพธ์บนหน้าจอของคุณเนื่องจากไม่ได้ทำการค้นหา DNS

— Jed Daniels