ฉันรู้ว่าเครือข่ายใช้หลายเส้นทาง พวกเขาปรากฏตัวใน traceroute แต่ไม่ใช่ mtr mtr กำลังเกาะติดกับเส้นทางแรกอยู่หรือเปล่า? ดงคืออะไร

$ traceroute google.com
traceroute to google.com (216.58.210.46), 30 hops max, 60 byte packets
 1  gateway (172.16.9.1)  1.303 ms  1.332 ms  1.421 ms
 2  host-92-31-0-1.as13285.net (92.31.0.1)  14.965 ms  15.810 ms  16.978 ms
 3  xe-11-2-0-bragg001.bre.as13285.net (78.151.225.39)  19.456 ms  20.785 ms  23.052 ms
 4  host-78-151-225-14.static.as13285.net (78.151.225.14)  24.255 ms host-78-151-229-20.as13285.net (78.151.229.20)  25.979 ms host-78-151-225-18.static.as13285.net (78.151.225.18)  27.059 ms
 5  host-78-144-8-57.as13285.net (78.144.8.57)  33.513 ms host-78-144-12-213.as13285.net (78.144.12.213)  35.825 ms host-78-144-10-37.as13285.net (78.144.10.37)  35.374 ms
 6  72.14.214.222 (72.14.214.222)  38.005 ms 72.14.242.127 (72.14.242.127)  35.820 ms 72.14.214.222 (72.14.214.222)  34.968 ms
 7  216.239.54.251 (216.239.54.251)  37.260 ms 64.233.174.83 (64.233.174.83)  22.876 ms 216.239.54.251 (216.239.54.251)  25.085 ms
 8  108.170.232.105 (108.170.232.105)  25.606 ms 108.170.232.103 (108.170.232.103)  27.050 ms  28.886 ms
 9  lhr25s11-in-f46.1e100.net (216.58.210.46)  29.601 ms  30.552 ms  31.896 ms
$ mtr --report google.com
Start: Wed Oct 26 11:07:33 2016
HOST: localhost.localdomain       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway                    0.0%    10    1.2   1.6   1.1   2.7   0.5
  2.|-- host-92-31-0-1.as13285.ne  0.0%    10   16.8  15.3  14.0  18.3   1.2
  3.|-- xe-11-2-0-bragg001.bre.as  0.0%    10   19.2  16.5  14.9  19.2   1.1
  4.|-- host-78-151-225-30.static  0.0%    10   16.3  16.2  15.7  16.6   0.0
  5.|-- host-78-144-12-147.as1328  0.0%    10   23.1  23.1  22.3  25.2   0.7
  6.|-- 72.14.242.127              0.0%    10   23.3  23.9  23.0  26.1   1.0
  7.|-- 216.239.54.251             0.0%    10   22.5  22.8  21.9  25.3   0.8
  8.|-- 108.170.232.105            0.0%    10   22.1  22.5  22.0  23.2   0.0
  9.|-- lhr25s11-in-f46.1e100.net  0.0%    10   23.3  23.4  22.7  24.3   0.0

ที่จริงแล้ว traceroute ใน Linux รุ่นใหม่มีตัวเลือกที่ตรงกับพฤติกรรม mtr (และในทางกลับกัน) เราสามารถเห็นสิ่งนี้เป็นเรื่องของการเริ่มต้นเท่านั้น

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

ค่าเริ่มต้น

วิธีการตามรอยโบราณ ใช้โดยค่าเริ่มต้น

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

ICMP

วิธีการที่ใช้กันมากที่สุดในตอนนี้ใช้แพ็คเก็ต icmp echo สำหรับโพรบ หากคุณสามารถ ping (8) โฮสต์ปลายทางการติดตาม tracerout ของ icmp ก็สามารถใช้ได้เช่นกัน

mtrดูเหมือนว่าค่าเริ่มต้นของ icmp จะเป็น "วิธีปกติที่สุดในตอนนี้"

ข้อสรุป

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

tracerouteค่าเริ่มต้นจะเปลี่ยนพอร์ต UDP สำหรับแต่ละโพรบดังนั้นจึงเปลี่ยนพา ธ

mtrค่าเริ่มต้นของใช้ ICMP echo ซึ่งไม่มีหมายเลขพอร์ตและดังนั้นโพรบของมันจะเป็นไปตามเส้นทางเดียวกัน

