ฉันปิดการตั้งค่าที่ซับซ้อนของรีจิสทรี Windows และการตอบสนองของการ ping ของฉันในที่สุดก็ดูมีความเร็วขึ้น

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

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

อัลกอริทึมของเนเกิลคือเหตุผลที่ TCP ของคุณรู้สึกช้า

การปรับแต่งเก่าที่รวมข้อมูลของคุณแทนที่จะส่งทันที

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

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

ด้วยตัวมันเอง ฟังดูสมเหตุสมผล แต่มีการปรับแต่งอีกตัวหนึ่งที่ทำงานควบคู่กันอยู่เรียกว่า delayed ACKs ซึ่งฝั่งผู้รับจะรอประมาณ 100 ถึง 200 มิลลิวินาทีก่อนส่งการยืนยัน หวังว่าจะสามารถแนบไปกับข้อมูลที่ส่งออก เมื่อการรวมข้อมูลของ Nagle ที่ฝั่งผู้ส่งเจอกับ delayed ACKs ที่ฝั่งผู้รับ จะเกิดภาวะ deadlock ของความสุภาพ ผู้ส่งจะไม่ส่งเพราะกำลังรอการยืนยัน ผู้รับจะไม่ส่งการยืนยันเพราะกำลังรอแนบข้อมูล ข้อความเล็ก ๆ แต่ละข้อความต้องรอเพิ่มอีก 100 ถึง 200 มิลลิวินาที ซึ่งไม่มีส่วนเกี่ยวข้องกับความเร็วเครือข่ายจริงของคุณ

ค่าระเบียนสองค่าจะแก้ไขมันได้ทันที

การปิดใช้งานทั้งการรวมแพ็กเกจฝั่งผู้ส่งและการหน่วงเวลาการยืนยันการรับฝั่งผู้รับ

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

ก่อนที่จะทำการเปลี่ยนแปลงใด ๆ การสร้างจุดคืนค่าระบบเป็นความคิดที่ดีเพื่อให้คุณสามารถย้อนกลับได้หากจำเป็น ในการปรับแต่ง ให้เปิด Registry Editor โดยกด Win + R พิมพ์ regedit และกด Enter จากนั้นไปที่ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces คุณจะเห็นหลาย subkeys ที่มี ID string ยาว ๆ แต่ละอันแทนการ์ดเครือข่ายหนึ่งตัว ในการหาว่าอันไหนเป็นของคุณ ให้เปิด Command Prompt และรัน ipconfig เพื่อดูที่อยู่ IP ปัจจุบันของคุณ จากนั้นคลิกไปที่ subkeys จนกว่าคุณจะพบอันที่ DhcpIPAddress หรือ IPAddress ตรงกับ

เมื่อคุณพบตัวแปลงสัญญาณที่ถูกต้องแล้ว ให้คลิกขวาในบานหน้าต่างด้านขวา เลือก ใหม่ > ค่ DWORD (32 บิต) และสร้างค่าชื่อ TcpNoDelay ตั้งค่าเป็น 1 จากนั้นสร้างค่า DWORD อีกค่าและตั้งชื่อว่า TcpAckFrequency และตั้งค่าเป็น 1 เช่นกัน ปิดโปรแกรมแก้ไขรีจิสทรีแล้วรีสตาร์ทคอมพิวเตอร์ของคุณ

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

เกม UDP จะไม่ได้ประโยชน์ และนั่นคือเกือบทั้งหมด

ทำไมการปรับแต่งนี้จึงช่วยได้เฉพาะทราฟฟิกที่ใช้ TCP

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

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

ค่า ping ของคุณในเกมก็ขึ้นอยู่กับระยะทางจริง การกำหนดเส้นทางของผู้ให้บริการอินเทอร์เน็ต และความแออัดตามเส้นทางไปยังเซิร์ฟเวอร์ ไม่มีการปรับแต่งรีจิสทรีฝั่งไคลเอนต์ใดที่สามารถทำให้เส้นทางนั้นสั้นลงได้ ถ้าค่า ping ของคุณสูง มีการตั้งค่า Windows 11 อื่น ๆ ที่ควรเปลี่ยนแปลงซึ่งสามารถลดความล่าช้าที่รู้สึกได้ แต่ Nagle's Algorithm ไม่ใช่อุปสรรคสำคัญสำหรับเกม UDP.

อินเทอร์เน็ตแย่ก็ยังคงเป็นอินเทอร์เน็ตแย่

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

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