วิธีการวัดความหน่วงของเครือข่าย คู่มือปฏิบัติสำหรับนักพัฒนา

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

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

เหตุผลที่การวัดความหน่วงเป็นสิ่งจำเป็น

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

ลองนึกถึงผลกระทบที่เกิดขึ้นจริง:

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

การแยกแยะแนวคิดหลักเกี่ยวกับความหน่วง

เพื่อวัดความหน่วงของเครือข่ายได้อย่างแม่นยำ คุณต้องรู้ว่าคุณกำลังวัดอะไร แนวคิดพื้นฐานที่สำคัญที่สุดสองประการคือ เวลาเดินทางไปกลับ (RTT) และ ความหน่วงทางเดียว.

RTT คือเวลาทั้งหมดที่ใช้สำหรับสัญญาณเดินทางจากจุด A ไปยังจุด B และกลับมาอีกครั้ง นี่เป็นเมตริกที่พบบ่อยที่สุดเพราะวัดได้ง่าย—คุณต้องการการเข้าถึงปลายทางฝั่งใดฝั่งหนึ่งของการเชื่อมต่อเท่านั้น

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

ความสำคัญของสิ่งนี้ทั้งหมดจะชัดเจนขึ้นเมื่อคุณทำการ ทดสอบประสิทธิภาพโหลด อย่างจริงจัง ซึ่งเป็นจุดที่ทฤษฎีมาบรรจบกับความเป็นจริง และคอขstaclesจะถูกเปิดเผย

เพื่อให้เห็นตัวเลขที่ชัดเจน ผู้เชี่ยวชาญด้านการตรวจสอบเครือข่ายโดยทั่วไปจัดหมวดหมู่ความหน่วงดังนี้:

• ความหน่วงต่ำ: ต่ำกว่า 50 มิลลิวินาที
• ความหน่วงปานกลาง: 50-150 ms
• ความหน่วงสูง: มากกว่า 150 ms

จากประสบการณ์ของผม การทดสอบอย่างรวดเร็วไปยังเซิร์ฟเวอร์ใกล้เคียงอาจแสดงค่าที่ยอมรับได้สมบูรณ์แบบ 20-40 ms แต่ตัวเลขนั้นสามารถเพิ่มขึ้นได้ง่ายมากเกิน 200 ms สำหรับทราฟิกที่ต้องข้ามมหาสมุทร ซึ่งอาจเป็นตัวเปลี่ยนเกมสำหรับประสิทธิภาพของแอปพลิเคชันของคุณ

เพื่อให้เข้าใจศัพท์เทคนิคที่คุณจะพบเจอ นี่คืออ้างอิงอย่างย่อ

แนวคิดเกี่ยวกับความหน่วงที่สำคัญในภาพรวม

แนวคิด	สิ่งที่วัด	ทำไมมันถึงสำคัญ
ความหน่วง (Ping)	เวลาที่ใช้สำหรับแพ็กเก็ตข้อมูลเดินทางจากต้นทางไปยังปลายทางและกลับมา วัดในหน่วยมิลลิวินาที (ms).	นี่คือการวัดความล่าช้าดิบ ความหน่วงต่ำมีความสำคัญอย่างยิ่งสำหรับแอปพลิเคชันแบบเรียลไทม์ เช่น เกม, VoIP และการประชุมทางวิดีโอ
เวลาเดินทางกลับ (RTT)	โดยพื้นฐานเหมือนกับความหน่วง นี่คือระยะเวลาทั้งหมดสำหรับสัญญาณที่จะถูกส่งบวกเวลาที่จะได้รับการยืนยัน.	RTT เป็นวิธีที่พบบ่อยและใช้ได้จริงที่สุดในการวัดความหน่วงจากจุดเดียว ทำให้เป็นเมตริกหลักสำหรับเครื่องมือเช่น ping.
ความหน่วงทางเดียว	เวลาที่ใช้สำหรับแพ็กเก็ตเดินทางจากต้นทางไปยังปลายทางในทิศทางเดียว.	ให้มุมมองที่ละเอียดขึ้น โดยเฉพาะอย่างยิ่งสำหรับเครือข่ายที่ไม่สมมาตร ซึ่งเส้นทางอัปโหลดและดาวน์โหลดมีความหน่วงต่างกัน.
จิตเตอร์	ความแปรปรวนของความหน่วงเมื่อเวลาผ่านไป มันวัดความไม่สอดคล้องกันของเวลาที่แพ็กเก็ตมาถึง.	จิตเตอร์สูงแย่พอๆ กับความหน่วงสูงสำหรับสื่อสตรีมมิ่งและการโทรออนไลน์ ทำให้เกิดการกระตุก, การบัฟเฟอร์ และข้อผิดพลาด.
แบนด์วิดท์	ปริมาณข้อมูลสูงสุดที่สามารถส่งผ่านการเชื่อมต่อเครือข่ายได้ในช่วงเวลาที่กำหนด วัดใน Mbps หรือ Gbps.	มักสับสนกับความเร็ว แบนด์วิดท์เกี่ยวกับความจุ คุณสามารถมีแบนด์วิดท์สูงแต่ยังคงทนทุกข์กับความหน่วงสูงได้.