หากคุณร้องขอ UDP หรือ TCP traceroute mtrระบบจะแสดงเส้นทางที่แตกต่างกัน อาจมีความแตกต่างอื่น ๆ เมื่อเทียบกับtracerouteแต่ในแง่นี้มันเกิดขึ้นเพื่อทำงานในทำนองเดียวกัน

Sidetrack: ทำไมถึงไม่ใช้ icmp

ดังนั้น Linux จึงtracerouteยังคงซื่อสัตย์ต่อต้นฉบับอยู่โดยเจตนารวมถึงการเลือกโหมดเริ่มต้น แต่เหตุผลในการเลือกดั้งเดิมไม่ชัดเจนโดยสิ้นเชิง

ฉันจำได้ว่าอ่านman tracepath:

เราเตอร์เชิงพาณิชย์ [IPv4] ไม่ส่งคืนข้อมูลที่เพียงพอในข้อความแสดงข้อผิดพลาด icmp อาจจะมีการเปลี่ยนแปลงเมื่อพวกเขาจะได้รับการปรับปรุง สำหรับตอนนี้ [tracepath] ใช้เคล็ดลับของ Van Jacobs โดยกวาดพอร์ต UDP ที่หลากหลายเพื่อรักษาประวัติการติดตาม

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

Traceroute จะแตกต่างกันไป (เพิ่มขึ้น) หมายเลขพอร์ตปลายทาง UDP สำหรับแต่ละโพรบที่ส่งออกไปเพื่อให้ตรงกับ ICMP TTL ที่เชื่อถือได้ข้อความที่เกินไปยังแต่ละโพรบ เนื่องจากพอร์ต UDP เกิดขึ้นหลังจากส่วนหัวของ IP จึงสามารถเชื่อถือได้เพื่อรวมไว้ในส่วน "แพ็คเก็ตดั้งเดิม" ของ ICMP TTL ข้อความที่มากเกินไปแม้ว่ามาตรฐาน ICMP จะบังคับเท่านั้นว่าแปด octets แรกต่อจากส่วนหัว IP ของ แพ็คเก็ตเดิมจะรวมอยู่ในข้อความ ICMP (อนุญาตให้ส่งได้มากกว่า)

เมื่อมีการใช้คำขอ ICMP ECHO ตัวตรวจสอบสามารถถูก disambiguated โดยใช้ฟิลด์หมายเลขลำดับซึ่งเกิดขึ้นก่อนที่จะมีขอบเขต 8-octet

PERTยังคงแนะนำต่อไป

เป็นที่เชื่อกันว่าเป็นเพราะในเวลานั้นบางเกตเวย์ (เมื่อเราเตอร์ถูกเรียกแล้ว) ปฏิเสธที่จะส่งข้อความ ICMP (เกิน TTL) เพื่อตอบสนองต่อข้อความ ICMP ตามที่ระบุไว้ในการแนะนำ RFC 792 "Internet Protocol Message Protocol" . ดังนั้นตัวแปร UDP จึงแข็งแกร่งกว่า

ความคิดเห็นรหัสที่มาอธิบายการใช้งานพอร์ต UDP เช่นกัน แต่ไม่ได้ใช้ UDP มากกว่า ICMP ก้อง การอ่านอย่างเข้มงวดแสดงให้เห็นความเป็นไปได้อีกอย่างหนึ่ง

เนื่องจาก icmp ไม่ได้ถูกส่งไปยัง icmp

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

อย่างไรก็ตามมันก็เป็นไปได้ที่ Van Jacobson พูดคุยกับตัวเอง สิ่งหนึ่งอาจสันนิษฐานได้ว่าข้อผิดพลาด icmp จะไม่ถูกส่งคืนสำหรับแพ็กเก็ต icmp ใด ๆ โดยมองว่าสิ่งนี้ไม่ได้นำไปใช้กับคำขอ icmp echo

อย่าใช้สิ่งนี้เป็นตัวอย่างการเข้ารหัส ฉันพยายามค้นหาปัญหาการกำหนดเส้นทางและการเรียงลำดับของรหัสนี้โผล่ออกมาหลังจาก 48 ชั่วโมงโดยไม่ต้องนอนหลับ ฉันประหลาดใจที่เคยรวบรวมวิ่งน้อยมาก