วัด latency / jitter / packet-way ทางเดียว


10

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

มีวิธีที่จะจำกัดความผิดหลังจากที่ไปข้างหน้าและย้อนกลับmtrไม่สามารถระบุผู้กระทำผิดที่แน่นอนและผู้ติดต่อ NOC @ ไม่ตอบสนองหรืออ้างว่าประสบกับการสูญเสียบนเส้นทางที่เป็นปัญหาหรือไม่? (ฉันใช้ OpenBSD)

ฉันได้ลองทำmtrโดยตรงกับลูกค้าบางส่วนของทั้งสองเครือข่ายที่อาจประสบปัญหาความแออัด แต่ไม่พบปัญหาใด ๆ ที่เกิดขึ้นโดยเฉพาะอย่างยิ่งเช่น he.net มีป๊อปจำนวนมากและบ่อยครั้ง เส้นทางที่แตกต่างกันจะถูกนำมาระหว่างรายการที่กำหนดและออกจาก POP ดังนั้นเมื่อฉันลองไปยังmtrโฮสต์ของพวกเขา (เช่น tserv) โดยตรงที่ทางออก POP ซึ่งฉันอาจจะสูญเสียแพ็กเก็ตในเครือข่ายของพวกเขาเส้นทาง he.net ที่แตกต่างกัน POP เดียวกันและไม่มีการสูญเสียแพ็กเก็ตเกิดขึ้นซึ่งไม่ได้พิสูจน์สิ่งที่น่าสนใจ (นอกเหนือจากข้อเสนอแนะที่เป็นไปได้ว่าพวกเขาอาจเกินเส้นทางบางเส้นทางในขณะที่ทำให้แน่ใจว่าคนอื่น ๆ ไม่ได้หลงลืมโดยไม่สนใจคำขอ NOC @ จากลูกค้า


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

คำตอบ:


9

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

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

หากคุณควบคุมปลายทั้งสองต้องแน่ใจว่าคุณกำลังซิงโครไนซ์ NTP กับเซิร์ฟเวอร์เพียง 1 เครื่องและเซิร์ฟเวอร์เดียวกัน นาฬิกาแบบสัมบูรณ์ไม่สำคัญมากมันเป็นสิ่งสำคัญที่คุณต้องมีประสบการณ์ใกล้เคียงกันมากที่สุด

ถ้าการประทับเวลาของ ICMP ไม่เพียงพอคุณสามารถเขียน ruby ​​/ perl / python หรือ 10 บรรทัดเพื่อวัดค่าเมื่อคุณควบคุมปลายทั้งสอง

ฉันไม่สามารถแนะนำซอฟต์แวร์สำหรับทำการวัดเวลาของ ICMP ได้ทางเดียว, hping2 รองรับการส่งเวลา ICMP แต่ด้วยเหตุผลบางอย่างไม่ได้ส่งออกค่าทิศทางเดียว ฉันเขียนpatchสำหรับ hping2 เพื่อแสดง latencies ทางเดียว


ว้าวhping --icmp-tsเลขคณิตพิเศษของคุณช่างน่ากลัวมาก! ขี้เกียจเกินไปที่จะรับแหล่งที่มาและคอมไพล์ไบนารีฉันได้รับรุ่นเชลล์ของแพทช์ hping ของคุณ ( stackoverflow.com/q/20172028/1122270 ) และมันแสดงเวลาคงที่ค่อนข้างมากในเส้นทาง init7 ไปยัง hetzner และ ความแปรปรวนแบบ all-over-the-map พร้อมเส้นทาง he.net จาก hetzner! ในที่สุดฉันก็มีหลักฐานที่ชัดเจนว่า init7 กำลังบอกความจริง! แม้ว่าฉันจะเถียงกับการใช้เซิร์ฟเวอร์ ntp เดียวกันสำหรับสิ่งนี้: เพียงให้แน่ใจว่า ntpd ยังมีชีวิตอยู่ (ฉันไม่ต้องเปลี่ยนการตั้งค่าใด ๆ เลย แต่ค่าดูสมเหตุสมผล)
cnst

1
หากคุณใส่ใจเวลาที่ถูกต้องคุณจะต้องมีเซิร์ฟเวอร์ NTP อย่างน้อย 3 เครื่อง (เพื่อให้สามารถตรวจจับสัญลักษณ์ที่ผิดเซิร์ฟเวอร์ NTP 2 ตัวเป็นตัวเลือกที่แย่ที่สุดที่คุณสามารถทำได้) แต่ที่นี่เราไม่สนใจเวลาที่อยู่บนผนังเราใส่ใจกับการเลือกนาฬิกาอย่างถูกต้องในเวลาเดียวกันโดยไม่คำนึงถึงผนัง ดังนั้นสำหรับการวัดแบบทางเดียวผลลัพธ์ที่ดีที่สุดมาจากนาฬิกาที่เที่ยงตรงเวลาในการแขวนผนังที่ไม่เกี่ยวข้อง ดีใจที่ได้ยินว่าคุณได้ผลลัพธ์!
ytti
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.