ปรับแต่ง TCP/IP เพื่อลดอาการแล็กในเกม

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

ปรับแต่ง TCP/IP ให้เหมาะสมสำหรับ ลดความหน่วง มันไม่ใช่แค่เรื่องของการปรับแต่ง "การตั้งค่ามหัศจรรย์" สองสามอย่าง คุณต้องเข้าใจว่าแนวคิดต่างๆ เช่น... ทำงานอย่างไร MTU, MSS, ขนาดหน้าต่าง TCP, ความหน่วง หรือ bufferbloatจากนั้นให้ทำการเปลี่ยนแปลงเฉพาะเจาะจงกับพีซี เราเตอร์ เครือข่าย Wi-Fi และแม้แต่เซิร์ฟเวอร์คลาวด์หรือเครื่องเสมือน มาดูกันทีละขั้นตอน แต่ด้วยมุมมองที่เน้นการใช้งานจริง: แต่ละอย่างคืออะไร และคุณสามารถทำอะไรได้บ้างเพื่อให้การเชื่อมต่อของคุณตอบสนองได้เร็วขึ้น

แนวคิดหลักของ TCP/IP ที่ส่งผลต่อความหน่วง

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

MTU, การแตกตัว และ LSO

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

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

นอกจากนี้ยังมีส่วนที่มีชื่อเสียงอีกด้วย “อย่าแตกแยก” (DF) ในส่วนหัวของ IP หากเปิดใช้งาน และเราเตอร์ระดับกลางได้รับแพ็กเก็ตที่มีขนาดใหญ่กว่า MTU แทนที่จะแบ่งแพ็กเก็ต เราเตอร์จะทิ้งแพ็กเก็ตนั้นและส่งข้อความ ICMP "Fragmentation Needed" กลับมา ซึ่งจะใช้ใน... การตรวจจับเส้นทาง MTU (PMTUD)แต่หากไฟร์วอลล์บล็อกแพ็กเก็ต ICMP เหล่านั้น ผู้ส่งก็จะยังคงพยายามส่งแพ็กเก็ตขนาดใหญ่เกินไป ซึ่งจะทำให้เกิดความล่าช้าและการส่งซ้ำ

ในสภาพแวดล้อมอย่าง Azure หรือ Google Cloud แพ็กเกจที่แยกส่วนมักจะสูญเสียข้อดีไปเช่นกัน เครือข่ายเร่งความเร็วSR-IOV และ SmartNICs จะถูกประมวลผลผ่านเส้นทางช้าของไฮเปอร์ไวเซอร์ โดยมีรายละเอียดเพิ่มเติม กระวนกระวายใจความหน่วงแย่ลงและจำนวนแพ็กเก็ตต่อวินาทีลดลง ดังนั้นคำแนะนำโดยทั่วไปคือ หลีกเลี่ยงการแตกกระจายของสัญญาณโดยการปรับค่า MTU และ MSS ให้เหมาะสม และไม่ควรเพิ่มค่า MTU มากเกินไปหากมีไฟร์วอลล์หรือ VPN คั่นอยู่

ในทางกลับกัน ฟังก์ชัน ปริมาณการส่งขนาดใหญ่ (LSO) วิธีนี้ช่วยให้สแต็ก TCP/IP ของระบบปฏิบัติการสร้าง "ซูเปอร์แพ็กเก็ต" ขนาดใหญ่ ซึ่งจะถูกแบ่งย่อยภายในโดยการ์ดเครือข่ายตามค่า MTU วิธีนี้ช่วยลดภาระ CPU ได้อย่างมาก แม้ว่าในการตรวจสอบการรับส่งข้อมูล คุณอาจเห็นเฟรมขนาดใหญ่มากที่ไม่ได้บ่งชี้ว่ามีการแบ่งย่อยบนเครือข่าย แต่เป็นการแบ่งย่อยที่เกิดขึ้นภายในอะแดปเตอร์เอง

MSS, PMTUD และ VPN

El TCP MSS (ขนาดเซ็กเมนต์สูงสุด) ค่านี้กำหนดว่าข้อมูลที่ใช้งานได้แต่ละส่วน (TCP segment) จะมีจำนวนกี่ไบต์ โดยไม่รวมส่วนหัว IP และ TCP โดยทั่วไป ระบบจะคำนวณค่า MSS ดังนี้:

MSS = MTU - (tamaño cabecera IP + tamaño cabecera TCP)

ด้วยค่า MTU 1500 และส่วนหัว IPv4+TCP ขนาด 20+20 ไบต์ ค่า MSS ทั่วไปคือ ไบต์ 1460ค่านี้จะถูกเจรจาในระหว่างการเชื่อมต่อแบบสามทางของ TCP โดยแต่ละฝ่ายจะเสนอค่าของตนเอง และการเชื่อมต่อจะใช้ค่าที่ต่ำกว่าในสองค่าดังกล่าว

อย่างไรก็ตาม อาจมีอุปกรณ์ต่างๆ ขวางกั้นอยู่ตามเส้นทาง (เช่น ไฟร์วอลล์, เราเตอร์, เกตเวย์ VPNเป็นต้น) ด้วย MTU ที่เล็กลง ซึ่งส่งผลให้ MSS ลดลงอย่างมีประสิทธิภาพ นี่คือจุดที่ เส้นทาง MTU Discovery (PMTUD)เมื่อเราเตอร์ไม่สามารถส่งต่อแพ็กเก็ตได้เนื่องจากแพ็กเก็ตมีขนาดใหญ่เกินไปและมีการตั้งค่าบิต DF ไว้ เราเตอร์จะทิ้งแพ็กเก็ตนั้นและส่งข้อความ ICMP "Fragmentation Needed" เพื่อระบุขนาด MTU สูงสุดที่รองรับ เพื่อให้ต้นทางลดขนาดแพ็กเก็ตลง

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

บนโซเชียลมีเดียกับ แอปพลิเคชั่น VPN IPsec หรือในอุโมงค์อื่นๆ ส่วนหัวเพิ่มเติมจะลดพื้นที่ว่างสำหรับข้อมูล ดังนั้นจึงแนะนำให้ใช้ค่า MTU และ MSS ที่เล็กกว่า (เช่น MTU 1400 และ MSS ~1350 ในอุโมงค์ทั่วไป) เพื่อหลีกเลี่ยงการแตกตัวของอุโมงค์และความล่าช้าที่เกี่ยวข้อง

ความหน่วง, RTT และหน้าต่าง TCP

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

ในโปรโตคอล TCP อัตราการรับส่งข้อมูลสูงสุดตามทฤษฎีของการเชื่อมต่อเดียวจะถูกกำหนดโดยสูตรพื้นฐานนี้:

rendimiento máximo ≈ tamaño de ventana TCP / RTT

La หน้าต่าง TCP นี่คือปริมาณข้อมูลที่ผู้ส่งสามารถมี "ในระหว่างการส่ง" โดยที่ยังไม่ได้รับการยืนยันการรับส่งข้อมูล (ACK) ด้วยหน้าต่างขนาด 65.535 ไบต์และ MSS ที่ 1460 จะสามารถส่งแพ็กเก็ตได้เพียงประมาณ 45 แพ็กเก็ตก่อนที่จะต้องรอการยืนยันการรับส่งข้อมูล หาก RTT สูง (ตัวอย่างเช่น 80-160 มิลลิวินาทีระหว่างทวีป) หน้าต่างที่ไม่ได้ปรับขนาดจะไม่สามารถใช้ประโยชน์จากลิงก์ที่มีความจุสูงได้อย่างเต็มที่

โดยค่าเริ่มต้น ฟิลด์ window ในส่วนหัวของ TCP มีขนาด 16 บิต ซึ่งจำกัดค่าสูงสุดไว้ที่ 65.535 ไบต์ สำหรับเครือข่ายสมัยใหม่แล้ว ขนาดนี้เป็นไปไม่ได้ ดังนั้นเมื่อหลายปีก่อนจึงมีการนำ [ข้อมูลที่ขาดหายไป - น่าจะเป็นคุณสมบัติหรือวิธีการเฉพาะ] มาใช้ การปรับขนาดหน้าต่าง TCPซึ่งจะนำค่าดังกล่าวไปคูณด้วยตัวคูณ 2^na และอนุญาตให้ใช้หน้าต่างที่มีขนาดหลายร้อยเมกะไบต์หรือแม้แต่หลายกิกะไบต์ได้

