ตัวเลือกสำหรับการจัดการแบนด์วิดท์บนการเชื่อมต่ออินเทอร์เน็ตที่ใช้ร่วมกัน


13

หลักฐาน:

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

นี่คือตรงไปตรงมาในตัวเอง - ตั้งค่าเราเตอร์ที่มีเครือข่ายย่อยสำหรับแต่ละครัวเรือน (VLANs หรือพอร์ตทางกายภาพ), ปิดกั้นการรับส่งข้อมูลระหว่างพวกเขาและกำหนดค่าโมเด็มเพื่อเส้นทางไปยังเครือข่ายย่อยเหล่านั้นหรือตั้งค่า NAT สองครั้ง

ปัญหา:

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

ตัวอย่างเช่นสมมติว่ามี 4 ครัวเรือนที่แชร์การเชื่อมต่อแบบ 12Mbit / s หากหนึ่งในนั้นคือการดาวน์โหลด / การสตรีม / อะไรก็ตามพวกเขาควรจะสามารถใช้ 12Mbit / s เต็ม (หรือใกล้พอ) หาก 2 ครัวเรือนกำลังใช้การเชื่อมต่อพวกเขาควรได้รับ 6Mbit / s โดยไม่คำนึงว่าครอบครัวหนึ่งกำลังดาวน์โหลด 1 ไฟล์และอีก 11 ไฟล์ (โดยไม่มีการจัดการแบนด์วิดท์ใด ๆ ไฟล์แต่ละไฟล์จะดาวน์โหลดที่ประมาณ 1Mbit / s) 3 ครัวเรือน รับ 4Mbit / s ทุก ๆ

สิ่งที่ฉันทำไปแล้ว:

ตำแหน่งที่ดีที่สุดในการใช้นโยบายเช่นนี้ (สำหรับดาวน์สตรีม) จะอยู่ที่ปลายอีกด้านหนึ่งของท่อแคบ ๆ เช่นที่ ISP เห็นได้ชัดว่าเป็นไปไม่ได้ในกรณีนี้ดังนั้นจึงเป็นการดีที่จะสามารถประมาณค่าได้ แต่อย่างไร มีเราเตอร์นอกชั้นวางที่รองรับบางสิ่งเช่นนี้หรือไม่? ฉันสามารถกำหนดค่ากล่อง Linux หรือ BSD เพื่อทำมันได้หรือไม่ ไม่จำเป็นต้องเป็นแบบกระสุน - เซิร์ฟเวอร์ TCP ที่ทำงานผิดปกติหรือบริการ UDP ที่ก้าวร้าวอาจหลีกเลี่ยงสิ่งที่ฉันสามารถทำได้ในตอนท้ายของฉัน - แต่ควรทำงานในกรณีทั่วไปของการรับส่งข้อมูลส่วนใหญ่ประกอบด้วย RFC-compliant จำนวนมาก การเชื่อมต่อ TCP

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

มีข้อมูลจำนวนมากที่เขียนไม่ดี / สำรอกซ้ำ ๆ / ข้อมูลที่ไม่ถูกต้องเกี่ยวกับปริมาณข้อมูลบนเว็บ เอกสารเกี่ยวกับฮาร์ดแวร์ของเราเตอร์นั้นไม่เจาะจงอย่างยิ่งดังนั้นฉันจึงดูเหมือนจะวิ่งวนเป็นวงกลม

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

มีวิธีทำสิ่งที่ฉันถามหรือไม่ ฉันจะทำผิดหรือเปล่า? ฉัน (หรือมากกว่าครัวเรือนที่มีปัญหา) ยินดีจ่ายเงินให้กับเรา - ไม่ว่าจะเป็นเราเตอร์ / อุปกรณ์แบบ off-the-shelf หรือกล่องทั่วไปเพื่อรัน Linux หรือ BSD distro

คำตอบ:


4

ถ้าฉันจะสร้างบางสิ่งบางอย่างเพื่อแก้ปัญหานี้ฉันจะตั้งค่านี้:

พวกเรากำลังจะยกตัวอย่างคอมพิวเตอร์ 4 เครื่องที่ใช้ลิงค์เดียว เครือข่ายจะมีรูปร่างดังนี้:

{ ISP }=========[ SOHO router] ===LAN1=== [eth0 |Linux Box| eth1] ===LAN2=== Home Desktops/Laptops

สมมติว่าคุณใช้การกำหนดที่อยู่ IP แบบคงที่ใน LAN2:

Linux Box 192.168.1.1
Home 1    192.168.1.11
Home 2    192.168.1.12
Home 3    192.168.1.13
Home 4    192.168.1.14

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

ต้องแน่ใจว่าจัดการกับกรณีที่ไม่มีโฮสต์ออนไลน์

