ทำไม mtr ถึงเร็วกว่า traceroute มาก?

ในmtrหน้าคนมันอ่าน:

mtr รวมการทำงานของ traceroute และโปรแกรม ping ในเครื่องมือวิเคราะห์เครือข่ายเดียว

ฉันใช้mtrมากและพบว่ามันเร็วกว่าtracerouteมาก โดยสัญชาตญาณmtrให้คำตอบอย่างน่าประทับใจในขณะที่tracerouteแสดงที่อยู่ IP ทุก ๆ วินาที ที่คอมพิวเตอร์ของฉันฉันใช้time mtr www.google.comและtime traceroute www.google.comผลลัพธ์คือ 21.9s VS 6.1

คำถามคือทำไม เนื่องจากไม่ได้หมายความว่ามันช้าลงหรืออย่างน้อยก็เป็นเช่นเดียวกับmtr = ping + traceroutetraceroute

ทุกคนสามารถให้คำตอบที่สมเหตุสมผลและมีรายละเอียดได้หรือไม่

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

ความแตกต่างที่สำคัญอีกประการหนึ่งซึ่งฉันไม่ได้กล่าวถึงคือเครื่องมือสองอย่างที่แสดงผลลัพธ์ Traceroute สร้างเอาต์พุตตามลำดับจากบนลงล่าง Mtr แสดงผลเอาต์พุตในวิธีที่ต่างกันโดยที่ mtr สามารถย้อนกลับและอัพเดตเอาต์พุตในบรรทัดก่อนหน้า

ซึ่งหมายความว่า mtr สามารถแสดงเอาต์พุตได้ทันทีที่พร้อมใช้งานเพราะถ้าการตอบกลับในภายหลังทำให้เอาต์พุตนั้นไม่ถูกต้อง mtr สามารถย้อนกลับและอัปเดตได้ เนื่องจาก traceroute ไม่สามารถย้อนกลับและอัปเดตเอาต์พุตได้จึงต้องรอจนกว่าจะได้ตัดสินใจในที่สุดว่าจะแสดงอะไร

ตัวอย่างเช่นถ้า hop หมายเลข 2 ไม่ตอบสนอง (ซึ่งเป็นอาการที่ฉันเห็นบน ISP หลาย ๆ เครื่อง) traceroute จะแสดงหมายเลข hop 1 แล้วรอสักครู่ก่อนที่จะแสดง hop หมายเลข 2 และ 3 แม้ว่าการตอบกลับจากหมายเลข hop 3 มาถึงแล้วมันไม่ได้ถูกแสดงเพราะ traceroute ยังคงรอการตอบกลับจากหมายเลข hop 2 Mtr ไม่มีข้อ จำกัด นั้นและสามารถแสดงคำตอบจาก hop หมายเลข 3 และยังคงกลับไปเพื่อแสดงคำตอบจาก hop หมายเลข 2 ถ้า มันมาถึงในภายหลัง

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

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

ความแตกต่างอีกอย่างคือจำนวนของฮ็อปที่ไม่มีคำตอบปรากฏขึ้นก่อนที่เครื่องมือจะหยุดแสดงฮ็อปมากขึ้น ฉันได้เห็นคำสั่ง traceroute ดำเนินการต่อสำหรับฮ็อปมากเท่าที่ร้องขอ (30 โดยค่าเริ่มต้น) ในขณะที่คำสั่ง mtr จะหยุดทันทีที่มันผ่านห้าฮ็อปที่ไม่มีการตอบสนอง

คำสั่ง traceroute กำลังส่ง 3 โพรบต่อ hop ถ้าคุณ จำกัด ให้เป็น 1 โพรบ-q 1ดังนั้นผลลัพธ์จะเปรียบเทียบกัน

time mtr -r -c 1 google.com
.
.
.
real    0m2.640s
user    0m0.003s
sys     0m0.018s


time traceroute6 -q 1 google.com
.
.
.
real    0m0.445s
user    0m0.006s
sys     0m0.007s

ฉันคาดหวังความแตกต่างที่สำคัญระหว่างการทดสอบเทียบเคียงจะเกี่ยวข้องกับเวลาสอบถาม DNS และความแตกต่างของเส้นทาง คุณจะทราบว่า traceroute ของฉันเร็วกว่า mtr แต่นี่ไม่ใช่กรณีเสมอไป

ฉันคิดว่าสิ่งนี้มาจากวิธีการติดตามเส้นทางถูกนำไปใช้ tracerouteส่งอย่างน้อย 3 แพ็คเก็ตสำหรับการกระโดดแต่ละครั้งในเส้นทางไปยังปลายทางตามลำดับ

mtr ค้นหาฮ็อพในเส้นทางก่อนจากนั้นส่งแพ็กเก็ตไปยังแต่ละโหนดพร้อมกัน

สำหรับฉันแล้วดูเหมือนว่ามีความแตกต่างในวิธีmtrจัดการกับการกระโดดไม่ตอบสนองต่อการ ping / probes; มันจะเพิกเฉยเร็วกว่าtracerouteที่ดูเหมือนว่าจะส่ง 3 แพ็คเก็ตตลอดเวลาแม้ว่าความพยายามครั้งแรกล้มเหลวในการรับการตอบกลับ

เหตุผลหลักคือวิธี traceroute ทำงาน มันส่งแพ็กเก็ต UDP (หรือ ICMP บน windows) ด้วย TTL หนึ่งไปยังโฮสต์แรกและเมื่อได้รับการตอบกลับ timeout (หรือผ่านการหมดเวลาภายใน) มันจะสร้างแพ็กเก็ตถัดไปสำหรับโฮสต์ถัดไปด้วย TTL สองและต่อ ๆ ไป (เพิ่มหนึ่งรายการใน TTL สำหรับแต่ละโฮสต์) ดังนั้นเวลาทั้งหมดของ traceroute จึงรวมถึงการส่งและรับแพ็กเก็ตสำหรับแต่ละโฮสต์ตามลำดับ

mtr หลังจากกำหนดพา ธ ที่แพ็กเก็ตใช้ส่งแพ็กเก็ต ICMP ECHO ทั้งหมดพร้อมกัน