ในระบบปฏิบัติการอย่าง Windows หรือ Linux การปรับขนาดหน้าต่างจะถูกจัดการโดยอัตโนมัติด้วยการตั้งค่าที่กำหนดไว้ล่วงหน้า (การปรับแต่งอัตโนมัติ) และสามารถดูหรือแก้ไขได้โดยใช้คำสั่งต่างๆ เช่น Get-NetTCPSetting o sysctlระดับการตั้งค่าที่เข้มงวดมากขึ้น (เช่น "ทดลอง") อนุญาตให้ใช้หน้าต่างขนาดใหญ่ และสามารถปรับปรุงประสิทธิภาพบนเครือข่ายระยะไกลได้อย่างมาก โดยมีเงื่อนไขว่าต้องไม่มีการสูญเสียแพ็กเก็ตมากเกินไป

เครือข่ายเร่งความเร็ว, RSS และ GRO/TSO

บนแพลตฟอร์มคลาวด์ (Azure, Google Cloud ฯลฯ) อินเทอร์เฟซเครือข่ายแบบดั้งเดิมพึ่งพา CPU ของโฮสต์อย่างมากในการประมวลผลแต่ละแพ็กเก็ต ใช้กฎ ห่อหุ้ม และแกะห่อหุ้ม ซึ่งส่งผลให้เกิดปัญหา ภาระหนักมากต่อไฮเปอร์ไวเซอร์ เมื่อมีปริมาณการใช้งานสูงมาก จะทำให้เกิดความหน่วงที่ไม่เสถียร

นั่นคือเหตุผลที่เรียกกันว่า เครือข่ายเร่งความเร็วเทคโนโลยีเหล่านี้อิงตามเทคโนโลยีต่างๆ เช่น SR-IOV และการ์ด SmartNIC ที่ใช้ FPGA แนวคิดคือส่วนสำคัญของสแต็กเครือข่ายที่กำหนดโดยซอฟต์แวร์จะทำงานบนฮาร์ดแวร์ NIC และการรับส่งข้อมูลสามารถส่งตรงจาก VM ไปยังการ์ดได้โดยไม่ต้องผ่านสวิตช์เสมือนของโฮสต์

สิ่งนี้ให้ประโยชน์หลายประการ ข้อได้เปรียบ:

• ความหน่วงน้อยลง ประสิทธิภาพต่อเฟรมต่อวินาที (PPS) สูงขึ้น
• การสั่นสะเทือนน้อยลง
• ลดการใช้ CPU ทั้งบนเครื่องโฮสต์และเครื่องเสมือน

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

ในฝั่งระบบปฏิบัติการของเครื่องเสมือน สิ่งสำคัญคือต้องเปิดใช้งานเทคโนโลยีต่างๆ เช่นนี้ รับ Side Scaling (RSS)ซึ่งกระจายการประมวลผลแพ็กเก็ตขาเข้าไปยังคอร์ CPU หลายตัว รวมถึงการดาวน์โหลดการแบ่งส่วนและการรวมข้อมูล เช่น TSO (Transmit Segmentation Offload) และ GRO/LRO (Generic Receive Offload)ซึ่งจะช่วยลดจำนวนแพ็กเก็ตที่ซีพียูต้องประมวลผลโดยตรง

TIME_WAIT และการใช้ซ็อกเก็ตซ้ำ

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

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

เทคนิคที่ก้าวร้าวมากขึ้น ซึ่งได้รับการสนับสนุนจากเคอร์เนลบางตัว (เช่น Windows Server บน Azure) เรียกว่า การลอบสังหาร TIME_WAITหากมีคำขอ SYN ใหม่เข้ามาที่มีหมายเลขลำดับสูงกว่าหมายเลขลำดับของการเชื่อมต่อเก่าอย่างมีนัยสำคัญ ระบบสามารถบังคับให้ปิดซ็อกเก็ตในระหว่างช่วงเวลา TIME_WAIT และยอมรับการเชื่อมต่อใหม่ได้ทันที ซึ่งจะช่วยเพิ่มความสามารถในการขยายระบบ แต่หากตั้งค่าไม่ถูกต้อง อาจทำให้เกิดปัญหาได้ ปัญหาการทำงานร่วมกัน โดยใช้สแต็ก TCP ที่ค่อนข้างอนุรักษ์นิยมบางประเภท