แนวคิดเหล่านี้คือองค์ประกอบพื้นฐานสำหรับการทำความเข้าใจปัญหาประสิทธิภาพเครือข่ายใดๆ.

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

ลงมือใช้เครื่องมือวัดเวลาแฝงผ่าน Command-Line

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

เครื่องมือคลาสสิกที่ใช้งานกันมานานคือ ping. มันเรียบง่ายและยอดเยี่ยมมาก: มันจะส่งแพ็กเก็ตข้อมูลเล็กๆ (คำขอ ICMP echo) ไปยังเซิร์ฟเวอร์แล้วรอให้ส่งกลับมา นั่นคือพื้นฐานสำหรับการคำนวณ เวลาแฝงไปกลับ (RTT) และให้การตรวจสอบสถานะการเชื่อมต่อของคุณได้ทันที

การตรวจสอบเวลาแฝงครั้งแรกของคุณด้วย Ping

การรันการทดสอบ ping นั้นง่ายดายมาก เปิดเทอร์มินัลหรือ Command Prompt ของคุณ พิมพ์ ping ตามด้วยโดเมนที่คุณต้องการทดสอบ

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

เมื่อเสร็จสิ้น คุณจะได้รับสรุปที่กระชับพร้อมตัวเลขสำคัญ:

• แพ็กเก็ตที่ส่ง/รับ: บอกคุณว่ามีข้อมูลสูญหายไประหว่างทางหรือไม่ แม้แต่ปริมาณการสูญเสียแพ็กเก็ตเพียงเล็กน้อยก็เป็นสัญญาณเตือนภัยครั้งใหญ่สำหรับปัญหาเครือข่าย
• สถิติเวลาเดินทางกลับ (Round-trip) ขั้นต่ำ/เฉลี่ย/สูงสุด/ค่าเบี่ยงเบนมาตรฐาน: นี่คือสถิติความหน่วงหลักของคุณ คุณจะได้เวลาในกรณีที่ดีที่สุด (min) ค่าเฉลี่ย (avg) และกรณีที่แย่ที่สุด (max) mdev (ค่าเบี่ยงเบนเฉลี่ย) เป็นการวัด jitter ของคุณ — ว่าความหน่วงแตกต่างกันมากน้อยแค่ไหนระหว่างแต่ละแพ็กเก็ต.

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

ข้อผิดพลาดทั่วไปคือการมองแค่ค่าเฉลี่ย RTT อย่างรวดเร็ว ค่าเฉลี่ย 50ms อาจดูโอเค แต่ถ้าค่าขั้นต่ำของคุณคือ 20ms และค่าสูงสุดคือ 250ms ประสบการณ์ของผู้ใช้จะรู้สึกกระตุกและไม่น่าเชื่อถือ ให้ดูช่วงค่าทั้งหมดเสมอเพื่อเข้าใจ jitter.

การติดตามร่องรอยด้วย Traceroute และ MTR

แล้วจะทำอย่างไรเมื่อ ping เผยให้เห็นความหน่วงสูงหรือการสูญเสียแพ็กเก็ต? งานต่อไปของคุณคือค้นหาว่า ที่ไหน ที่เป็นปัญหา นั่นคือสิ่งที่ traceroute (หรือ tracert บน Windows) ทำได้ มันจะแสดงแผนที่ของเส้นทางทั้งหมดที่แพ็กเก็ตของคุณเดินทาง โดยแสดงทุก "จุดกระโดด" — แต่ละเราเตอร์ — ระหว่างเครื่องของคุณและจุดหมายปลายทาง.

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

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

