เน็ตเร็วแต่ยังวิดีโอคอลสะดุด? รู้จัก Packet Loss ตัวการที่คนทำ Network ไม่ควรมองข้าม

เคยเจอไหมครับ? อินเทอร์เน็ตดูเร็วดี Speed Test ก็ไม่ได้แย่ แต่พอประชุมผ่าน Zoom หรือ Microsoft Teams ภาพกลับค้าง เสียงขาด ๆ หาย ๆ หรือเล่นเกมออนไลน์แล้วมีอาการแลคแบบจับจังหวะไม่ได้

อาการแบบนี้ไม่ได้เกิดจาก “ความเร็วเน็ต” หรือ Bandwidth อย่างเดียวเสมอไป อีกตัวแปรสำคัญที่คนทำ Network มักต้องตรวจคู่กันคือ Packet Loss หรือการที่ข้อมูลบางส่วนหายไประหว่างทาง

Packet Loss คืออะไร?

อธิบายง่าย ๆ เหมือนเราส่งเอกสาร 100 หน้าไปให้เพื่อน แต่ระหว่างทางหายไปบางหน้า เพื่อนปลายทางจึงได้รับข้อมูลไม่ครบ

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

ที่สำคัญคือ Packet Loss อาจเกิดขึ้นได้แม้ความเร็วอินเทอร์เน็ตโดยรวมจะดูปกติ เพราะ Bandwidth, Latency, Jitter และ Packet Loss เป็นคนละตัวชี้วัดกัน การดูแค่ความเร็วอย่างเดียวจึงอาจยังไม่พอสำหรับการวิเคราะห์ปัญหา Network จริง ๆ

สาเหตุที่พบบ่อยของ Packet Loss

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

สาย LAN หรือหัว RJ45 มีปัญหา
สายชำรุด หัวหลวม สายพับงอมากเกินไป หรือหน้าสัมผัสไม่ดี อาจทำให้เกิด Error ที่พอร์ต เช่น CRC, FCS หรือ Input Error ได้ โดยเอกสารของ Cisco ระบุว่าค่า CRC/FCS/alignment error ที่เพิ่มขึ้นควรถูกตรวจสอบ เพราะอาจเกี่ยวข้องกับปัญหาทางกายภาพหรือ duplex mismatch

Network Congestion
เมื่อมี Traffic หนาแน่น เช่น หลายคนสตรีมวิดีโอพร้อมกัน มีการ Backup ไฟล์ใหญ่ หรือระบบใช้งาน Bandwidth เต็ม อุปกรณ์ระหว่างทางอาจเริ่มหน่วงหรือทิ้ง Packet บางส่วน

อุปกรณ์ทำงานหนักเกินไป
Router, Switch หรือ Firewall ที่ CPU/RAM สูงต่อเนื่อง อาจประมวลผล Traffic ไม่ทัน โดยเฉพาะช่วงที่มี Session จำนวนมาก หรือมี Policy ตรวจสอบทราฟฟิกละเอียดเกินกำลังเครื่อง

Duplex หรือ Speed ไม่ตรงกัน
ถ้าฝั่งหนึ่งตั้ง Full Duplex แต่อีกฝั่งเป็น Half Duplex หรือมีการเจรจาความเร็วผิดพลาด อาจเกิด collision/error และทำให้ทราฟฟิกสูญหายได้ เอกสารของ Cisco และ Meraki ต่างระบุว่า duplex mismatch เป็นหนึ่งในปัญหาที่ควรตรวจเมื่อพบ error หรือ packet loss บนลิงก์

Wi-Fi มีสัญญาณรบกวน
การใช้งานผ่าน Wi-Fi มีโอกาสเจอปัญหามากกว่าสาย LAN เพราะมีปัจจัยเรื่องระยะทาง ผนัง ช่องสัญญาณชนกัน สัญญาณรบกวนจากอุปกรณ์อื่น และจำนวนผู้ใช้งานในพื้นที่เดียวกัน

Switch Loop หรือ Broadcast Storm
การต่อสายผิดจนเกิดลูปในระบบ LAN อาจทำให้ Broadcast วิ่งวนจน Switch ทำงานหนักผิดปกติ และกระทบทั้งเครือข่ายได้

