ต่อสู้เพื่อมิลลิวินาที วิธีเลือกเซิร์ฟเวอร์ที่มีค่า ping ต่ำที่สุด

สำหรับงานหลายๆ อย่าง ความล่าช้าระหว่างไคลเอนต์และเซิร์ฟเวอร์ถือเป็นสิ่งสำคัญ เช่น ในเกมออนไลน์ การประชุมทางวิดีโอ/เสียง ระบบโทรศัพท์ IP VPN เป็นต้น หากเซิร์ฟเวอร์อยู่ไกลจากไคลเอนต์มากเกินไปในระดับเครือข่าย IP ความล่าช้า (ที่นิยมเรียกว่า "ping", "lag") จะรบกวนการทำงาน

ความใกล้ชิดทางภูมิศาสตร์ของเซิร์ฟเวอร์ไม่เท่ากันที่ระดับการกำหนดเส้นทาง IP เสมอไป ตัวอย่างเช่น เซิร์ฟเวอร์ในประเทศอื่นอาจ "ใกล้" กับคุณมากกว่าเซิร์ฟเวอร์ในเมืองของคุณ ทั้งหมดนี้เนื่องมาจากลักษณะเฉพาะของการกำหนดเส้นทางและการสร้างเครือข่าย

จะเลือกเซิร์ฟเวอร์ที่ใกล้เคียงกับลูกค้าเป้าหมายมากที่สุดได้อย่างไร? การเชื่อมต่อเครือข่าย IP คืออะไร? จะนำไคลเอนต์ไปยังเซิร์ฟเวอร์ที่ใกล้ที่สุดได้อย่างไร? มาดูกันในบทความ

การวัดความล่าช้า

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

ICMP - ปิงปกติ

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

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

ช่วงเวลาระหว่างแพ็กเก็ต (ตัวเลือก -i) — เวลาระหว่างการส่งข้อมูล ตามค่าเริ่มต้น แพ็กเก็ตจะถูกส่งหนึ่งครั้งต่อวินาที ซึ่งเป็นเวลานานมาก โปรแกรมจริงส่งแพ็กเก็ตนับร้อยนับพันต่อวินาที ดังนั้นเราจะตั้งค่าช่วงเวลาเป็น 0.1 วินาที โปรแกรมก็ไม่อนุญาตน้อยลง

เป็นผลให้คำสั่งมีลักษณะดังนี้:

ping -s 1300 -i 0.1 yandex.ru

การออกแบบนี้ช่วยให้คุณเห็นภาพความล่าช้าที่สมจริงยิ่งขึ้น

ปิงผ่าน UDP และ TCP

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

คุณประโยชน์ ปิง จากผู้พัฒนาสแกนเนอร์ชื่อดัง nmap สามารถสร้างแพ็กเก็ตใดก็ได้ นอกจากนี้ยังสามารถใช้เพื่อวัดความล่าช้าได้
เนื่องจาก UDP และ TCP ทำงานบนพอร์ตเฉพาะ เราจึงต้อง "ping" พอร์ตเฉพาะ ลอง ping TCP 80 นั่นคือพอร์ตเว็บเซิร์ฟเวอร์:

$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com

Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44  seq=2876862274 win=64240 <mss 1398>

Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds

ตามค่าเริ่มต้น nping จะส่ง 4 แพ็กเก็ตและหยุด ตัวเลือก -ค 0 เปิดใช้งานการส่งแพ็กเก็ตอย่างไม่มีที่สิ้นสุด หากต้องการหยุดโปรแกรม คุณต้องกด Ctrl+C สถิติจะแสดงในตอนท้าย เราจะเห็นว่าค่า rtt (เวลาไปกลับ) เฉลี่ยอยู่ที่ 101ms

MTR - Traceroute บนสเตียรอยด์