เหตุใดเสียง ping จึงมีความสำคัญมากในชีวิตประจำวันของคุณ

นอกเหนือจากทฤษฎีแล้ว ความหน่วงมีผลกระทบโดยตรงต่อเกือบทุกสิ่งที่เราทำออนไลน์ในปัจจุบัน การมี "ความเร็ว 600 Mbps" นั้นไม่เพียงพอ หากการตอบสนองช้า ประสบการณ์การใช้งานก็จะแย่ลง ลองมาดูตัวอย่างบางกรณีที่ความหน่วงส่งผลต่อประสบการณ์การใช้งานกัน ค่า ping ที่ "ดี" นั้นสร้างความแตกต่างอย่างมาก.

เกมออนไลน์และระดับปิงที่ "เล่นได้"

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

จาก 100-300 มิลลิวินาที ปัญหาใหญ่ ๆ เริ่มปรากฏขึ้น: กระสุนมาถึงช้า การเคลื่อนไหวที่เห็นได้ล่าช้า รถ "กระเด้ง" ในเกมแข่งรถ เป็นต้น เมื่อค่า MR เกิน 300 มิลลิวินาที เกมจะกลายเป็นการทรมานมากกว่าอย่างอื่น โดยเฉพาะในเกมยิงปืน เกมแข่งรถ หรือเกมกีฬา

ประเภทของเกมก็มีอิทธิพลอย่างมากเช่นกัน เกม FPS และเกมแข่งรถ ในทางปฏิบัติแล้ว การมีค่าความหน่วงต่ำกว่า 50 มิลลิวินาทีถือเป็นสิ่งจำเป็นสำหรับการแข่งขัน และในเกมกีฬาออนไลน์ การรักษาค่าความหน่วงให้ต่ำกว่า 30-40 มิลลิวินาทีก็เป็นที่ต้องการเช่นกัน อย่างไรก็ตาม ใน เกม MMO หรือเกมวางแผนแบบผลัดกันเล่นคุณสามารถ "เอาตัวรอด" ได้ด้วยค่า ping 150-200 ms โดยไม่ทำให้เกมเล่นไม่ได้ แต่ประสบการณ์การเล่นจะไม่ลื่นไหลเท่าที่ควร หากคุณเล่นบน Windows คุณอาจสนใจที่จะเรียนรู้วิธีการนี้ ลดความล่าช้าในการป้อนข้อมูลใน Windows 11 เพื่อปรับปรุงการตอบสนองในเกมการแข่งขัน

การโทรผ่านวิดีโอ การแชร์หน้าจอ และการโทรผ่าน VoIP

ในการสนทนาทางวิดีโอผ่าน Zoom, Teams, Skype หรือแพลตฟอร์มที่คล้ายกัน ค่า Ping ก็มีความสำคัญเช่นกัน โดยในอุดมคติแล้ว ค่า Ping ควรอยู่ที่ประมาณ... 20-40 มิลลิวินาทีโดยที่การสนทนาไหลลื่นอย่างเป็นธรรมชาติโดยไม่ซ้อนทับกัน ผู้ใช้ส่วนใหญ่สามารถทนได้ถึงประมาณ 100 มิลลิวินาที แม้ว่าความล่าช้าเล็กน้อยจะเริ่มสังเกตเห็นได้แล้วขณะพูดคุย

เมื่อค่า ping เกิน ms 100คุณเริ่มขัดจังหวะอีกฝ่ายโดยไม่ตั้งใจ คำตอบจะดังเหมือนมี "เสียงสะท้อน" ชั่วคราว และความเงียบที่น่าอึดอัดจะเกิดขึ้นบ่อยครั้ง นอกจากนี้ หากการเชื่อมต่อมีแบนด์วิดท์จำกัดหรือ Wi-Fi ไม่ดี ก็จะเกิดปัญหาภาพและเสียงขาดหายเพิ่มขึ้นอีกด้วย

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

อินเทอร์เน็ตของสรรพสิ่ง ระบบบ้านอัจฉริยะ และการทำงานทางไกล