Firewall หรือ Security Policy
บางครั้ง Packet ไม่ได้ “หาย” เพราะระบบเสีย แต่ถูกอุปกรณ์ Security Drop ตาม Policy, IPS, App Control หรือ session limit ที่ตั้งไว้ จึงต้องตรวจ log ประกอบเสมอ

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

วิธีตรวจสอบ Packet Loss เบื้องต้น

สำหรับผู้ใช้ทั่วไปหรือคนดูแลระบบ สามารถเริ่มตรวจได้จากเครื่องมือพื้นฐานก่อน

บน Windows อาจใช้คำสั่ง:

ping 8.8.8.8 -n 100

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

ถ้าต้องการดูว่า Packet Loss อาจเกิดตรงช่วงไหนของเส้นทาง สามารถใช้:

pathping 8.8.8.8

Microsoft ระบุว่า pathping ใช้ดูข้อมูล latency และ packet loss ตาม hop ระหว่างต้นทางกับปลายทางได้ จึงมีประโยชน์มากเวลาต้องแยกว่าเป็นปัญหาที่เครื่องเรา, Gateway, อุปกรณ์ระหว่างทาง หรือปลายทาง

บน Linux หรือ macOS ผู้ดูแลระบบมักใช้เครื่องมืออย่าง mtr หรือ traceroute ควบคู่กับ ping เพื่อดูภาพรวมของเส้นทางและความเสถียร

ควรอ่านค่า Packet Loss อย่างไร?

โดยทั่วไป 0% ถือว่าเป็นสภาพที่ดีที่สุด โดยเฉพาะงานแบบ Real-time เช่น วิดีโอคอล VoIP Remote Desktop หรือเกมออนไลน์

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

แต่ไม่ควรยึดตัวเลขเดียวแบบตายตัว เพราะผลกระทบขึ้นอยู่กับประเภทแอปพลิเคชัน ระยะเวลาที่เกิด จุดที่เกิด loss และมี jitter/latency สูงร่วมด้วยหรือไม่

สิ่งที่คนทำ Network ควรเช็กต่อ

ถ้าเริ่มพบ Packet Loss ควรไล่ตรวจเป็นลำดับ ไม่ควรรีบสรุปว่าเป็นเพราะ ISP ทันที

เริ่มจากเช็กสาย LAN และพอร์ตที่ใช้งาน ลองเปลี่ยนสาย เปลี่ยนพอร์ต หรือทดสอบผ่านสายแทน Wi-Fi จากนั้นดู interface counter เช่น CRC, input error, output drop, collision หรือค่าที่เพิ่มขึ้นผิดปกติ

สำหรับอุปกรณ์ Cisco คำสั่งอย่าง show interfaces ช่วยดูสถานะพอร์ตและ error counter ได้ ส่วนอุปกรณ์ Firewall หรือ Router ควรตรวจ CPU, RAM, session, log การ drop traffic และ policy ที่เกี่ยวข้อง

ในกรณี Wi-Fi ให้ดูระดับสัญญาณ ช่องสัญญาณที่ชนกัน จำนวนผู้ใช้บน Access Point และลองแยกทดสอบระหว่าง 2.4 GHz กับ 5 GHz หากเป็นไปได้

สรุปแล้ว Packet Loss เป็นปัญหาที่ดูเล็ก แต่สร้างผลกระทบชัดเจนมากกับงานที่ต้องการความต่อเนื่องแบบ Real-time ต่อให้เน็ตเร็วแค่ไหน ถ้าข้อมูลบางส่วนหายระหว่างทาง ประสบการณ์ใช้งานก็ยังแย่ได้

ใครดูแลระบบ Network จึงไม่ควรดูแค่ Speed Test อย่างเดียว แต่ควรตรวจ Packet Loss, Latency, Jitter, Interface Error และสถานะอุปกรณ์ควบคู่กันเสมอ เพราะหลายครั้งการเจอสาเหตุเร็ว อาจช่วยแก้ปัญหาได้ก่อนที่ทั้งออฟฟิศจะเริ่มบ่นว่า “เน็ตช้าอีกแล้วครับ!”

แหล่งอ้างอิงข้อมูล :

• Cisco Networking Academy. (2024). Understanding Packet Loss and Network Latency.

• Fortinet Documentation. (2024). Troubleshooting Network Performance and CPU Utilization.

• RFC 2330 - Framework for IP Performance Metrics.