8 บิตนั้นเพียงพอสำหรับ TTL ในส่วนหัวของ IP อย่างไร


18

TTL (Time to Live) เป็นฟิลด์ 8 บิตในส่วนหัวของ IPv4 มันสามารถรับค่าใด ๆ จาก 0 ถึง 255 หากนี่หมายความว่าแพ็คเก็ตสามารถใช้สูงสุด 255 ฮ็อป (เราเตอร์) เพื่อไปยังปลายทางของมันแพ็คเก็ตจะถูกทิ้ง

ฉันจะส่งแพ็กเก็ตข้ามทวีปได้อย่างไร


14
เหตุผลเดียวกับที่tracerouteเครื่องมือส่วนใหญ่ยอมแพ้หลังจาก 30 ฮ็อป - "เส้นผ่าศูนย์กลางของอินเทอร์เน็ต" นั้นไม่ใหญ่เท่าที่คุณคิด
user1686

4
ลองคิดดูสิว่าจะนำข้อมูลของคุณไปไว้บนเครื่องบินเพื่อเดินทาง สำหรับการกระโดดในท้องถิ่นให้เช่าเครื่องบินเบา สำหรับการกระโดดข้ามชาติครั้งใหญ่คุณจะขึ้นเครื่องบิน 777 หรือ A380 ที่ใกล้ที่สุดแล้วกระโดดให้ใหญ่ แทนที่จะเป็นเที่ยวบินระหว่างประเทศข้อมูลเดินทางจากยุโรปไปยังสหรัฐอเมริกา (หรือที่อื่น ๆ ) โดยใช้หนึ่งในสิ่งเหล่านี้: en.wikipedia.org/wiki/Transatlantic_communications_cable
Baldrickk

2
ทฤษฎี "การแยกแบบหกองศา" อาจสนใจคุณเช่นกัน
Pam

1
ฉันแนะนำให้คุณพิจารณาข้อเสนอแนะของ Pam อย่างจริงจัง ปรากฎว่าในระบบที่เกิดขึ้นตามธรรมชาติ (ระบบที่ไม่ได้วางแผนไว้) เช่นผู้คนสร้างเพื่อนโหนดที่ถูกเพิ่มเข้ามาในอินเทอร์เน็ต บริษัท ที่ทำธุรกิจเป็นต้นซึ่งการเชื่อมต่อส่วนใหญ่ไม่จำเป็นต้องใช้ฮ็อปมากมาย สำหรับปฏิสัมพันธ์ของมนุษย์ที่มีจำนวนไม่เกิน 6 ใช้ตัวอย่าง oracleofbacon.org ซึ่งคำนวณการเชื่อมต่อของนักแสดงเควินเบคอนกับนักแสดงคนอื่น ๆ ระยะทางระหว่างเบคอนและนักแสดงเตลูกู Ravi Teja เป็นเพียงภาพยนตร์ 3 เรื่อง Saloma นักแสดงหญิงชาวมลายูยุค 60 ยังมีภาพยนตร์เพียง 3 เรื่องระหว่างเธอกับเควินเบคอน
ลอบสังหาร

คำตอบใดช่วยคุณได้บ้าง ถ้าเป็นเช่นนั้นคุณควรยอมรับคำตอบเพื่อที่คำถามจะไม่โผล่ขึ้นมาเรื่อย ๆ โดยมองหาคำตอบ หรือคุณสามารถให้และยอมรับคำตอบของคุณเอง
Ron Maupin

คำตอบ:


27

แม้ว่าจะส่งแพ็กเก็ตข้ามทวีป TTL ที่ 255 ก็เพียงพอแล้ว - เราเตอร์ไม่ได้เกี่ยวข้องอะไรมาก

การทดสอบอย่างรวดเร็ว (จากเยอรมนี) แสดงให้เห็นว่ากระโดด 17 ครั้งไปยังสหรัฐอเมริกาและ 18 ถึงญี่ปุ่น โดยปกติคุณจะไม่ได้สูงกว่า 30 หรือมากกว่านั้น นี่เป็นเพราะโครงสร้างลำดับชั้นของอินเทอร์เน็ต - คุณกดแบ็คโบน ISP ของคุณด้วย 2-5 ฮ็อพอีก 2-3 ฮ็อปพาคุณไปยังผู้ให้บริการรายต่อไปเป็นต้น

โปรดทราบว่า TTL นับ layer-3 hops เท่านั้น เลเยอร์ 2 ที่ใช้บ่อยมากขึ้นข้ามสวิตช์ไม่ได้ส่งผลกระทบต่อ TTL - ไม่มีแนวคิดดังกล่าวในอีเธอร์เน็ตหรือโปรโตคอลที่คล้ายกัน

