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

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

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

การทำงานของ tracert

Tracert แสดงแผนที่ทุกกระโดดระหว่างคุณกับเซิร์ฟเวอร์

เมื่อคุณพิมพ์ tracert google.com ลงใน Windows Terminal หรือ Command Prompt คำสั่งจะส่งแพ็กเก็ตที่มีค่า TTL (Time To Live) เพิ่มขึ้นอย่างต่อเนื่อง ทำให้เราเตอร์แต่ละตัวตามเส้นทางจำเป็นต้องระบุตัวเอง ในลักษณะนี้ tracert จะค้นหาเราเตอร์แต่ละตัวตามลำดับและวัดระยะเวลาที่ใช้ในการเข้าถึงแต่ละตัว

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

นี่คือลักษณะของการติดตามไปยัง Google.com ที่สุขภาพดีจากการเชื่อมต่อของฉัน:

นี่คือการติดตามที่สะอาดและดีต่อสุขภาพ Hop 1 คือเราเตอร์ท้องถิ่นของฉันที่ 1-2 มิลลิวินาที Hop 2 และ 3 เป็นโครงสร้างพื้นฐานของ ISP ของฉัน ยังคงต่ำกว่า 6 มิลลิวินาที เวลา RTT เพิ่มขึ้นที่ hop 4 เมื่อทราฟฟิกเข้าสู่เครือข่ายอินเทอร์เน็ตกว้าง จากนั้นยังคงคงที่ผ่านเครือข่ายของ Google ไปยังจุดหมาย ไม่มีการกระโดดอย่างฉับพลัน ไม่มีการหมดเวลา

การพุ่งขึ้นของ RTT ระบุคอขวด

สังเกตว่าความหน่วงพุ่งขึ้นตรงไหนและคงอยู่สูง

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

สามโหนดแรกมีเวลา RTT ต่ำกว่า 4 มิลลิวินาที ดังนั้นเครือข่ายท้องถิ่นและผู้ให้บริการอินเทอร์เน็ตของฉันจึงปกติดี แต่ดูที่โหนดที่ 4: เวลา RTT กระโดดไปที่ 66 มิลลิวินาทีเมื่อทราฟฟิกออกจากผู้ให้บริการของฉัน ที่โหนดที่ 5 มันเพิ่มขึ้นเป็น 77 มิลลิวินาทีผ่านจุดแลกเปลี่ยน Equinix จากนั้นที่โหนดที่ 6 เวลา RTT เกือบเพิ่มเป็นสองเท่าเป็น 132 มิลลิวินาทีเมื่อการเชื่อมต่อเข้าถึงเราเตอร์ IIJ.Net ในโตเกียว โดยน่าจะข้ามสายเคเบิลใต้น้ำจากอินเดียไปญี่ปุ่น โหนดที่เหลืออยู่ในช่วง 133-144 มิลลิวินาที และปลายทางอยู่ที่ 160-205 มิลลิวินาที

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

นั่นคือคุณค่าที่แท้จริง หากการดีดตัวปรากฏที่ hop 2 หรือ 3 ผมก็จะรู้ว่าปัญหาอยู่ที่ผู้ให้บริการอินเทอร์เน็ตของผม หากปรากฏที่ hop 1 ผมก็จะมองที่เราเตอร์ของตัวเอง Tracert ไม่เพียงแค่บอกคุณว่าบางอย่างช้า; มันบอกคุณว่าปัญหาอยู่กับใคร

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

ไม่ใช่ทุกความผิดปกติหมายความว่ามีบางอย่างเสีย

เวลาหมดและความผันผวนสามารถเป็นเรื่องปกติได้อย่างสมบูรณ์

ในการติดตามเส้นทางเดียวกันของ yahoo.co.jp ที่ hop 10 แสดงเครื่องหมายดอกจันทั้งสาม probe พร้อมข้อความ "Request timed out" นั่นดูน่าตกใจ แต่การติดตามเส้นทางเสร็จเรียบร้อยที่ hop 11 โดยถึงปลายทาง เราเตอร์ที่ hop 10 เพียงแค่ไม่ตอบสนองต่อ probes ของ tracert เราเตอร์หลายตัวถูกตั้งค่าแบบนี้ด้วยเหตุผลด้านความปลอดภัยหรือเพื่อลดภาระกระบวนการ พวกมันยังคงส่งต่อข้อมูลจริงของคุณ เพียงแต่ไม่ตอบสนองต่อแพ็กเก็ตวินิจฉัยเท่านั้น

Tracert ยังส่งการตรวจสอบไปตามค่าเริ่มต้นสูงสุดของ 30 hop หากไม่สามารถถึงปลายทางภายในขีดจำกัดนั้น คุณจะเห็นข้อความ "Request timed out" สำหรับทุก hop ที่เหลือ ซึ่งมักหมายความว่าเราเตอร์บางตัวตามเส้นทางกำลังบล็อกการตรวจสอบ แต่ยังคงส่งข้อมูลปกติ เช่นเดียวกัน การพบการตรวจสอบสูงหนึ่งครั้งจากสามครั้งใน hop ใด ๆ มักเป็นเสียงรบกวนชั่วคราว ไม่ใช่สิ่งที่ควรสืบสวน

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

หยุดเดาว่าอะไรผิดพลาดกับเครือข่ายของคุณ

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

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