เหตุใดการเลือกเครื่องมือจึงมีความสำคัญ

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

จริงๆ แล้วตัวเลขที่ต่างกันค่อนข้างน่าทึ่งเลยนะ ในประสบการณ์ทดสอบอย่างละเอียดที่ดำเนินการโดย Google Cloud การทดสอบ ping แบบมาตรฐานรายงานค่า RTT โดยเฉลี่ยที่ 146 ไมโครวินาที แต่เมื่อพวกเขาใช้เครื่องมืออีกตัวหนึ่งที่ส่งธุรกรรมต่อเนื่องกันโดยไม่หยุดพัก ค่า RTT ก็ลดลงเหลือเพียง 66.59 ไมโครวินาที—เร็วขึ้นมากกว่าสองเท่าเลยทีเดียว!

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

ค้นหาความเร็วสูงสุดของคุณด้วย iperf

ความหน่วงไม่ใช่ภาพรวมทั้งหมดเสมอไป บางครั้งคุณจำเป็นต้องรู้ปริมาณข้อมูลสูงสุดที่การเชื่อมต่อของคุณสามารถส่งผ่านได้จริง—นั่นคือแบนด์วิดท์ของมัน สำหรับงานนี้ เครื่องมือที่คุณต้องการคือ iperf.

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

เพื่อใช้งาน iperf คุณจะต้องมีเครื่องคอมพิวเตอร์สองเครื่อง:

1. บนเครื่องหนึ่ง คุณรัน iperf ใน โหมดเซิร์ฟเวอร์ มันจะแค่นั่งรอฟังการเชื่อมต่อเข้ามา
2. บนอีกเครื่องหนึ่ง คุณรัน iperf ใน โหมดลูกค้า โดยชี้มันไปที่ที่อยู่ของเซิร์ฟเวอร์

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

วัดความหน่วงจากมุมมองของผู้ใช้

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

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

ดำดิ่งสู่เครื่องมือสำหรับนักพัฒนาในเบราว์เซอร์

เบราว์เซอร์หลักทุกตัว—Chrome, Firefox, Edge, Safari—ล้วนมาพร้อมกับชุดเครื่องมือสำหรับนักพัฒนา

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

• DNS Lookup: เวลาที่ใช้ในการแก้ไขชื่อโดเมนไปเป็น IP Address.
• Initial Connection: เวลาที่ใช้ในการสร้าง การเชื่อมต่อ TCP กับเซิร์ฟเวอร์.
• SSL/TLS Handshake: ค่าใช้จ่ายด้านเวลาที่ต้องใช้ในการตั้งค่าการเชื่อมต่อที่ปลอดภัย.
• Time to First Byte (TTFB): นี่คือตัวชี้วัดที่สำคัญมาก มันวัดว่าเบราว์เซอร์ต้องรอเวลานานเท่าใดก่อนที่จะได้รับ ไบต์ข้อมูลแรกเริ่ม จากเซิร์ฟเวอร์.
• Content Download: เวลาที่ใช้ในการดาวน์โหลดทรัพยากรนั้นๆ โดยเฉพาะ.

ตัวอย่างเช่น TTFB ที่สูง เป็นสัญญาณบ่งชี้ที่ชัดเจนของปัญหาฝั่งแบ็กเอนด์หรือการประมวลผลฝั่งเซิร์ฟเวอร์ที่เชื่องช้า ซึ่งเป็นสิ่งที่การ ping ทดสอบอย่างง่ายๆ ไม่มีทางค้นพบได้

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

การวัดเชิงโปรแกรมด้วย Timing APIs

สำหรับการวัดที่แม่นยำและเป็นระบบอัตโนมัติมากขึ้น คุณสามารถใช้ JavaScript API ที่ฝังอยู่ในเบราว์เซอร์ได้ Navigation Timing API และ Resource Timing API ให้คุณเข้าถึงข้อมูลประสิทธิภาพที่ละเอียดเหมือนกับที่เห็นในเครื่องมือสำหรับนักพัฒนาได้ทางโปรแกรม

คุณสามารถดึงเมตริกเหล่านี้ได้ด้วย JavaScript ไม่กี่บรรทัด บน console ของเบราว์เซอร์ได้เลย ตัวอย่างเช่น เพื่อรับค่าเวลาหลักของการโหลดหน้าเว็บหลัก คุณสามารถใช้ performance.getEntriesByType('navigation') ซึ่งจะส่งคืนอ็อบเจ็กต์ที่เต็มไปด้วย timestamps ที่มีคุณค่า.