แบ่งแบนด์วิดท์ทั้งหมดด้วยจำนวนโฮสต์ที่เชื่อมต่อ (12Mb สำหรับ 1, 6Mb สำหรับ 2, 4Mb สำหรับ 3, 3Mb สำหรับ 4)

ถัดไปใช้ tc กับอัลกอริทึม HTB เพื่อ จำกัด แบนด์วิดท์ของแต่ละที่อยู่บนอุปกรณ์ WAN-side ขั้นแรกสร้างคลาสรูท:

DEV="eth0"
TC="/sbin/tc"
TOT_BW=12
$TC qdisc add dev $DEV root handle 1: htb default 99

จากนั้นเพิ่มคลาสสำหรับแต่ละ "ไคลเอนต์" (ที่นี่ตัวอย่างเช่น 3 ไคลเอนต์)

NB_CLT=3
CLT_BW=$(($TOT_BW/$NB_CLT))mbit
for i in seq $NB_CLT
do
    $TC class add def $DEV parent 1: classid 1:$i htb rate $CLT_BW ceil $CLT_BW burst 15k cburst 1500
    $TC filter add dev $DEV protocol ip parent 1:0 prio 1 flowid 1:$i u32 \
     match ip dst 192.168.1.1$i/32 \
     match ip src [Router IP in LAN1]/32
done

(สคริปต์ข้างต้นไม่ได้ทดสอบทั้งหมดและไม่พิมพ์ปราศจากข้อผิดพลาด)

ตอนนี้คุณยังคงต้องสคริปต์อย่างถูกต้องที่จะเรียกใช้ทุกนาทีและต่ออายุถัง / ตัวกรองทุกครั้งที่มีโฮสต์ใหม่ขึ้นหรือลง

ฉันหวังว่าจะชี้ให้คุณในทิศทางที่ถูกต้องโชคดี

ทางเลือกอื่น

ติดตั้งซอฟต์แวร์ QoS แบบโลคัลบนโฮสต์ทั้งหมดเพื่อ จำกัด แบนด์วิดท์ I Personnaly ใช้ NetLimiter (ฟรี)


ปัญหาเกี่ยวกับวิธีการของฉันคือโฮสต์ทุกตัวลดแบนด์วิดท์ของผู้อื่นแม้ว่าพวกเขาจะไม่ได้ใช้งานร่วมกันทั้งหมด แต่การออกแบบสิ่งที่บังคับให้แบ่งปันเฉพาะเมื่อความต้องการสูง ... ยาก
mveroone

2

OpenWRT ดูเหมือนจะให้การสนับสนุนแม้ว่าฉันจะไม่เคยใช้มันมาก่อน คุณสามารถที่จะดูที่การควบคุมการจราจรทางเครือข่ายหน้าในเว็บไซต์ของพวกเขาและโดยเฉพาะอย่างยิ่งตัวอย่างที่สอง: การแบ่งปันแบนด์วิดธ์ที่เรียบง่ายธรรมดา (aka การปรับการจราจร) กับ HTB สิ่งนี้เกี่ยวข้องกับการเรียก qdisc อย่างง่ายๆดังนั้นกล่อง Linux ก็สามารถทำได้


ฉันสังเกตเห็นว่าตัวอย่างนั้นใช้สำหรับด้านการอัปโหลด ขณะนี้ฉันกำลังอ่านวิธีการของฉันผ่านทางLinux Advanced Routing & Traffic HOWTOซึ่งดูเหมือนจะค่อนข้างมีแนวโน้มและหวังว่าฉันจะเข้าใจtcกฎเหล่านี้ทั้งหมด Traffic Shaper ของ Linux นั้นดูดีอยู่
pmdj

0

การตั้งค่าที่อธิบายไว้ใน/superuser//a/1210164/257859ทำเช่นนั้นทุกประการ:

[... ] คิวกระจาย BW ที่ จำกัด อย่างสม่ำเสมอระหว่างไคลเอนต์ LAN ทั้งหมด (LAN IPs ให้แม่นยำ)


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

@DavidPostill ฉันคิดถึงการลงคะแนนให้ใกล้เคียงกัน แต่ลังเลเพราะนี่เป็นคำถามอายุ 3 ปี ฉันยังสืบค้น meta.superuser และพบว่าเป็นคำถามที่เกี่ยวข้องในmeta.superuser.com/questions/3524/... หลังจากอ่านเมตาฉันคิดว่าสถานการณ์มีความซับซ้อน (ฉันมีคำตอบสำหรับคำถามสองข้อที่มีการอภิปรายเพียงพอในแต่ละข้อ) และการออกคำตอบสั้น ๆ อย่างน้อยก็ดูเหมือนว่า "ไม่เลว" ฉันเปิดใจรับฟังความคิดของคุณ
ndemou
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.