โครงการ MTR My Traceroute เป็นยูทิลิตี้ขั้นสูงสำหรับการติดตามเส้นทางไปยังโฮสต์ระยะไกล ไม่เหมือนกับ Traceroute ยูทิลิตี้ระบบทั่วไป (ใน Windows นี่คือยูทิลิตี้ Tracert) มันสามารถแสดงความล่าช้าให้กับแต่ละโฮสต์ในแพ็กเก็ตเชน นอกจากนี้ยังสามารถติดตามเส้นทางไม่เพียงแต่ผ่าน ICMP แต่ยังผ่าน UDP และ TCP อีกด้วย

$ sudo mtr microsoft.com

(คลิกได้) อินเทอร์เฟซโปรแกรม MTR การติดตามเส้นทางไปยัง microsoft.com เริ่มต้นแล้ว

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

WiFi และสายเคเบิล

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

นี่คือการทดสอบด้วยภาพเพื่อเปรียบเทียบการเชื่อมต่อ WiFi และสายเคเบิล นี่คือการ ping ไปยังเราเตอร์ WiFi ซึ่งก็คือไม่ใช่แม้แต่อินเทอร์เน็ต

(คลิกได้) การเปรียบเทียบการ ping กับเราเตอร์ WiFi ผ่านสายเคเบิลและผ่าน WiFi

จะเห็นได้ว่าเมื่อใช้ WiFi ความล่าช้าจะนานกว่า 1ms และบางครั้งก็มีแพ็กเก็ตที่มีความล่าช้านานกว่าสิบเท่า! และนี่เป็นเพียงช่วงเวลาสั้นๆ เท่านั้น ในเวลาเดียวกัน เราเตอร์ตัวเดียวกันทำให้เกิดความล่าช้าที่เสถียร <1ms

ในตัวอย่างข้างต้น มีการใช้ WiFi 802.11n ที่ 2.4GHz โดยมีเพียงแล็ปท็อปและโทรศัพท์เท่านั้นที่เชื่อมต่อกับจุดเข้าใช้งาน WiFi หากมีไคลเอ็นต์บนจุดเข้าใช้งานมากขึ้น ผลลัพธ์ที่ได้จะแย่ลงมาก นี่คือสาเหตุที่ฉันไม่เปลี่ยนคอมพิวเตอร์ในสำนักงานทุกเครื่องเป็น WiFi หากสามารถเข้าถึงด้วยสายเคเบิลได้

การเชื่อมต่อไอพี

ดังนั้นเราจึงได้เรียนรู้ที่จะวัดความล่าช้าของเซิร์ฟเวอร์ เรามาลองค้นหาเซิร์ฟเวอร์ที่ใกล้ที่สุดกับเรากันดีกว่า ในการดำเนินการนี้ เราสามารถดูว่าการกำหนดเส้นทางของผู้ให้บริการของเราทำงานอย่างไร สะดวกในการใช้บริการนี้ บีจีพี.เฮ.เน็ต

เมื่อเราเข้าถึงไซต์ เราจะเห็นว่าที่อยู่ IP ของเราเป็นของระบบอัตโนมัติ AS42610.

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

กราฟการเชื่อมต่อของระบบอัตโนมัติของผู้ให้บริการ

การใช้เครื่องมือนี้ทำให้คุณสามารถศึกษาว่าช่องทางของผู้ให้บริการ รวมถึงโฮสติ้ง มีโครงสร้างอย่างไร ดูว่าผู้ให้บริการรายใดที่เชื่อมต่อโดยตรงกับ ในการดำเนินการนี้ คุณจะต้องป้อนที่อยู่ IP ของเซิร์ฟเวอร์ในการค้นหา bgp.he.net และดูกราฟของระบบอัตโนมัติ คุณยังสามารถเข้าใจได้ว่าศูนย์ข้อมูลหรือผู้ให้บริการโฮสติ้งรายหนึ่งเชื่อมต่อกับอีกรายหนึ่งได้อย่างไร

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

ตัวอย่างเช่นที่นี่ กระจกมอง จากเอ็มจีทีเอส

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

เลือกเซิร์ฟเวอร์ที่ใกล้ที่สุด

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

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

ที่มา: will.com