เวลา ping ที่รายงานนานหนึ่งชั่วโมงบนโลกจะเป็นจริงได้อย่างไร?


15

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

ฉันสังเกตเห็นว่าเราเตอร์ของพวกเขากำลังpptpจับมือกันซ้ำ ๆและเจรจาใหม่ฆ่าการเชื่อมต่ออย่างมีประสิทธิภาพ สิ่งนี้น่าผิดหวัง ดังนั้นในความพยายามที่จะหลีกเลี่ยงการเสียสติฉันจึงบอกให้เพิ่มระยะห่าง SNR ขั้นต่ำที่ยอมรับได้สองเท่าและจับมือเพื่อลดความเร็ว:

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
U.S. Robotics Wireless MAXg ADSL Gateway
Login: ***********
Password: 
> sh


BusyBox v1.00 (2006.02.17-20:30+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

# adsl configure --snr 200; exit 
Connection closed by foreign host.

เรื่องนี้ดีขึ้นและสิ่งที่มีเสถียรภาพ (ค่อนข้าง) ถ้าช้าไปป์อย่างไม่น่าเชื่อไปยังโลกภายนอก:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=3236.679 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=3699.541 ms
...

เมื่อถึงจุดนี้ชีวิตจริงก็เข้าแทรกแซงและฉันก็ใช้เวลาหลายชั่วโมงในการเล่นกับแมวมองแมว gif บนโทรศัพท์ของฉัน จริง ๆ แล้วพูดคุยกับครอบครัวของฉันฯลฯ ฉันลืมไปว่าฉันออกจากกระบวนการ ping นี้แล้วกลับมา ctrl-cวันต่อมาจะตี

สถิติสรุปที่แสดงให้ฉันเห็น:

--- 8.8.8.8 ping statistics ---
103074 packets transmitted, 100564 packets received, 2.4% packet loss
round-trip min/avg/max/stddev = 32.986/3034.479/3600577.732/87527.276 ms

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

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

ในที่สุดฉันก็สนใจที่จะทราบว่ามีจรรยาบรรณในสหราชอาณาจักรระบุว่าการเชื่อมต่อ ADSL ของผู้บริโภคคาดว่าจะมีความหน่วงน้อยและการจัดการจราจรที่ดีกว่าโดยRFC 1149และRFC 2549 ;-)


1
เราเตอร์ที่ไม่ได้รับสแปมมากเกินไป
วงล้อประหลาด

เราเตอร์โลภ;) เพียงแค่ต้องเล่นสิ่งนี้เมื่อคุณสังเกตเห็นว่ากำลังวางแผนที่จะรอหนึ่งชั่วโมงก่อนที่จะส่งต่อแพ็คเก็ต youtube.com/watch?v=moSFlvxnbgk
Cestarian

1
เป็นไปได้หรือไม่ที่คุณบอกว่าคุณทิ้งไว้ค้างคืนคอมพิวเตอร์ของคุณจะใช้เวลา +1 ชั่วโมงเมื่อเริ่มต้น Daylight Daylight และยุ่งกับการคำนวณ RTT ของแพ็คเก็ตที่เฉพาะเจาะจงหรือไม่
kenkh

@kenkh - ไม่; ฉันแน่ใจว่าวันที่นาฬิกาเปลี่ยนไปไม่ใช่วันนั้นแน่นอน นอกจากนี้การดูping ซอร์สโค้ด (จาก ~ l 761) ฉันสามารถเห็นว่าเขตเวลาถูกละเว้นในการคำนวณครั้งถัดไป ( gettimeofday(nv, NULL)ส่งคืนไมโครวินาทีตอน) มันใช้เวลาหนึ่งชั่วโมงจริง ๆ !
Landak

หากคุณมีการเข้าถึงระบบคุณสามารถเรียกใช้การค้นพบด้วยหรือไม่ จะแสดงให้เห็นอย่างคร่าวๆว่าการชะลอตัวอยู่ที่ใด
Journeyman Geek

คำตอบ:


4

แพ็คเก็ต ICMP และการตอบสนองสำหรับ ping มีความยาว 32 ไบต์ดังนั้นจึงดูเหมือนว่าจะมีการ ping ยาวชั่วโมงที่ทุกไบต์ใช้เวลาเกือบหนึ่งนาทีในการส่ง

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

Internet Protocol (IP) ส่งข้อมูลด้วยดาตาแกรมและพยายามไม่ส่งข้อมูลบางส่วน เมื่อเริ่มส่งสัญญาณระบบจะรอตามค่าเริ่มต้นเป็น 200 มิลลิวินาทีเพื่อให้มีการเพิ่มไบต์เพิ่มในดาตาแกรม ในช่วงเวลานั้นซอฟต์แวร์ / เฟิร์มแวร์จะส่งสิ่งใดก็ตามที่มีเป็นดาตาแกรมเดียว ในกรณีที่เวลา ping นานชั่วโมงแพ็กเก็ตแพ็กเก็ตอาจมีขนาดเล็กเท่ากับหนึ่งไบต์ ตราบใดที่ข้อมูลยังมาถึงการเชื่อมต่อจะไม่ถูกยกเลิกโดยทั้งสองฝ่ายที่เข้าร่วม