จากข้อมูลนี้ คุณสามารถคำนวณเมตริกที่สำคัญได้:

• DNS Lookup Time: domainLookupEnd - domainLookupStart
• TCP Handshake Time: connectEnd - connectStart
• Time to First Byte (TTFB): responseStart - requestStart
• เวลาโหลดหน้าทั้งหมด: loadEventEnd - startTime

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

การปรับปรุงการตรวจสอบให้ราบรื่นด้วยเครื่องมือที่ผสานรวม

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

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

วิธีการออกแบบการทดสอบเวลาแฝงที่บอกข้อมูลที่มีประโยชน์จริงๆ

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

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

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

อย่างที่คุณเห็น ตั้งแต่การค้นหา DNS ครั้งแรกไปจนถึงการเรนเดอร์ขั้นสุดท้าย มีหลายขั้นตอนที่มีส่วนทำให้เกิดเวลาการรอคอยโดยรวม

การเลือกจุดปลายทางสำหรับทดสอบของคุณ

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

รายการจุดเชื่อมต่อของคุณควรครอบคลุมพื้นที่หลักหลายจุด:

• ศูนย์กลางผู้ใช้ที่สำคัญที่สุดของคุณ: ลูกค้าส่วนใหญ่ของคุณอาศัยอยู่ที่ไหน? ทดสอบจากจุดนั้น
• เส้นทางข้ามทวีป: ดูว่าเกิดอะไรขึ้นเมื่อข้อมูลต้องข้ามมหาสมุทร ทดสอบระหว่างยุโรปและอเมริกาเหนือ หรือเอเชียและสหรัฐอเมริกา เพื่อเข้าใจประสิทธิภาพระยะยาว
• Cloud Regions ของคุณ: หากคุณใช้ AWS, Azure, หรือ GCP ทดสอบการเชื่อมต่อ ถึง และ ระหว่าง ศูนย์ข้อมูลเฉพาะที่คุณพึ่งพา

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

การค้นหาจังหวะการทดสอบที่เหมาะสม

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

เพื่อให้ได้ค่าพื้นฐานที่แท้จริง คุณจำเป็นต้องทดสอบอย่างสม่ำเสมอตลอดเวลา ลองสลับเปลี่ยนรูปแบบดู:

• ทดสอบในช่วงเวลาที่มีการใช้งานสูงสุดทางธุรกิจ
• กำหนดเวลาทดสอบบางส่วนในช่วงเวลาการบำรุงรักษาข้ามคืน
• อย่าลืมช่วงวันหยุดสุดสัปดาห์ ซึ่งรูปแบบการใช้งานอาจแตกต่างกันอย่างสิ้นเชิง

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

อย่าลืมเรื่อง Jitter

เวลาแฝงเฉลี่ยเป็นจุดเริ่มต้นที่ดี แต่มักจะซ่อนปัญหาที่ร้ายแรงกว่า: jitter. Jitter เป็นเพียง ความแปรผัน ในเวลาแฝงของคุณตลอดเวลา พิจารณาดู — การเชื่อมต่อที่เสถียรและมีความ 80ms หน่วงที่คาดการณ์ได้มักจะดีกว่าสำหรับแอปพลิเคชันแบบเรียลไทม์มากกว่าการเชื่อมต่อที่มีค่าเฉลี่ย 50ms แต่เด้งขึ้นลงอย่างรุนแรงระหว่าง 10ms และ 200ms.

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

การเข้าใจ jitter หมายความว่าต้องมองให้ไกลกว่าค่าเฉลี่ย มันคือตัวร้ายที่ไม่ได้รับการยกย่องเพราะมันเปิดเผยเหตุผลว่าทำไมค่าเฉลี่ยเพียงอย่างเดียวถึงสามารถทำให้เข้าใจผิดได้ง่ายนัก ตัวอย่างเช่น ข้อมูลจาก Pandora FMS แสดงให้เห็นว่า jitter ที่มากกว่า 30ms สามารถเพิ่มอัตราการสูญหายของข้อมูล (packet loss) ในการเล่นเกมได้ถึง 15%—มากพอที่จะทำให้เกมเล่นไม่ได้เลย การวัดค่าเบี่ยงเบนมาตรฐาน (standard deviation) ของค่าเวลาแฝง (latency) ของคุณคือขั้นตอนแรกในการกำหนดตัวเลขนั้นให้กับความไม่เสถียรนี้

