เพื่อนร่วมห้องเชื่อมต่ออินเทอร์เน็ตด้วยการดูวิดีโอจากเว็บไซต์จีน QoS สามารถแก้ไขปัญหาได้หรือไม่?


7

เพื่อนร่วมห้องของฉันเป็นนักเรียนต่างชาติจากประเทศจีนและชอบดูรายการทีวีจีนออนไลน์โดยใช้เว็บไซต์ที่ตั้งอยู่ในภูมิภาคนั้น (เราอยู่ที่ชายฝั่งตะวันออกของสหรัฐ) แต่มันทำให้เครือข่ายแฝงของเรายิงสูงขึ้นอย่างน่าหัวเราะและกระทบประมาณ 400ms เมื่อกระตุก 4.2.2.2 และอยู่ในช่วง 100 ถึง 1,000+ (ปกติจะอยู่ที่ใดก็ได้จาก 20-40ms) น่าเสียดายที่เธอต้องการเล่นเป็นใบ้เกี่ยวกับปัญหาดังนั้นฉันจึงต้องหาวิธีแก้ไขปัญหานี้ที่ไม่ต้องการการปฏิบัติตามของเธอ

เราเตอร์ปัจจุบันของฉัน (Netgear N150 WPN824N) ไม่รองรับ QoS หรือเฟิร์มแวร์แบบกำหนดเองที่ได้รับความนิยมที่มี (AFAIK) ดังนั้นฉันจึงพิจารณาซื้อเราเตอร์ที่มีราคาแพงกว่าด้วย QoS ในตัวหรือเราเตอร์ราคาถูกกว่าที่รองรับ Tomato, DD-WRT หรืออย่างอื่น แต่ฉันไม่แน่ใจว่าสิ่งที่เป็นปัญหาหรือ QoS จะช่วยได้หรือไม่ (เช่นสิ่งที่เราต้องการรู้ก่อนใช้จ่ายเงิน) เว็บไซต์ที่มีแนวโน้มว่าจะเป็นผู้ร้ายมากที่สุดคือ tv.sohu.com ไม่ใช่ภาษาอังกฤษและส่วนใหญ่มีเนื้อหาวิดีโอที่ถูก จำกัด ในภูมิภาค ดังนั้นทั้งหมดที่ฉันสามารถทดสอบได้คือความหน่วงของเว็บไซต์ (ซึ่งอยู่ห่างจากที่ฉันอาศัยอยู่ประมาณ 350ms) ฉันไม่ทราบว่าเป็นปัญหาเกี่ยวกับแบนด์วิดท์หรือหากไซต์ใช้โปรโตคอลที่กำหนดเองแปลก ๆ บางอย่างหรืออาจมีปัจจัยอื่นที่นี่ ฉันไม่ใช่คนเครือข่ายดังนั้นนอกเหนือจากการใช้แบนด์วิธสูงฉัน

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

คำตอบ:


5

เพื่อนร่วมห้องเชื่อมต่ออินเทอร์เน็ตด้วยการดูวิดีโอจากเว็บไซต์จีน QoS สามารถแก้ไขปัญหาได้หรือไม่?

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

สิ่งที่คุณต้องการคือการจัดการคิวที่ใช้งานอยู่

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

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

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

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

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

สิ่งที่นักวิจัยพยายามทำมานานหลายปี (ซึ่งเราเพิ่งประสบความสำเร็จเพียงบางส่วนเมื่อเร็ว ๆ นี้เมื่อเดือนพฤษภาคม 2555) คือการออกแบบอัลกอริทึมที่ใช้การจัดการคิวแบบแอคทีฟที่เหมาะสม (AQM) โดยไม่มีการกำหนดค่าผู้ใช้ จะเสียเวลาและน่ารำคาญ) เพียงแค่ "bullet เวทมนตร์" ที่ปรับขนาดคิวให้เหมาะสมเพื่อลดการสูญหายของแพ็กเก็ตและลดเวลาแฝงในเวลาเดียวกัน

จนถึงตอนนี้สิ่งเดียวที่เราพบว่าประสบความสำเร็จอย่างมากในเราเตอร์โฮมคือ Controlled Delay (CoDel) Active Queue Management ซึ่งเป็นส่วนเสริมล่าสุดของเคอร์เนล Linux

CoDel มีประโยชน์มากเพราะควบคุมการหน่วงเวลา (เวลาแฝง) ของแพ็กเก็ต วิธีมันไม่นี้เป็นบิตทางเทคนิคเกินไปสำหรับคำถามนี้

ลิงก์บางอย่างใน CoDel เพื่อให้คุณสามารถอ่านได้:

CoDel บน bufferbloat.net

CeroWRT

บทความของ Jim Gettys ใน codel

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

CoDel รวมกับ QoS, la CeroWRT บนเราเตอร์ของคุณเป็นวิธีที่ดีที่สุด


0

หากคุณเป็นบวก 100% ว่าปัญหาเกิดขึ้นเฉพาะเมื่อเพื่อนร่วมห้องของคุณกำลังสตรีมวิดีโอ QoS จะช่วยคุณแก้ปัญหานี้

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

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


2
QoS เพียงอย่างเดียวไม่มีประสิทธิภาพ มันต้องการการจัดการคิวที่ใช้งานอยู่ด้วย
allquixotic

0

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.