คุณสามารถทำอะไรได้บ้าง :

  • หากโทรศัพท์แฟกซ์หรืออุปกรณ์อื่นเชื่อมต่ออยู่กับสายโทรศัพท์เดียวกันให้ตรวจสอบว่าได้รับการคุ้มครองโดยตัวกรองสัญญาณ DSLหรือไม่ ตรวจสอบให้แน่ใจว่าคุณไม่ได้ใส่ตัวกรองในบรรทัดที่ไปยังโมเด็ม DSL ของคุณ
  • ลองใช้เราเตอร์ตัวอื่น - เมื่อคุณมีอุปกรณ์ที่ไม่ดีด้วยตัวเองแล้วคุณจะไม่ทำอะไรเลยนอกจากโยนมันออกไป
  • หากไม่มีเราเตอร์อื่นให้ติดต่อคุณ ISP - พวกเขาสามารถเรียกใช้การทดสอบที่มีประโยชน์จากด้านข้างของพวกเขา
  • หาก ISP ไม่พบอะไรให้ลองขอเราเตอร์ / โมเด็มแทน
  • หากปัญหาเดียวกันนี้เกิดขึ้นกับเราเตอร์อื่นให้ติดต่อ บริษัท โทรศัพท์

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


ฉันจะเลี้ยว 2 และ 3 รอบ การโทรหา ISP นั้นง่ายกว่ามาก พวกเขาสามารถทำการทดสอบ หากพวกเขาพบปัญหาพวกเขาจะส่งโมเด็มใหม่ (ไม่จำเป็นต้องเป็นเราเตอร์) หากโมเด็มใหม่ไม่สามารถแก้ปัญหาได้ ISP ควรติดต่อ บริษัท โทรศัพท์ นั่นเป็นวิธีการทำงานที่นี่ แต่มันอาจแตกต่างกันในสหราชอาณาจักร
SPRBRN

ฉันหมายถึงว่าควรดำเนินการหลาย ๆ จุดบนขนานกันมากที่สุด ในกรณีของฉัน ISP ของฉันสามารถตัดสินใจที่จะส่งช่างเทคนิค แต่หากปัญหานั้นสำคัญเหมือนตัวกรองสัญญาณ DSL ที่ไม่ได้ใช้งานก็อาจตัดสินใจคิดค่าธรรมเนียม
harrymc

ฮึ. ความคิดเห็นหมายถึงตัวเลขในรายการลำดับเลข จากนั้นผู้โพสต์ของคำตอบแก้ไขคำตอบเพื่อลบตัวเลขจึงทำให้ความคิดเห็นดูออกไป Tsk tsk
TOOGAM

1
200 ms : สิ่งนี้มีอยู่ในซอฟต์แวร์ Windows / Linux ฉันพบเมื่อวิเคราะห์ว่าทำไมผลิตภัณฑ์ของ บริษัท ของฉันมีปริมาณการรับส่งข้อมูล TCP / IP ต่ำเกินไปในดาตาแกรมขนาดเล็กจากนั้นจึงพบการเรียกระบบที่ "ส่งทันที" บนซ็อกเก็ต แพ็คเก็ตแพ็คเก็ต : นี่คือการเจรจาไม่ได้ แต่ดาตาแกรม TCP / IP ที่มีขนาดใหญ่เกินไปจะถูกตัดออกเป็นส่วน ๆ เมื่อพบทางเดินที่MTUมีขนาดเล็กเกินไป โมเด็ม DSL : ความเป็นไปได้ที่การเปลี่ยนแปลงพารามิเตอร์จะชดเชยค่าโทรศัพท์ / สวิตช์ที่ไม่ดี แต่ควรได้รับการแก้ไขแทนที่จะชดเชย
harrymc

1
ปรับแต่งอีก: ปิดการใช้งาน ADSL2 + และอยู่กับ ADSL1 เพื่อความมั่นคง ไม่ว่าคุณจะซื้อเราเตอร์แบบใดคุณสามารถปรับแต่งระยะขอบ SNR ได้อย่างถูกต้อง (ข้อมูลบางอย่างที่นี่ ) เราเตอร์พันล้านนั้นดีเหมือน Netgear (ฉันชอบรุ่นที่รองรับ DD-WRT ด้วยการติดตั้งง่าย) นี้บทความสามารถให้คุณมีความคิดอื่น ๆ - และมีลักษณะที่ระยะทาง / ความเร็วแผนภาพที่
harrymc

0

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

ดังนั้นการรวมกันของการมีนโยบายการจัดการความแออัดที่ไม่ดีกับการเปิดเซสชัน ping เป็นเวลาหลายชั่วโมงอาจส่งผลให้เกิดสถานการณ์แปลก ๆ

ข้อมูลเพิ่มเติมเกี่ยวกับการจัดการความแออัดของที่นี่

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