รายการตรวจสอบการออกแบบการทดสอบเวลาแฝง

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

รายการตรวจสอบ	ทำไมจึงสำคัญ	เคล็ดลับที่นำไปใช้ได้
กำหนดเป้าหมายที่ชัดเจน	คุณไม่สามารถวัดสิ่งที่คุณไม่ได้กำหนดได้ คุณกำลังแก้ไขปัญหาเฉพาะเจาะจงหรือกำลังสร้างค่าพื้นฐาน (baseline)?	จดวัตถุประสงค์ของคุณไว้ก่อนเริ่ม "วินิจฉัยปัญหาความหน่วงสำหรับผู้ใช้ในเอเชียตะวันออกเฉียงใต้" เป็นเป้าหมายที่ดีกว่า "ตรวจสอบเวลาแฝง"
เลือกจุดปลายทางที่หลากหลาย	เส้นทางเดียวไม่สามารถเป็นตัวแทนประสบการณ์ผู้ใช้ทั่วโลกของคุณได้	เลือก 3-5 ตำแหน่ง: หนึ่งในท้องถิ่น, หนึ่งบนทวีปอื่น, และอีกหลายตำแหน่งในตลาดผู้ใช้หลักของคุณ
สร้างความถี่ในการทดสอบ	การทดสอบครั้งเดียวจะพลาดรูปแบบตามช่วงเวลา เช่น ความแออัดในชั่วโมงเร่งด่วน	กำหนดเวลาให้ทดสอบรันอัตโนมัติทุกชั่วโมงเป็นเวลาหนึ่งสัปดาห์เพื่อจับเก็บวัฏจักรที่สมบูรณ์ของพฤติกรรมเครือข่าย
วัด Jitter	ค่าเฉลี่ยซ่อนประสิทธิภาพที่ไม่แน่นอนซึ่งทำลายแอปพลิเคชันแบบเรียลไทม์	อย่าดูแค่ค่าเฉลี่ย RTT จงคำนวณค่าเบี่ยงเบนมาตรฐาน หรือใช้เครื่องมือเช่น mtr ที่แสดงเวลาแฝงต่ำสุด/สูงสุด/เฉลี่ย
ใช้เครื่องมือที่เหมาะสม	ping ดีสำหรับการตรวจสอบอย่างรวดเร็ว แต่เครื่องมือเช่น mtr หรือ iperf จะให้ข้อมูลเชิงลึกมากกว่า	สำหรับประสิทธิภาพเว็บ ให้ใช้เครื่องมือสำหรับนักพัฒนาในเบราว์เซอร์ สำหรับเส้นทางเครือข่ายดิบ mtr เป็นทางเลือกที่ยอดเยี่ยม
บันทึกทุกอย่าง	อีกหกเดือนข้างหน้า คุณจะลืม "เหตุผล" ที่อยู่เบื้องหลังการทดสอบของคุณไปเอง.	เก็บบันทึกง่ายๆ: วันที่, เวลา, endpoint ที่ใช้, เครื่องมือที่ใช้ และบันทึกสั้นๆ สิ่งที่คุณสังเกตเห็น.

ด้วยการดำเนินการอย่างมีแบบแผน คุณจะก้าวจากการวัดค่าเวลาแฝง (latency) ไปสู่การทำความเข้าใจอย่างแท้จริง วิธีการที่พิถีพิถันนี้คือสิ่งที่แยกตัวเลขสุ่มๆ ออกจากตัวชี้วัดประสิทธิภาพที่เชื่อถือได้.

การทำความเข้าใจตัวเลข (และสิ่งที่ควรหลีกเลี่ยง)

เอาล่ะ คุณได้รันการทดสอบแล้วและมีกองข้อมูลอยู่ในมือ นี่คือจุดที่งานจริงเริ่มต้นขึ้น—การแปลงตัวเลขดิบเหล่านั้นให้กลายเป็นสิ่งที่มีความหมายจริงๆ ข้อมูลกำลังเล่าเรื่องราวเกี่ยวกับสุขภาพเครือข่ายของคุณ คุณแค่ต้องเรียนรู้วิธีการอ่านมัน.

