วิธีการวัดความหน่วงของเครือข่าย คู่มือปฏิบัติสำหรับนักพัฒนา
เรียนรู้วิธีการวัดความล่าช้าของเครือข่ายด้วยคู่มือที่ครอบคลุมนี้ เราจะพูดถึงเครื่องมือที่จำเป็น เช่น ping และ traceroute รวมถึงเทคนิคการทดสอบที่ใช้ในเบราว์เซอร์
ส่วนขยายที่แนะนำ
ต้องการวัดความหน่วงของเครือข่ายหรือไม่? คุณสามารถเริ่มต้นด้วยเครื่องมือบรรทัดคำสั่งที่ง่ายและมีอยู่แล้ว เช่น ping และ traceroute เพื่อให้ได้ข้อมูลเบื้องต้นเกี่ยวกับ Round-Trip Time (RTT) หรือคุณสามารถเปิดเครื่องมือพัฒนาของเบราว์เซอร์เพื่อดูว่าความล่าช้ากระทบต่อประสบการณ์ของผู้ใช้ของคุณอย่างไร
วิธีเหล่านี้ให้ภาพรวมที่รวดเร็วและมีประโยชน์เกี่ยวกับระยะเวลาที่ใช้ในการส่งข้อมูลจากแหล่งที่มาไปยังจุดหมายปลายทางและกลับมาอีกครั้ง
ทำไมการวัดความหน่วงจึงเป็นสิ่งที่ไม่สามารถเจรจาได้
ก่อนที่เราจะเข้าสู่ "วิธีการ" มาพูดถึง "ทำไม" กันก่อน สำหรับนักพัฒนาและวิศวกรเครือข่าย ความหน่วงไม่ใช่แค่ตัวเลขบนหน้าจอ; มันคือมือที่มองไม่เห็นที่กำหนดประสบการณ์ของผู้ใช้ทั้งหมด ในแอปพลิเคชันในปัจจุบัน มิลลิวินาทีคือทุกสิ่ง แม้แต่ความล่าช้าที่เล็กน้อยก็สามารถเป็นความแตกต่างระหว่างบริการที่รู้สึกทันทีและบริการที่รู้สึกขัดข้อง
ลองคิดถึงผลกระทบในโลกแห่งความเป็นจริง:
- การตอบสนองของ API: การเรียก API ที่ช้าเพียงครั้งเดียวสามารถสร้างผลกระทบแบบโดมิโน ทำให้ทุกอย่างตั้งแต่การโหลดโปรไฟล์ของผู้ใช้ไปจนถึงการประมวลผลการชำระเงินที่สำคัญหยุดชะงัก
- ข้อมูลสตรีมแบบเรียลไทม์: สำหรับการเล่นเกมออนไลน์ วิดีโอสด หรือการซื้อขายทางการเงิน ความหน่วงต่ำและสม่ำเสมอเป็นพื้นฐานที่สำคัญที่สุด หากไม่มีมัน แอปพลิเคชันเหล่านี้จะไม่ทำงาน
- การรักษาผู้ใช้: มีความสัมพันธ์โดยตรงระหว่างเว็บไซต์และแอปที่โหลดช้าไปยังอัตราการตีกลับที่สูงขึ้นและรถเข็นช็อปปิ้งที่ถูกทิ้งไว้ ข้อมูลเหล่านี้ส่งผลกระทบต่อผลกำไรอย่างมาก
การแยกแยะแนวคิดหลักเกี่ยวกับความหน่วง
เพื่อวัดความหน่วงของเครือข่ายอย่างแม่นยำ คุณต้องรู้ว่าคุณกำลังมองหาอะไร แนวคิดพื้นฐานสองประการคือ Round-Trip Time (RTT) และ ความหน่วงแบบทางเดียว
RTT คือระยะเวลาทั้งหมดที่ใช้ในการส่งสัญญาณจากจุด A ไปยังจุด B และกลับมาอีกครั้ง นี่คือเมตริกที่พบได้บ่อยที่สุดที่คุณจะเห็นเพราะมันวัดได้ง่าย—คุณเพียงแค่ต้องเข้าถึงปลายทางหนึ่งของการเชื่อมต่อ
ความหน่วงแบบทางเดียว ตามชื่อที่บอก มันวัดระยะเวลาที่ใช้ในการส่งข้อมูลในทิศทางเดียวเท่านั้น นี่เป็นการวัดที่ยากกว่ามากเพราะต้องการนาฬิกาที่ซิงโครไนซ์อย่างสมบูรณ์ที่ปลายทั้งสองด้าน อย่างไรก็ตาม มันเป็นตัวบ่งชี้ที่แม่นยำกว่าสำหรับการเชื่อมต่อที่ไม่สมมาตร ซึ่งเส้นทางการอัปโหลดและดาวน์โหลดมีพฤติกรรมที่แตกต่างกันอย่างมาก
ความสำคัญของทั้งหมดนี้จะชัดเจนเมื่อคุณกำลังทำ การทดสอบประสิทธิภาพโหลด อย่างจริงจัง ซึ่งเป็นที่ที่ทฤษฎีพบกับความเป็นจริงและจุดคอขวดถูกเปิดเผย
เพื่อให้มีตัวเลขที่ชัดเจน ผู้เชี่ยวชาญด้านการตรวจสอบเครือข่ายมักจัดประเภทความหน่วงดังนี้:
- ความหน่วงต่ำ: ต่ำกว่า 50 มิลลิวินาที
- ความหน่วงปานกลาง: 50-150 มิลลิวินาที
- ความหน่วงสูง: มากกว่า 150 มิลลิวินาที
จากประสบการณ์ของฉัน การทดสอบอย่างรวดเร็วไปยังเซิร์ฟเวอร์ใกล้เคียงอาจแสดงให้เห็นถึง 20-40 มิลลิวินาที ที่ยอมรับได้อย่างสมบูรณ์ แต่ตัวเลขนั้นสามารถเพิ่มขึ้นได้ง่ายๆ เป็นมากกว่า 200 มิลลิวินาที สำหรับการจราจรที่ต้องข้ามมหาสมุทร ซึ่งอาจเป็นตัวเปลี่ยนเกมสำหรับประสิทธิภาพของแอปพลิเคชันของคุณ
เพื่อให้เข้าใจศัพท์เฉพาะที่คุณจะพบ นี่คือการอ้างอิงอย่างรวดเร็ว
แนวคิดหลักเกี่ยวกับความหน่วงในภาพรวม
| แนวคิด | สิ่งที่มันวัด | ทำไมมันถึงสำคัญ |
|---|---|---|
| ความหน่วง (Ping) | ระยะเวลาที่ใช้ในการส่งข้อมูลแพ็กเก็ตเดียวจากแหล่งที่มาไปยังจุดหมายปลายทางและกลับมา วัดเป็นมิลลิวินาที (ms) | นี่คือการวัดความล่าช้าอย่างดิบ ความหน่วงต่ำเป็นสิ่งสำคัญสำหรับแอปพลิเคชันแบบเรียลไทม์ เช่น เกม VoIP และการประชุมวิดีโอ |
| Round-Trip Time (RTT) | โดยพื้นฐานแล้วเหมือนกับความหน่วง นี่คือระยะเวลาทั้งหมดที่ใช้ในการส่งสัญญาณบวกกับเวลาที่ใช้ในการรับการยืนยัน | RTT เป็นวิธีที่พบได้บ่อยและใช้งานได้จริงในการวัดความหน่วงจากจุดเดียว ทำให้เป็นเมตริกที่ใช้กันทั่วไปสำหรับเครื่องมืออย่าง ping |
| ความหน่วงแบบทางเดียว | ระยะเวลาที่ใช้ในการส่งแพ็กเก็ตจากแหล่งที่มาไปยังจุดหมายปลายทางในทิศทางเดียว | ให้มุมมองที่ละเอียดมากขึ้น โดยเฉพาะสำหรับเครือข่ายที่ไม่สมมาตรซึ่งเส้นทางการอัปโหลดและดาวน์โหลดมีความหน่วงที่แตกต่างกัน |
| Jitter | ความแปรปรวนของความหน่วงตามเวลา มันวัดความไม่สอดคล้องกันของเวลาที่แพ็กเก็ตมาถึง | Jitter ที่สูงก็ไม่ดีเท่ากับความหน่วงที่สูงสำหรับการสตรีมมีเดียและการโทรออนไลน์ ทำให้เกิดการกระตุก การบัฟเฟอร์ และความผิดพลาด |
| แบนด์วิธ | ปริมาณข้อมูลสูงสุดที่สามารถส่งผ่านการเชื่อมต่อเครือข่ายในระยะเวลาที่กำหนด วัดเป็น Mbps หรือ Gbps | มักจะถูกสับสนกับความเร็ว แบนด์วิธเกี่ยวกับความจุ คุณสามารถมีแบนด์วิธสูงแต่ยังประสบปัญหาความหน่วงสูงได้ |
แนวคิดเหล่านี้เป็นพื้นฐานสำหรับการเข้าใจปัญหาประสิทธิภาพเครือข่ายใดๆ
นี่คือจุดที่การมีเครื่องมือที่เข้าถึงได้และรวมเข้าด้วยกันมีความสำคัญมาก แทนที่จะต้องรันชุดการวินิจฉัยที่ซับซ้อน ส่วนขยายเบราว์เซอร์และเครื่องมือพัฒนาสมัยใหม่สามารถให้ข้อมูลเชิงลึกที่คุณต้องการโดยไม่ต้องออกจากการทำงานของคุณ มันเกี่ยวกับการทำให้การวัดความหน่วงเป็นส่วนหนึ่งที่ง่ายและเป็นกิจวัตรในการสร้างและบำรุงรักษาซอฟต์แวร์ที่ยอดเยี่ยม
ลงมือทำกับเครื่องมือวัดความหน่วงในบรรทัดคำสั่ง
เพื่อให้รู้สึกถึงประสิทธิภาพของเครือข่ายของคุณ คุณต้องเปิดเทอร์มินัล บรรทัดคำสั่งคือที่ที่คุณจะพบเครื่องมือพื้นฐานที่ให้ข้อมูลดิบที่ไม่กรองเกี่ยวกับการเชื่อมต่อของคุณ มันเกี่ยวกับการเห็นสิ่งที่ เกิดขึ้นจริง กับแพ็กเก็ตที่เคลื่อนที่ระหว่างคุณและจุดหมายปลายทาง และมันคือขั้นตอนแรกที่สำคัญสำหรับนักพัฒนาที่จริงจังเกี่ยวกับการวัดความหน่วง
ยูทิลิตี้ที่คลาสสิกและเป็นที่นิยมคือ ping มันเรียบง่ายอย่างสวยงาม: มันส่งแพ็กเก็ตข้อมูลขนาดเล็ก (ICMP echo request) ไปยังเซิร์ฟเวอร์และรอให้มันกลับมา การเดินทางรอบนี้เป็นพื้นฐานสำหรับการคำนวณ Round-Trip Time (RTT) และให้การตรวจสอบสุขภาพทันทีเกี่ยวกับการเชื่อมต่อ
การตรวจสอบความหน่วงครั้งแรกของคุณด้วย Ping
การรันการทดสอบ ping ง่ายมาก เพียงเปิดเทอร์มินัลหรือพรอมต์คำสั่ง พิมพ์ ping และตามด้วยโดเมนที่คุณต้องการทดสอบ
ตามค่าเริ่มต้น ping จะทำงานต่อไปตลอดไปใน macOS และ Linux ขณะที่ Windows จะส่งเพียงสี่แพ็กเก็ตแล้วหยุด สำหรับการวิเคราะห์ที่แท้จริง คุณจะต้องควบคุมสิ่งนี้ การส่งแพ็กเก็ตสิบหรือยี่สิบแพ็กเก็ตจะให้ภาพที่เชื่อถือได้มากขึ้นเกี่ยวกับความเสถียรของการเชื่อมต่อมากกว่าการส่งเพียงไม่กี่แพ็กเก็ต
เมื่อเสร็จสิ้น คุณจะได้รับสรุปที่เรียบร้อยพร้อมตัวเลขที่สำคัญ:
- แพ็กเก็ตที่ส่ง/รับ: นี่บอกคุณว่ามีข้อมูลใดสูญหายไปหรือไม่ แม้แต่การสูญเสียแพ็กเก็ตเล็กน้อยก็เป็นสัญญาณเตือนที่สำคัญสำหรับปัญหาเครือข่าย
- รอบการเดินทาง min/avg/max/mdev: นี่คือสถิติความหน่วงหลักของคุณ คุณจะได้รับเวลาที่ดีที่สุด (
min), ค่าเฉลี่ย (avg), และเวลาที่เลวร้ายที่สุด (max) ค่าmdev(ค่าเฉลี่ยเบี่ยงเบน) คือการวัด jitter ของคุณ—ความแปรปรวนของความหน่วงจากแพ็กเก็ตหนึ่งไปยังอีกแพ็กเก็ตหนึ่ง
ให้ความสนใจกับช่องว่างระหว่าง RTT ขั้นต่ำและสูงสุดของคุณ หากมันกว้าง การเชื่อมต่อของคุณไม่เสถียร แม้ว่าค่าเฉลี่ยจะดูดี Jitter นี้อาจทำให้แอปพลิเคชันเรียลไทม์ เช่น การโทรวิดีโอหรือการเล่นเกม เสียหายมากกว่าการเชื่อมต่อที่ช้าอย่างสม่ำเสมอ
ข้อผิดพลาดทั่วไปคือการมองเพียงค่าเฉลี่ย RTT ค่าเฉลี่ยที่ 50ms อาจดูดี แต่ถ้าค่าต่ำสุดของคุณคือ 20ms และค่าต่ำสุดคือ 250ms ประสบการณ์ของผู้ใช้จะรู้สึกกระตุกและไม่น่าเชื่อถือ ควรมองไปที่ช่วงทั้งหมดเพื่อเข้าใจ jitter
ติดตามเส้นทางด้วย Traceroute และ MTR
แล้วคุณจะทำอย่างไรเมื่อ ping แสดงความหน่วงสูงหรือการสูญเสียแพ็กเก็ต? งานถัดไปของคุณคือการหาว่า ปัญหาอยู่ที่ไหน นั่นคือสิ่งที่ traceroute (หรือ tracert บน Windows) ใช้เพื่อทำ มันแสดงเส้นทางทั้งหมดที่แพ็กเก็ตของคุณเดินทาง แสดงให้คุณเห็นทุก "hop"—เราเตอร์แต่ละตัว—ระหว่างเครื่องของคุณและจุดหมายปลายทางสุดท้าย
แต่ละบรรทัดในผลลัพธ์ของ traceroute คือ hop และมักจะแสดงการวัดความหน่วงสามรายการแยกกันไปยังจุดนั้น ซึ่งช่วยให้คุณระบุได้ว่าเราเตอร์เฉพาะที่อยู่ตามเส้นทางทำให้เกิดการชะลอตัวหรือทำให้แพ็กเก็ตสูญหาย
แต่ traceroute เป็นการถ่ายภาพแบบครั้งเดียว สำหรับการดูที่มีพลศาสตร์และต่อเนื่องมากขึ้น มืออาชีพด้านเครือข่ายส่วนใหญ่ที่ฉันรู้จักยืนยันว่า MTR (My Traceroute) เป็นเครื่องมือที่มีพลัง มันทำงานเหมือนเครื่องมือที่รวม ping และ traceroute เข้าด้วยกัน มันส่งแพ็กเก็ตไปยังทุก hop บนเส้นทางอย่างต่อเนื่อง ทำให้คุณเห็นภาพความหน่วงและการสูญเสียแพ็กเก็ตแบบสดๆ ที่ทุกจุด ซึ่งทำให้มันมีประสิทธิภาพอย่างมากในการจับปัญหาที่เกิดขึ้นเป็นระยะๆ ที่ traceroute เดียวอาจพลาดไป
ทำไมการเลือกเครื่องมือจึงสำคัญ
เครื่องมือที่คุณเลือกและวิธีการตั้งค่าของมันสามารถเปลี่ยนผลลัพธ์ของคุณได้อย่างมาก โดยเฉพาะในสภาพแวดล้อมที่มีความเร็วสูงและความหน่วงต่ำ เช่น ศูนย์ข้อมูลคลาวด์
มันน่าตกใจจริงๆ ว่าตัวเลขสามารถแตกต่างกันได้มาก ในการทดลองที่ละเอียดโดย Google Cloud การทดสอบ ping มาตรฐานรายงานค่าเฉลี่ย RTT ที่ 146 ไมโครวินาที แต่เมื่อพวกเขาใช้เครื่องมืออื่นที่ส่งธุรกรรมแบบต่อเนื่องโดยไม่มีการหยุดพัก RTT ลดลงเหลือเพียง 66.59 ไมโครวินาที—เร็วกว่าสองเท่า!
นี่คือตัวอย่างที่สมบูรณ์แบบว่าทำไม ping บางครั้งอาจประเมินความหน่วงสูงเกินไป มันแสดงให้เห็นว่าการเข้าใจ วิธีการ ที่เครื่องมือทำงานนั้นสำคัญต่อการได้รับการวัดที่คุณสามารถเชื่อถือได้
ค้นหาความเร็วสูงสุดของการเชื่อมต่อของคุณด้วย iperf
ความหน่วงไม่ใช่ภาพรวมทั้งหมดเสมอไป บางครั้งคุณต้องการทราบปริมาณข้อมูลสูงสุดที่การเชื่อมต่อของคุณสามารถส่งผ่านได้—แบนด์วิดธ์ของมัน สำหรับงานนั้น เครื่องมือที่คุณต้องการคือ iperf
ping วัดความล่าช้า iperf จะเน้นที่การส่งข้อมูล มันทำงานโดยการตั้งค่าการเชื่อมต่อแบบไคลเอนต์-เซิร์ฟเวอร์และจากนั้นส่งข้อมูลมากที่สุดเท่าที่จะทำได้ระหว่างกันในระยะเวลาที่กำหนด
ในการใช้ iperf คุณจะต้องมีเครื่องสองเครื่อง:
- ในเครื่องหนึ่ง คุณรัน
iperfใน โหมดเซิร์ฟเวอร์ มันจะนั่งอยู่ที่นั่นและรอการเชื่อมต่อ - ในเครื่องอีกเครื่องหนึ่ง คุณรัน
iperfใน โหมดไคลเอนต์ โดยชี้ไปที่ที่อยู่ของเซิร์ฟเวอร์
ไคลเอนต์จะเชื่อมต่อและการทดสอบจะเริ่มขึ้น ผลลัพธ์จะแจ้งให้คุณทราบถึงข้อมูลทั้งหมดที่ถูกส่งและที่สำคัญที่สุดคือ bitrate (แบนด์วิดธ์ของคุณ) ในเมกาบิตหรือกิกะบิตต่อวินาที นี่เป็นวิธีที่สมบูรณ์แบบในการทดสอบความเครียดของลิงก์เครือข่ายและค้นหาว่ามันสามารถทำอะไรได้จริงๆ
การวัดความหน่วงจากมุมมองของผู้ใช้
มันไม่เคยเกี่ยวกับการเดินทางรอบเดียวของแพ็กเก็ตเดียว ความหน่วงที่ผู้ใช้ รู้สึก เป็นค็อกเทลที่ซับซ้อนของการค้นหา DNS, การจับมือ TCP, การเจรจา TLS, เวลาการประมวลผลของเซิร์ฟเวอร์ และแน่นอน เวลาที่ใช้ในการแสดงเนื้อหาบนหน้าจอจริงๆ โชคดีที่เบราว์เซอร์สมัยใหม่มาพร้อมกับเครื่องมือในตัวที่ทรงพลังเพื่อช่วยให้เราวิเคราะห์กระบวนการทั้งหมดนี้
ดำน้ำสู่เครื่องมือพัฒนาเบราว์เซอร์
เบราว์เซอร์หลักทุกตัว—Chrome, Firefox, Edge, Safari—มาพร้อมกับชุดเครื่องมือพัฒนา แท็บ "เครือข่าย" ภายในเครื่องมือเหล่านี้คือศูนย์บัญชาการของคุณในการเข้าใจว่าเว็บไซต์ของคุณโหลดอย่างไร มันแสดงทุกอย่างในกราฟน้ำตก ซึ่งเป็นการแสดงภาพการแบ่งส่วนของคำขอแต่ละรายการที่เบราว์เซอร์ทำเพื่อแสดงหน้า
มุมมองน้ำตกนี้มีค่าอย่างยิ่ง คุณสามารถเห็นได้อย่างชัดเจนว่าแต่ละทรัพยากรใช้เวลานานเท่าใดในการดาวน์โหลด ตั้งแต่เอกสาร HTML เริ่มต้นและสไตล์ CSS ไปจนถึงภาพและการเรียก API ที่สำคัญกว่านั้น มันจะแบ่งวงจรชีวิตของแต่ละคำขอออกเป็นขั้นตอนที่ชัดเจน:
- การค้นหา DNS: เวลาที่ใช้ในการแปลงชื่อโดเมนเป็นที่อยู่ IP
- การเชื่อมต่อเริ่มต้น: เวลาที่ใช้ในการสร้าง การเชื่อมต่อ TCP กับเซิร์ฟเวอร์
- การจับมือ SSL/TLS: ค่าใช้จ่ายที่จำเป็นในการตั้งค่าการเชื่อมต่อที่ปลอดภัย
- เวลาถึงไบต์แรก (TTFB): นี่คือสิ่งที่สำคัญมาก มันวัดระยะเวลาที่เบราว์เซอร์รอคอยก่อนที่จะได้รับ ไบต์แรก ของข้อมูลจากเซิร์ฟเวอร์
- การดาวน์โหลดเนื้อหา: เวลาที่ใช้ในการดาวน์โหลดทรัพยากรจริงๆ
TTFB ที่สูง เช่น เป็นสัญญาณคลาสสิกของปัญหาด้านการประมวลผลเซิร์ฟเวอร์หรือแบ็กเอนด์ที่ช้า—สิ่งที่การทดสอบ ping ง่ายๆ จะไม่สามารถค้นพบได้ โดยการวิเคราะห์น้ำตกนี้ คุณสามารถระบุได้อย่างรวดเร็วว่าทรัพยากรใดที่ขัดขวางการแสดงผลหรือใช้เวลานานเกินไปในการโหลด
ข้อคิดสำคัญจากประสบการณ์ของฉันคือไม่เพียงแค่ดูเวลาการโหลดทั้งหมด แต่ต้องค้นหาบาร์ที่ยาวที่สุดในน้ำตก ภาพที่ไม่ได้ปรับให้เหมาะสมเพียงภาพเดียวหรือ API ของบุคคลที่สามที่ช้าสามารถทำให้ทั้งหน้าไม่สามารถโหลดได้ สร้างประสบการณ์ผู้ใช้ที่ไม่ดีแม้ว่าส่วนที่เหลือของเว็บไซต์จะเร็วเหมือนสายฟ้า
การวัดเชิงโปรแกรมด้วย Timing APIs
สำหรับการวัดที่เป็นอัตโนมัติและแม่นยำมากขึ้น คุณสามารถใช้ JavaScript APIs ที่มีอยู่ในเบราว์เซอร์ Navigation Timing API และ Resource Timing API ให้การเข้าถึงโปรแกรมไปยังข้อมูลประสิทธิภาพที่ละเอียดเดียวกันที่คุณเห็นในเครื่องมือพัฒนา นี่เป็นวิธีที่สมบูรณ์แบบในการรวบรวมข้อมูลการตรวจสอบผู้ใช้จริง (RUM) เพื่อเข้าใจว่าเว็บไซต์ของคุณทำงานอย่างไรสำหรับผู้เข้าชมจริงทั่วโลก
คุณสามารถดึงข้อมูลเหล่านี้ได้ด้วยเพียงไม่กี่บรรทัดของ JavaScript ในคอนโซลเบราว์เซอร์ ตัวอย่างเช่น เพื่อรับเวลาประสิทธิภาพหลักสำหรับการโหลดหน้าหลัก คุณสามารถใช้ performance.getEntriesByType('navigation') ซึ่งจะส่งคืนวัตถุที่บรรจุด้วยข้อมูลเวลาที่มีค่า
จากข้อมูลนั้น คุณสามารถคำนวณเมตริกที่สำคัญ:
- เวลาการค้นหา DNS:
domainLookupEnd - domainLookupStart - เวลาการจับมือ TCP:
connectEnd - connectStart - เวลาถึงไบต์แรก (TTFB):
responseStart - requestStart - เวลาการโหลดหน้าทั้งหมด:
loadEventEnd - startTime
การปฏิบัติตามรายการตรวจสอบนี้จะช่วยให้คุณมั่นใจได้ว่าข้อมูลที่คุณรวบรวมมีความถูกต้องและมีประโยชน์จริง ๆ
โดยการทำอย่างมีระเบียบ คุณจะก้าวจากการวัดความล่าช้าไปสู่การเข้าใจมันอย่างแท้จริง วิธีการที่รอบคอบนี้คือสิ่งที่แยกความแตกต่างระหว่างตัวเลขสุ่มกับตัวชี้วัดประสิทธิภาพที่เชื่อถือได้
ทำความเข้าใจกับตัวเลข (และสิ่งที่ควรหลีกเลี่ยง)
ดีแล้ว คุณได้ทำการทดสอบและมีข้อมูลมากมาย นี่คือจุดที่งานจริงเริ่มต้น—การแปลตัวเลขดิบเหล่านั้นให้กลายเป็นสิ่งที่มีความหมาย ข้อมูลกำลังบอกเล่าเรื่องราวเกี่ยวกับสุขภาพของเครือข่ายของคุณ; คุณแค่ต้องเรียนรู้วิธีการอ่านมัน
ตัวอย่างเช่น การกระโดดขึ้นอย่างกะทันหันใน Round-Trip Time (RTT) บน traceroute เป็นเบาะแสคลาสสิก หากความล่าช้ากระโดดที่จุดเชื่อมต่อหมายเลขสามและยังคงสูงตลอดจนถึงจุดสิ้นสุด คุณอาจพบปัญหาของคุณ: มันคือเราเตอร์ที่สามหรือการเชื่อมต่อที่อยู่หลังจากนั้น แต่ต้องระวัง หากเพียงแค่จุดเชื่อมต่อเดียวแสดงความล่าช้าสูงและจุดหมายปลายทางสุดท้ายยังคงรวดเร็ว มันอาจเป็นเพียงเราเตอร์ที่ถูกตั้งค่าให้ลดความสำคัญของการจราจรประเภทที่การทดสอบของคุณใช้ นี่เป็นสัญญาณเตือนที่ผิดพลาดทั่วไปที่อาจทำให้คุณหลงทาง
การถอดรหัส Jitter และ Packet Loss
การมองข้าม RTT ที่ง่ายคือที่ที่คุณจะพบข้อมูลเชิงลึกที่สำคัญที่สุด ความ jitter ที่สูง ซึ่งเป็นคำที่หรูหราสำหรับความล่าช้าที่ไม่สม่ำเสมอ สามารถทำให้เกิดความยุ่งเหยิงมากกว่าความล่าช้าที่สูงอย่างสม่ำเสมอ โดยเฉพาะอย่างยิ่งสำหรับสิ่งที่เป็นเรียลไทม์
หากผลลัพธ์ของคุณแสดงค่าเฉลี่ย RTT ที่ 40ms แต่ค่าต่ำสุดคือ 10ms และค่าสูงสุดคือ 150ms การเชื่อมต่อของคุณไม่เสถียร ความแปรปรวนที่มากมายนี้คือสิ่งที่ทำให้เกิดการสะดุดที่น่ารำคาญในการโทรวิดีโอและการกระตุกที่ทำให้เกิดความโกรธในเกมออนไลน์
Packet loss เป็นสัญญาณเตือนที่ใหญ่กว่านั้น แม้แต่ 1% ของ packet loss ก็สามารถทำให้แอปพลิเคชันที่ใช้ TCP เสียหายได้ ทำให้ต้องส่งข้อมูลซ้ำตลอดเวลาและทำให้ทุกอย่างช้าลง เมื่อคุณดูผลการทดสอบของคุณ ความแตกต่างที่แท้จริงระหว่างแพ็กเก็ตที่ส่งและแพ็กเก็ตที่ได้รับต้องได้รับการตรวจสอบทันที
หนึ่งในข้อผิดพลาดที่ใหญ่ที่สุดที่ฉันเห็นผู้คนทำคือการสมมติว่าการทดสอบเพียงครั้งเดียวบอกเล่าเรื่องราวทั้งหมด สภาพเครือข่ายมีการเปลี่ยนแปลงอยู่ตลอดเวลา การทดสอบที่ทำในเวลา 3 โมงเช้าจะดูแตกต่างจากการทดสอบในเวลา 3 โมงเย็นในช่วงเวลาทำการที่มีคนหนาแน่น วิธีเดียวที่จะได้ฐานข้อมูลประสิทธิภาพที่แท้จริงคือการทดสอบอย่างสม่ำเสมอและซ้ำๆ
เพื่อป้องกันปัญหา ควรพิจารณาเครื่องมือเฉพาะสำหรับ การตรวจสอบประสิทธิภาพเครือข่าย วิธีนี้จะเปลี่ยนแนวทางของคุณจากการซ่อมแซมสิ่งต่างๆ อย่างเร่งรีบเมื่อมันพังไปสู่การรักษาเครือข่ายของคุณให้มีสุขภาพดีอย่างเชิงรุก
ข้อผิดพลาดในการวัดที่พบบ่อยที่สุด
- การทดสอบผ่าน Wi-Fi: จริงๆ แล้วอย่าทำเลย การเชื่อมต่อไร้สายมีชื่อเสียงในเรื่องความไม่เสถียร มีแนวโน้มที่จะถูกรบกวนจากทุกอย่างตั้งแต่ไมโครเวฟไปจนถึงเราเตอร์ของเพื่อนบ้าน สำหรับการทดสอบความล่าช้าที่จริงจัง ให้เชื่อมต่อด้วยสาย Ethernet นี่คือวิธีเดียวที่จะได้ฐานข้อมูลที่เสถียรและเชื่อถือได้
- ลืมค่าใช้จ่ายของ VPN: VPN ดีสำหรับความปลอดภัย แต่จะเพิ่มจุดหยุดและการเข้ารหัสให้กับการเดินทางของข้อมูลของคุณ ซึ่งจะ เพิ่ม ความล่าช้าเสมอ หากคุณพยายามวินิจฉัยการเชื่อมต่อที่ช้า คุณควรถามคำถามแรกว่า "คุณใช้ VPN หรือไม่?" การทดสอบด้วยและไม่มีมันจะทำให้คุณเห็นว่ามันเพิ่มความล่าช้าไปเท่าไหร่
- มองข้ามความแออัดของเครือข่ายท้องถิ่น: ผลการทดสอบของคุณจะเบี่ยงเบนหากมีคนอื่นในเครือข่ายของคุณใช้แบนด์วิธทั้งหมด หากเพื่อนร่วมงานกำลังสตรีมวิดีโอ 4K หรือดาวน์โหลดไฟล์ขนาดใหญ่ในขณะที่คุณกำลังทดสอบ ตัวเลขความล่าช้าของคุณจะสูงขึ้น และคุณจะต้องไล่ตามปัญหาที่ไม่มีอยู่จริง
อีกปัจจัยที่ละเอียดอ่อนแต่สำคัญคือเครื่องมือที่คุณเลือก ตามที่เราได้กล่าวถึง เครื่องมือที่แตกต่างกันวัดความล่าช้าในวิธีที่แตกต่างกันเสมอ ควรใช้เครื่องมือที่คุณใช้ในการเปรียบเทียบอย่างสม่ำเสมอ และให้แน่ใจว่าคุณเข้าใจว่าแต่ละเครื่องมือ วัดอะไร จริงๆ ไม่ว่าจะเป็น ICMP echo ที่ง่ายหรือคำขอในระดับแอปพลิเคชันที่ซับซ้อน และอย่าลืมว่าประสิทธิภาพสามารถได้รับผลกระทบจากหลายชั้น; ตัวอย่างเช่น หากคุณกำลังขุดลงไปในประสิทธิภาพของเว็บ คู่มือของเราเกี่ยวกับ Cookie Editor Chrome Extension สามารถแสดงให้เห็นว่าองค์ประกอบด้านลูกค้าเล่นบทบาทอย่างไร
โดยการตีความผลลัพธ์ของคุณด้วยบริบทที่ถูกต้องและหลีกเลี่ยงข้อผิดพลาดทั่วไปเหล่านี้ คุณจะก้าวข้ามจากการเก็บตัวเลขไปสู่การเข้าใจ เหตุผล ที่อยู่เบื้องหลังประสิทธิภาพของเครือข่ายของคุณ และนั่นคือกุญแจสำคัญในการสร้างระบบที่รวดเร็วและเชื่อถือได้มากขึ้น
คำถามทั่วไปเกี่ยวกับความล่าช้าของเครือข่าย
แม้จะมีเครื่องมือที่ถูกต้อง แต่คำถามทั่วไปบางอย่างมักจะเกิดขึ้นเมื่อคุณเริ่มขุดลึกลงไปในความล่าช้าของเครือข่าย มาลองดูคำถามที่พบบ่อยที่สุดที่ฉันได้ยินเพื่อช่วยให้คุณเข้าใจผลลัพธ์ของคุณ
ตัวเลขความล่าช้าที่ “ดี” จริงๆ คืออะไร?
นี่คือคำถามคลาสสิก "มันขึ้นอยู่กับ" แต่เราสามารถตั้งเกณฑ์ที่มั่นคงได้ ตัวเลขความล่าช้าที่ "ดี" นั้นสัมพันธ์กับสิ่งที่คุณพยายามทำ
- การท่องเว็บทั่วไป: สำหรับพวกเราส่วนใหญ่ ทุกอย่างที่ต่ำกว่า 100ms RTT จะรู้สึกดีมาก หน้าเว็บโหลดได้อย่างรวดเร็ว และคุณจะไม่สังเกตเห็นความล่าช้าที่แท้จริง
- การเล่นเกมออนไลน์ที่แข่งขัน: นี่คือที่ที่ทุกมิลลิวินาทีมีความสำคัญ นักเล่นเกมที่จริงจังและนักเทรดที่มีความถี่สูงกำลังมองหาความล่าช้าที่ต่ำกว่า 20ms นี่คือความแตกต่างระหว่างการชนะและการแพ้
- การโทรวิดีโอ & VoIP: ที่นี่ ความสม่ำเสมอคือกุญแจสำคัญ คุณต้องการความล่าช้าที่เสถียรต่ำกว่า 150ms และ jitter ที่ต่ำ (น้อยกว่า 30ms) เพื่อหลีกเลี่ยงความรู้สึกสะดุดและไม่ตรงกัน หรือแย่กว่านั้นคือการโทรที่ถูกตัด
ตามกฎทั่วไป ผู้เชี่ยวชาญด้านเครือข่ายส่วนใหญ่ที่ฉันรู้จักจะจัดประเภททุกอย่างที่ต่ำกว่า 50ms ว่าเป็นความล่าช้าต่ำ จาก 50-150ms ถือว่าปานกลาง และเมื่อคุณเกิน 150ms คุณจะเริ่มรู้สึกถึงความช้าในแอปพลิเคชันที่มีการโต้ตอบส่วนใหญ่
ทำไมผลการทดสอบ Ping และความเร็วของเบราว์เซอร์ของฉันถึงไม่ตรงกัน?
นี่คือคำถามที่ยอดเยี่ยมและเป็นจุดที่สับสนทั่วไป มันเกิดขึ้นเพราะคำสั่ง ping ในบรรทัดคำสั่งและการทดสอบความเร็วในเบราว์เซอร์เป็นเครื่องมือที่แตกต่างกันโดยพื้นฐานที่วัดสิ่งที่แตกต่างกัน
เริ่มต้น พวกเขาแทบจะพูดคุยกับเซิร์ฟเวอร์ที่แตกต่างกัน เมื่อคุณ ping โดเมน คุณกำลังติดต่อเป้าหมายเฉพาะ การทดสอบความเร็วเว็บในทางกลับกัน ถูกออกแบบมาเพื่อค้นหาเซิร์ฟเวอร์ที่ใกล้เคียงทางภูมิศาสตร์จากเครือข่ายของตนเองเพื่อให้ผลลัพธ์ที่ดีที่สุด
โปรโตคอลก็แตกต่างกันโดยสิ้นเชิง Ping ใช้โปรโตคอลที่เบามากชื่อ ICMP การทดสอบเบราว์เซอร์ส่วนใหญ่ทำงานผ่าน TCP ซึ่งต้องการกระบวนการตั้งค่าทั้งหมด (การ "จับมือสามทาง") เพียงเพื่อสร้างการเชื่อมต่อ การแลกเปลี่ยนข้อมูลเบื้องต้นนั้นเพิ่มเวลาเล็กน้อยก่อนที่การทดสอบจริงจะเริ่มต้น
สุดท้าย การทดสอบในเบราว์เซอร์มักจะรวมมากกว่าระยะเวลาในการเดินทางของเครือข่ายเพียงอย่างเดียว ตัวเลข "ความล่าช้า" ของพวกเขาอาจรวมถึงเวลาการประมวลผลของเซิร์ฟเวอร์หรือแม้แต่ความล่าช้าเล็กน้อยภายในเบราว์เซอร์ของคุณเอง ซึ่งอาจทำให้ตัวเลขสุดท้ายสูงขึ้นเมื่อเปรียบเทียบกับการ ping ICMP ดิบ
ฉันจะลดความล่าช้าของเครือข่ายได้อย่างไร?
การลดความหน่วงเวลาเกี่ยวกับการค้นหาและกำจัดจุดคอขวด ไม่ว่าจะอยู่ในสำนักงานของคุณหรือทั่วทั้งอินเทอร์เน็ต
สถานที่แรกที่ควรมองหาคือสภาพแวดล้อมโดยรอบของคุณ การเปลี่ยนแปลงที่มีประสิทธิภาพที่สุดที่คุณสามารถทำได้คือการเปลี่ยนจาก Wi-Fi เป็นการเชื่อมต่อ Ethernet แบบมีสาย นี่คือการเปลี่ยนแปลงที่สำคัญสำหรับความเสถียรและความเร็ว หากคุณต้องใช้ Wi-Fi ให้เข้าใกล้เราเตอร์ของคุณและลองใช้แบนด์ 5GHz หากทำได้—โดยปกติจะมีผู้ใช้น้อยกว่า
เมื่อมองข้ามเครือข่ายท้องถิ่นของคุณ บางครั้งการเปลี่ยน DNS อาจช่วยได้ การใช้เซิร์ฟเวอร์ DNS ที่เร็วขึ้นสามารถลดเวลาในการเชื่อมต่อเริ่มต้นเมื่อคุณค้นหาเว็บไซต์ได้
หากคุณพยายามปรับปรุงการเข้าถึงบริการที่คุณควบคุม เครือข่ายการจัดส่งเนื้อหา (CDN) คือคำตอบ มันทำงานโดยการวางสำเนาของเนื้อหาของคุณให้ใกล้ชิดกับผู้ใช้ของคุณมากขึ้น และหากคุณกำลังใช้ VPN ให้ลองปิดมัน การกระโดดและชั้นการเข้ารหัสเพิ่มเติมมักจะเพิ่มความหน่วงเวลา
ฉันเคยเห็น VPN ของบริษัทเพิ่มเวลาไปกลับได้ถึง 70ms มันสามารถเปลี่ยนการเชื่อมต่อที่ดีให้กลายเป็นการเชื่อมต่อที่ช้าอย่างน่าหงุดหงิดได้เสมอ ทดสอบด้วยและไม่มี VPN ของคุณเพื่อดูว่าคุณได้รับผลกระทบด้านประสิทธิภาพมากน้อยเพียงใด
ความแตกต่างที่แท้จริงระหว่างความหน่วงเวลาและแบนด์วิธคืออะไร?
การทำความเข้าใจเรื่องนี้เป็นพื้นฐานในการเข้าใจประสิทธิภาพของเครือข่าย มันง่ายที่จะสับสน แต่ทั้งสองวัดสิ่งที่แตกต่างกันมาก
นี่คือการเปรียบเทียบที่ฉันมักใช้: คิดว่ามันเหมือนกับทางหลวง
- แบนด์วิธ คือจำนวน เลน ที่ทางหลวงมี เลนมากขึ้นหมายถึงรถยนต์ (ข้อมูล) สามารถเดินทางได้พร้อมกันมากขึ้น
- ความหน่วงเวลา คือ ขีดจำกัดความเร็ว มันกำหนดว่ารถยนต์หนึ่งคัน (แพ็กเกจข้อมูล) สามารถไปจาก A ไป B ได้เร็วแค่ไหน
คุณอาจมีทางหลวงขนาดใหญ่ที่มีสิบเลน (แบนด์วิธมหาศาล) แต่มีขีดจำกัดความเร็ว 20 ไมล์ต่อชั่วโมง (ความหน่วงเวลาสูง) คุณอาจสามารถส่งข้อมูลจำนวนมากได้ในที่สุด แต่สิ่งที่ต้องการเวลาจริง เช่น การโทรวิดีโอ จะช้ามาก ในทางกลับกัน การเชื่อมต่อที่มีความหน่วงเวลาต่ำมากจะรู้สึกตอบสนองได้อย่างรวดเร็ว แม้ว่าจะมีแบนด์วิธไม่มากก็ตาม คุณต้องการความสมดุลที่ดีของทั้งสองอย่างเพื่อให้ได้ประสบการณ์ที่ยอดเยี่ยม
พร้อมที่จะทำให้การทดสอบประสิทธิภาพเป็นส่วนหนึ่งของการทำงานประจำวันของคุณอย่างราบรื่นแล้วหรือยัง? ชุด ShiftShift Extensions มอบการทดสอบความเร็วที่ทรงพลัง ตัวจัดรูปแบบ JSON และเครื่องมือสำหรับนักพัฒนาหลายสิบรายการภายในเบราว์เซอร์ของคุณ โดยเข้าถึงได้ด้วยคำสั่งเดียว หยุดการสลับแท็บและเริ่มทำงานอย่างชาญฉลาด ดาวน์โหลด ShiftShift Extensions ฟรีและเพิ่มประสิทธิภาพการทำงานของคุณวันนี้.