ในระบบนิเวศของ อินเทอร์เน็ตของสรรพสิ่ง (IoT) และอุปกรณ์อัจฉริยะ (ลำโพง หลอดไฟ กล้อง ปลั๊กไฟ หุ่นยนต์ เครื่องให้อาหารสัตว์เลี้ยง ฯลฯ) ความหน่วงก็มีบทบาทสำคัญเช่นกัน การเปิดไฟด้วยความล่าช้า 500 มิลลิวินาทีอาจดูไม่ร้ายแรง แต่เมื่อคุณเชื่อมโยงการกระทำหลายอย่างเข้าด้วยกันหรือโต้ตอบด้วยเสียง (Alexa, Google Assistant) มันจะสังเกตเห็นได้ชัดเจนมาก

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

ความล่าช้าและความปลอดภัย: ผลกระทบทางอ้อม

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

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

สาเหตุหลักที่ทำให้เกิดความหน่วงสูงในเครือข่ายภายในบ้าน

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

สัญญาณ WiFi ไม่ดีและมีสัญญาณรบกวน

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

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

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

เราเตอร์ที่ล้าสมัยหรือทำงานหนักเกินไป

เราเตอร์เก่าที่มีเฟิร์มแวร์ล้าสมัยหรือฮาร์ดแวร์พื้นฐานมาก อาจกลายเป็นคอขวดที่สำคัญได้ เมื่อโปรเซสเซอร์ของเราเตอร์ทำงานหนักเกินไปในการจัดการ NAT, ไฟร์วอลล์, QoS และทราฟฟิก P2P เราเตอร์ก็จะเกิดปัญหาขึ้นได้ ความล่าช้าของคิวและบัฟเฟอร์บวมแพ็กเก็ตจะสะสมอยู่ในบัฟเฟอร์ขนาดใหญ่และถูกส่งออกไปโดยมีความล่าช้าอย่างมาก ทำให้การทดสอบ ping ผิดพลาด

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

การดาวน์โหลดและอุปกรณ์อื่นๆ ที่ใช้แบนด์วิดท์

หากเครือข่ายของคุณมีอุปกรณ์หลายเครื่องที่กำลังดาวน์โหลดไฟล์ขนาดใหญ่ (P2P, การอัปเดต, การสตรีม 4K, การสำรองข้อมูลบนคลาวด์) ก็เป็นเรื่องปกติที่จะเกิดขึ้น ค่า ping ของคุณพุ่งสูงขึ้นปัญหาไม่ได้อยู่ที่ "หน่วยความจำหมด" มากนัก แต่อยู่ที่ว่าเราเตอร์จัดการคิวขาออกอย่างไร

วิธีแก้ปัญหานี้เกี่ยวข้องกับสองแนวทาง:

• ในอีกด้านหนึ่ง การควบคุมการดาวน์โหลดในพื้นหลัง (พีซี มือถือ คอนโซล NAS…) ให้ดีขึ้นก็เป็นสิ่งสำคัญ
• ในทางกลับกัน ให้เปิดใช้งานและปรับแต่งให้เหมาะสม QoS และการป้องกัน Bufferbloat จากเราเตอร์เพื่อให้การรับส่งข้อมูลแบบโต้ตอบ (เกม, VoIP, การโทรผ่านวิดีโอ) มีลำดับความสำคัญเหนือกว่าการดาวน์โหลดขนาดใหญ่

VPN, พร็อกซี, ไฟร์วอลล์ และโปรแกรมที่ทำงานอยู่เบื้องหลัง

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

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

มัลแวร์และอุปกรณ์ที่ถูกบุกรุก

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

เครื่องมือสำหรับวัดค่าความหน่วงและตรวจจับปัญหา

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

การทดสอบ ping และ traceroute ขั้นพื้นฐาน

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