ตัวอย่างเช่น การเพิ่มขึ้นอย่างฉับพลันของเวลาเดินทางกลับ (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 อยู่หรือเปล่า?" การทดสอบทั้งแบบเปิดและปิด VPN จะแสดงให้เห็นอย่างชัดเจนว่ามันเพิ่มความล่าช้าไปมากน้อยเท่าใด
• เมินเฉยต่อความหนาแน่นของเครือข่ายภายใน: ผลการทดสอบของคุณจะผิดเพี้ยนไปหากมีคนอื่นในเครือข่ายเดียวกันกำลังใช้แบนด์วิดท์ทั้งหมด หากเพื่อนร่วมงานกำลังสตรีมวิดีโอ 4K หรือดาวน์โหลดไฟล์ขนาดใหญ่ในขณะที่คุณทดสอบ ค่าความหน่วงของคุณจะสูงเกินจริง และคุณจะจบลงด้วยการไล่ตามปัญหาที่ไม่มีอยู่จริง

อีกปัจจัยที่ละเอียดอ่อนแต่สำคัญคือเครื่องมือที่คุณเลือก อย่างที่เราได้กล่าวไป เครื่องมือต่างๆ วัดค่าความหน่วงในรูปแบบที่แตกต่างกัน จงใช้เครื่องมือเดียวกันอย่างสม่ำเสมอเพื่อการเปรียบเทียบ และตรวจสอบให้แน่ใจว่าคุณเข้าใจว่าแต่ละเครื่องมือกำลัง จริงๆ วัดสิ่งใด—ไม่ว่าจะเป็น ICMP echo แบบง่าย หรือคำขอระดับแอปพลิเคชันที่ซับซ้อน และจำไว้ว่าประสิทธิภาพอาจได้รับผลกระทบจากหลายชั้น ตัวอย่างเช่น หากคุณกำลังวิเคราะห์ประสิทธิภาพเว็บ คู่มือของเราเกี่ยวกับ Cookie Editor Chrome Extension สามารถแสดงให้เห็นว่าองค์ประกอบฝั่งลูกค้ามีบทบาทอย่างไร

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

คำถามที่พบบ่อยเกี่ยวกับค่าความหน่วงของเครือข่าย

แม้จะมีเครื่องมือที่เหมาะสม คำถามทั่วไปไม่กี่ข้อก็มักจะปรากฏขึ้นเสมอเมื่อคุณเริ่ม深入了解 latency ของเครือข่าย เรามาดูคำถามที่พบบ่อยที่สุดที่ฉันได้ยินบ่อยๆ เพื่อช่วยให้คุณเข้าใจผลลัพธ์ของคุณ

ตัวเลข latency ที่ "ดี" จริงๆ คืออะไร?

นี่คือคำถาม "มันขึ้นอยู่กับ" แบบคลาสสิก แต่เราสามารถกำหนดเกณฑ์มาตรฐานที่มั่นคงได้แน่นอน "Latency ที่ดี" นั้นสัมพันธ์กับสิ่งที่คุณพยายามจะทำให้สำเร็จอย่างสมบูรณ์

• การท่องเว็บทั่วไป: สำหรับพวกเราส่วนใหญ่ ทุกอย่างที่ต่ำกว่า 100ms RTT จะรู้สึกสมบูรณ์แบบ หน้าเว็บจะโหลดอย่างรวดเร็ว และคุณจะไม่สังเกตเห็นความล่าช้าใดๆ จริงๆ
• การเล่นเกมออนไลน์แบบแข่งขัน: นี่คือที่ที่ทุกวินาทีมีความสำคัญ นักเล่นเกมมืออาชีพและเทรดเดอร์ความถี่สูงกำลังมองหาค่าความหน่วงที่ต่ำกว่ามาก 20ms. นั่นคือความแตกต่างระหว่างการชนะและการแพ้
• การโทรผ่านวิดีโอและ VoIP: ที่นี่ ความเสถียรคือสิ่งสำคัญที่สุด คุณจำเป็นต้องรักษาเวลาแฝงที่เสถียรต่ำกว่า 150ms และ jitter ต่ำ (น้อยกว่า 30ms) เพื่อหลีกเลี่ยงความรู้สึกไม่ลื่นไหล ไม่ซิงค์กัน หรือแย่กว่านั้นคือสายหลุด

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

ทำไม Ping และผลลัพธ์การทดสอบความเร็วเบราว์เซอร์ของฉันจึงไม่ตรงกันเสมอไป?

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

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

โปรโตคอลก็แตกต่างกันอย่างสิ้นเชิง Ping ใช้โปรโตคอลที่มีน้ำหนักเบาเรียกว่า ICMP การทดสอบเบราว์เซอร์ส่วนใหญ่ทำงานผ่าน TCP ซึ่งต้องใช้กระบวนการตั้งค่าทั้งหมด ("การจับมือสาม-way") เพื่อแค่เชื่อมต่อ การแลกเปลี่ยนเบื้องต้นนี้จะเพิ่มเวลาอีกเล็กน้อยก่อนที่การทดสอบจริงจะเริ่มต้นขึ้น

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

ฉันจะลดเวลาแฝงของเครือข่ายได้อย่างไรจริงๆ?

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

จุดแรกที่ควรตรวจสอบคือสภาพแวดล้อมรอบตัวคุณโดยตรง การเปลี่ยนแปลงที่มีประสิทธิผลมากที่สุดอย่างหนึ่งที่คุณทำได้คือการสลับจากการใช้ Wi-Fi มาเป็นการเชื่อมต่อ Ethernet แบบมีสาย ซึ่งเป็นจุดเปลี่ยนสำคัญสำหรับความเสถียรและความเร็ว หากคุณจำเป็นต้องใช้ Wi-Fi ให้เข้าใกล้เราเตอร์ของคุณมากขึ้น และ尝试เข้าร่วมย่านความถี่ 5GHz ถ้าทำได้ — โดยทั่วไปแล้วจะมีการจราจรน้อยกว่า

เมื่อมองเลยเครือข่ายท้องถิ่นของคุณ บางครั้งการเปลี่ยน DNS สามารถช่วยได้ การใช้เซิร์ฟเวอร์ DNS ที่เร็วกว่าสามารถลดเวลาเชื่อมต่อเริ่มต้นลงได้หลายมิลลิวินาที เมื่อคุณค้นหาเว็บไซต์

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

ฉันเคยเห็น VPN ขององค์กรเพิ่มเวลารอบ往返ได้มากถึง 70ms มันสามารถเปลี่ยนการเชื่อมต่อที่ยอดเยี่ยมให้กลายเป็นการเชื่อมต่อที่ช้าจนน่าหงุดหงิด ควรทดสอบทั้งแบบมีและไม่มี VPN เสมอเพื่อดูว่าคุณกำลังได้รับผลกระทบต่อประสิทธิภาพขนาดไหนกันแน่

ความแตกต่างจริงๆ ระหว่าง Latency กับ Bandwidth คืออะไร?

การทำความเข้าใจเรื่องนี้ให้ถูกต้องเป็นพื้นฐานสำหรับการทำความเข้าใจประสิทธิภาพเครือข่าย มันง่ายที่จะสับสนระหว่างกัน แต่ทั้งสองวัดสิ่งที่แตกต่างกันโดยสิ้นเชิง

นี่คืออุปมาที่ฉันใช้เสมอ: ลองนึกถึงมันเหมือนทางหลวง

• Bandwidth คือจำนวน ช่องทาง ที่ทางหลวงมี ยิ่งมีช่องทางมากเท่าไหร่ รถยนต์ (ข้อมูล) ก็สามารถสัญจรได้มากขึ้นในเวลาเดียวกัน
• Latency คือ ความเร็วสูงสุดที่กำหนด มันเป็นตัวกำหนดว่ารถยนต์คันเดียว (ชุดข้อมูล) จะสามารถเดินทางจากจุด A ไปยังจุด B ได้เร็วเพียงใด

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

---

พร้อมที่จะทำให้การทดสอบประสิทธิภาพเป็นส่วนหนึ่งที่ราบรื่นของขั้นตอนการทำงานประจำวันของคุณแล้วหรือยัง? ชุดเครื่องมือ ShiftShift Extensions วางเครื่องมือทดสอบความเร็วที่ทรงพลัง, ตัวจัดรูปแบบ JSON, และเครื่องมือนักพัฒนาอื่นๆ อีกหลายสิบรายการไว้ในเบราว์เซอร์ของคุณโดยตรง เข้าถึงได้ด้วยคำสั่งเดียว หยุดจัดการหลายแท็บและเริ่มทำงานอย่างชาญฉลาดขึ้น ดาวน์โหลด ShiftShift Extensions ได้ฟรีและเพิ่มประสิทธิภาพการทำงานของคุณวันนี้.