นอกจากนี้การห่อหุ้มแพ็กเก็ตสำหรับการขนส่งในอุโมงค์ 'หยุด' TTL ในขณะที่อยู่ในอุโมงค์ - ไม่ว่าจะมีแพ็คเก็ตด้านนอกใช้กี่แพ็ค (มันมี TTL ของตัวเอง) อุโมงค์ทั้งหมดจะนับเป็นหนึ่งหรือสอง


9

นอกเหนือจากคำตอบอื่น ๆ ที่จะทำให้เสร็จสมบูรณ์มากขึ้น: แม้ว่าเราเตอร์หลายคนดูเหมือนจะส่งแพ็กเก็ตที่มี TTL 255 (สำหรับแพ็คเก็ตที่พวกเขาสร้างขึ้นเองแน่นอนไม่ใช่พวกเขาไปข้างหน้า!) ระบบปฏิบัติการส่วนใหญ่ส่งแพ็กเก็ต ค่า TTL เริ่มต้นที่ต่ำกว่า:

  • Windows ใช้128 (ตั้งแต่ Windows NT 4)
  • ทั้ง MacOS X และ Linux ใช้64

บางระบบใช้ในการส่งค่าที่ต่ำกว่า (เช่น Windows 95 มีค่าเริ่มต้นเป็น 32) ค่าเหล่านั้นถูกยกขึ้นเพื่อป้องกันปัญหาเกี่ยวกับเส้นทางที่อาจนานกว่านี้ ... แต่ระบบเหล่านั้นสามารถเข้าถึงโฮสต์เกือบทั้งหมดบนอินเทอร์เน็ตได้ และ - ถึงกระนั้นฉันก็ยังไม่มีข้อพิสูจน์ใด ๆ เกี่ยวกับเรื่องนี้ - ฉันบอกได้ว่าจำนวนของฮ็อพที่ต้องการลดลงเนื่องจากมีการติดตั้งเส้นใยทางไกลมากขึ้นเพื่อรองรับการจราจร

อย่าลืมว่าจำนวนกระโดดและระยะทางภูมิศาสตร์นั้นไม่มีความสัมพันธ์กัน โดยทั่วไปแล้วมหาสมุทรจะมีการกระโดดเพียงครั้งเดียว (ขาประจำออปติคอลตามเส้นใยของเรือดำน้ำไม่ได้สัมผัสกับแพ็คเก็ตเท่านั้นเราเตอร์เท่านั้นที่จะลด TTL) เพิ่ง traceroute จากสวิตเซอร์แลนด์ไปนิวซีแลนด์: hop # 7 อยู่ห่างจากที่ฉันไม่ถึง 50 กม., # 9 อยู่ในแคลิฟอร์เนียและ # 10 อยู่ในนิวซีแลนด์ ... ส่วนการขนส่งข้ามทวีปโดยทั่วไปจะมีเพียงไม่กี่ฮ็อป ในเส้นทางส่วนที่เหลือส่วนใหญ่ไปถึงผู้ให้บริการระหว่างประเทศและมาถึงปลายทางจากมัน


8

8 บิตเกินพอ เนื่องจากการส่งข้อความแบบ ISP คุณสามารถเข้าถึงปลายทางได้โดยการเดินทางผ่าน ISP น้อยกว่า 5 หรือ 6 ตัวและเนื่องจากสถาปัตยกรรมเครือข่ายแกนหลักชุดข้อมูลจะถ่ายโอนผ่านเราเตอร์สูงสุด 3 หรือ 4 ตัวในหนึ่ง ISP เท่านั้น

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


สำหรับปลายทางที่ไม่ได้กำหนดเส้นทางเป็นเรื่องปกติหรือไม่ที่จะติดตั้งเส้นทางปฏิเสธเพื่อป้องกันสิ่งนี้
user1686

7
ปัญหาไม่ใช่จุดหมายปลายทางที่ไม่ได้กำหนดเส้นทางปัญหาคือปลายทางที่เกิดจากการกำหนดค่าผิดพลาดหรือเอฟเฟกต์ชั่วคราวมีการวนรอบเส้นทาง
ปีเตอร์กรีน

3

บันทึกจากแผนกประวัติ: หน่วยของ TTL คือวินาทีโดยที่งบประมาณเวลาที่อนุญาตลดลงหนึ่งวินาทีสำหรับเราเตอร์ทุกคน

จาก Internet Protocol RFC 791:

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

แพ็คเก็ตหลายวินาทีไม่ผิดปกติ: ดาตาแกรม IP ที่น้อยที่สุดที่อนุญาต 68 octets ใช้เวลามากกว่า 2 วินาทีที่ 300 baud อย่างไรก็ตามฉันไม่เคยเห็นเราเตอร์ที่ลดลงมากกว่า 1 สำหรับแพ็คเก็ตแบบหลายวินาที

โลกวันนี้เร็วขึ้น

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