ถ้าคุณเพิ่ม -t บน Windows (ping 8.8.8.8 -tคุณสามารถปล่อยให้โปรแกรมทำงานต่อไปเพื่อดูว่ามีสัญญาณผิดปกติ การขาดหาย หรือการกระตุกหรือไม่ และด้วย traceroute/tracert คุณตรวจสอบว่าแพ็กเก็ตของคุณผ่านจุดใดบ้าง และความหน่วงเริ่มเพิ่มขึ้นอย่างน่าสงสัย ณ จุดใด

เครื่องมือขั้นสูง: WinMTR, PingPlotter และอื่นๆ

โปรแกรมเช่น วินMTR เครื่องมือเหล่านี้รวมการตรวจสอบเส้นทาง (traceroute) และการส่งสัญญาณต่อเนื่อง (ping) เข้าด้วยกัน โดยแสดงเปอร์เซ็นต์การสูญเสียสัญญาณ และเวลาตอบสนองต่ำสุด เฉลี่ย และสูงสุดสำหรับแต่ละจุดเชื่อมต่อ เครื่องมือเหล่านี้มีประโยชน์มากในการระบุว่าปัญหาอยู่ที่จุดเชื่อมต่อแรกของ ISP ของคุณ โครงข่ายหลักระดับกลาง หรือเซิร์ฟเวอร์เกมเอง

สาธารณูปโภคอื่น ๆ เช่น เครือข่าย LatencyView (NirSoft) เป็นโปรแกรมที่วัดค่าความหน่วงแฝงจริงของการเชื่อมต่อ TCP ที่เปิดโดยพีซีของคุณ นอกจากนี้ยังมีชุดโปรแกรมอื่นๆ เช่น เครื่องมือ NetScan ประกอบด้วยโปรแกรมแสดงผลข้อมูลการ ping แบบกราฟิก, โปรแกรมสแกนพอร์ต, โปรแกรมตรวจสอบเส้นทางการเชื่อมต่อ (traceroute) และโปรแกรมตรวจสอบ DNS ครบจบในโปรแกรมเดียว

วัดค่า Ping บนมือถือ: แอปพลิเคชันสำหรับ Android และ iOS

บนสมาร์ทโฟนและแท็บเล็ต คุณยังสามารถวัดค่าความหน่วงได้โดยใช้แอปต่างๆ เช่น Fing, He.net Network Tools, NetX หรือใช้เครื่องมือ ping เฉพาะบน iOS เครื่องมือเหล่านี้เหมาะอย่างยิ่งสำหรับการตรวจสอบว่าเป็นปัญหาเกี่ยวกับ Wi-Fi ในห้องใดห้องหนึ่ง เครือข่ายมือถือ หรือคุณภาพสัญญาณโทรศัพท์บ้านที่ไม่ดี

การเพิ่มประสิทธิภาพ TCP/IP ขั้นสูงบนเซิร์ฟเวอร์และระบบคลาวด์

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

การตั้งค่าเคอร์เนลและสแต็ก TCP ใน Linux

บนระบบ Linux โดยใช้ sysctl และเครื่องมืออย่าง tc o ethtool คุณสามารถใช้การปรับแต่งขั้นสูงได้ เช่น:

• ลดค่า RTO ขั้นต่ำลง (net.ipv4.tcp_rto_min_us) ให้เป็นค่าที่ปลอดภัย เช่น 5000 ไมโครวินาที (5 มิลลิวินาที) บนเครือข่ายภายในที่มีความหน่วงต่ำ เพื่อให้สามารถกู้คืนจากการสูญเสียแพ็กเก็ตได้เร็วขึ้น
• กระตุ้น การจัดคิวอย่างเป็นธรรม (FQ) กับ tc qdisc replace dev <iface> root fq. เพื่อกระจายแบนด์วิดท์ระหว่างการรับส่งข้อมูลให้ดียิ่งขึ้น และหลีกเลี่ยงการใช้แบนด์วิดท์มากเกินไปจากจุดเชื่อมต่อเดียว
• ปิดการใช้งาน เริ่มต้นช้าหลังจากหยุดกิจกรรม (net.ipv4.tcp_slow_start_after_idle=0) บนเซิร์ฟเวอร์ที่ใช้การเชื่อมต่อแบบถาวร เพื่อไม่ให้เริ่มต้นใหม่จากแบนด์วิดท์ที่ต่ำมากทุกครั้งที่ตื่นจากโหมดพักเครื่อง
• ปิดใช้งานส่วนที่มีปัญหาของ ไฮสตาร์ท (การตรวจจับขบวน ACK) ใน Cubic TCP เพื่อป้องกันการแจ้งเตือนผิดพลาดเรื่องความแออัดที่อาจทำให้การขยายขนาดหน้าต่างช้าลง
• เพิ่มขึ้น บัฟเฟอร์ TCP (tcp_rmem, tcp_wmem, rmem_max, wmem_maxเพื่อให้สามารถรักษาอัตราการรับส่งข้อมูลสูงบนลิงก์ที่มีค่า RTT สูง ป้องกันไม่ให้ซ็อกเก็ตมีหน่วยความจำไม่เพียงพอ
• ขีดจำกัด tcp_notsent_lowat วิธีนี้จะช่วยป้องกันไม่ให้ข้อมูลที่ยังไม่ได้ส่งสะสมอยู่ในเคอร์เนลมากเกินไป ซึ่งจะช่วยปกป้องระบบจากการใช้หน่วยความจำมากเกินไป
• ทำให้สามารถ ฮาร์ดแวร์ GRO/LRO บน NIC ที่เข้ากันได้ (ethtool -K <iface> rx-gro-hw onเพื่อจัดกลุ่มแพ็กเก็ตและลดภาระ CPU ต่อการขัดจังหวะแต่ละครั้ง

MTU ขนาดใหญ่และเครือข่ายประสิทธิภาพสูง

ในเครือข่ายคลาวด์ภายใน (เช่น Google Cloud VPC) ที่มีการให้การสนับสนุน MTU ขนาดใหญ่พิเศษ สูงสุดประมาณ 8900 ไบต์ขอแนะนำอย่างยิ่งให้เพิ่มค่า MTU (เช่น เป็นประมาณ 4082 ไบต์ ซึ่งเข้ากันได้กับหน่วยความจำขนาด 4 KB) เพื่อลดจำนวนแพ็กเก็ตที่ประมวลผลต่อวินาทีและเพิ่มประสิทธิภาพการทำงานของ CPU

อย่างไรก็ตาม คุณต้องระมัดระวังเรื่องการรับส่งข้อมูลที่ส่งออกไปยังอินเทอร์เน็ตหรือผ่าน VPN: ในกรณีนั้น ควรคงค่า MTU มาตรฐานไว้ที่ 1500 หรือปรับค่าตามแต่ละเส้นทาง (ip route change กับ mtu y advmssเพื่อป้องกันไม่ให้การสื่อสารภายนอกเกิดการแตกกระจายหรือสูญหายเนื่องจากแพ็กเก็ตมีขนาดใหญ่เกินไป

เว็บเซิร์ฟเวอร์, HTTP/2/3 และการแคช

บนเว็บเซิร์ฟเวอร์ (Nginx, Apache ฯลฯ) นอกจากการปรับแต่ง TCP แล้ว คุณยังสามารถลดความหน่วงที่รับรู้ได้ลงอย่างมากโดยการเปิดใช้งาน HTTP/2 และ HTTP/3 (QUIC)ซึ่งช่วยให้สามารถส่งคำขอหลายรายการผ่านการเชื่อมต่อเดียว และลดต้นทุนในการเริ่มต้นการเชื่อมต่อ

การเปิดใช้งาน การบีบอัดแบบ GZIP หรือ Brotli, ใช้ แคชในหน่วยความจำ (Redis, Memcached) ย่อขนาดไฟล์ CSS/JS และให้บริการเนื้อหาคงที่ผ่านทาง เครือข่ายกระจายสัญญาณ (CDN) ที่มีจุดเชื่อมต่อใกล้เคียง สำหรับผู้ใช้ ทุกมิลลิวินาทีที่คุณประหยัดได้ใน TTFB (Time To First Byte) และ RTT ของเครือข่าย จะส่งผลให้เว็บไซต์ตอบสนอง "เร็วขึ้น" ในสายตาของผู้เข้าชม

การตรวจสอบอย่างต่อเนื่องและตัวชี้วัดความหน่วง

สุดท้ายนี้ หากคุณจริงจังกับเรื่องประสิทธิภาพ คุณจำเป็นต้องวัดผลอย่างต่อเนื่อง เครื่องมือต่างๆ เช่น ApacheBench, wrk, JMeter หรือชุดเครื่องมือตรวจสอบ (Prometheus + Grafana, New Relic, Datadog…) ช่วยให้คุณสามารถตรวจสอบได้ RTT, TTFB, เปอร์เซ็นไทล์ของความหน่วง, ปริมาณงาน และอัตราข้อผิดพลาด ภายใต้ภาระ

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

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