อัตราการรับส่งข้อมูลขาเข้า

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

มีการเชื่อมโยงใด ๆ ระหว่างTCP ช้าเริ่มต้นและอัตราการรับส่งข้อมูลขาเข้า? เป็นไปได้ไหมที่จะใช้วิธีที่อธิบายโดยการเริ่มต้นช้าเพื่อ จำกัด อัตราการส่งแพ็กเก็ตของผู้ส่งจริง?

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

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

ดาวน์โหลดผู้จัดการส่วนใหญ่มีแนวโน้มการทำงานตามที่ได้อธิบายในที่กระดาษหยด

กระบวนการที่ใช้ซ็อกเก็ต BSD อาจดำเนินการ จำกัด อัตราของตัวเอง สำหรับการ จำกัด อัปสตรีมแอ็พพลิเคชันสามารถทำได้โดยเพียง จำกัด อัตราข้อมูลที่เขียนลงในซ็อกเก็ต ในทำนองเดียวกันสำหรับการ จำกัด ดาวน์สตรีมแอปพลิเคชันอาจ จำกัด อัตราข้อมูลที่อ่านจากซ็อกเก็ต อย่างไรก็ตามเหตุผลที่งานนี้ไม่ชัดเจนทันที เมื่อแอปพลิเคชันละเลยที่จะอ่านข้อมูลบางอย่างจากซ็อกเก็ตซ็อกเก็ตของมันจะรับบัฟเฟอร์เต็ม สิ่งนี้จะทำให้ TCP ที่ได้รับโฆษณาหน้าต่างตัวรับสัญญาณขนาดเล็กลง (rwnd) สร้างแรงกดดันย้อนกลับบนการเชื่อมต่อ TCP พื้นฐานซึ่ง จำกัด การไหลของข้อมูล ในที่สุดเอฟเฟกต์ "แบบหยดลง" นี้จะบรรลุอัตราแบบ end-to-end จำกัด เอฟเฟกต์นี้อาจใช้เวลาสักครู่ทั้งนี้ขึ้นอยู่กับการบัฟเฟอร์ในเลเยอร์เครือข่ายทั้งหมด

หากบางครั้งคุณจำเป็นต้อง จำกัด อัตราโปรแกรมเดียวบนระบบยูนิกซ์เป็นทางออกที่ง่ายคือหยด Traffic Shaping tcจริงเช่นคุณจะดำเนินการบนเกตเวย์สามารถทำได้ด้วย นี่คือเอกสารในบทที่ 9 การจัดคิวงานสำหรับการจัดการแบนด์วิดท์ของ HOWTO การควบคุมขั้นสูงและการกำหนดเส้นทาง Linux

ในกรณีของโมเด็ม 56k เมื่อเทียบกับสาย 4 Mbps DSl มี (โดยปกติ) ไม่มีการสร้างความแตกต่างความเร็วมันเป็นเพียงความแตกต่างในความเร็วของการเชื่อมโยง

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

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

เส้นทางเดียวที่เป็นไปได้คือการกำหนดปริมาณการรับส่งข้อมูลจากอินเทอร์เน็ตทางด้าน LAN ของเราเตอร์ DSL ของคุณเนื่องจาก ณ จุดนั้นคุณจะต้องสร้างพอร์ต egress

ฉันไม่สามารถตอบได้ว่าทำไมคุณถึงไม่พบวิธีแก้ปัญหาที่อนุญาตให้สร้างข้อมูลขาเข้า (และไม่ทราบว่าอยู่ด้านบนสุดของหัวของฉัน) แต่เป็นวิธีที่ผู้ส่งรู้วิธีที่ผู้รับสามารถรับข้อมูลได้อย่างรวดเร็ว:

การออกแบบพื้นฐานของ TCP / IP นั้นสำหรับทุก ๆ แพ็กเก็ตที่ต้นทางส่งไปยังปลายทางมันต้องรอให้ปลายทางตอบกลับ (ด้วยACKแพ็กเก็ต) โดยบอกว่าได้รับแพ็กเก็ตแล้ว

ดังนั้นหากคุณมีผู้ส่ง 4Mbps และตัวรับสัญญาณ 56Kbps ผู้ส่งจะต้องนั่งรอระหว่างการส่งแพ็กเก็ตเพื่อให้ผู้รับตอบกลับแต่ละแพ็คเก็ต (มีรายละเอียดทางเทคนิคบางอย่างเพื่อลดค่าใช้จ่ายนี้ ระดับ)

แล้วจะเกิดอะไรขึ้นหากผู้ส่งส่งข้อมูล 56Kbps ไปแล้วลองส่งอีกเล็กน้อย

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

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

คุณสามารถทำได้ด้วยอินเตอร์เฟส ifb

ด้วยส่วนต่อประสาน ifb คุณสามารถกำหนดเส้นทางการไหลของ eth0 (หรืออะไรก็ตาม) ไปยัง egress ใน ifb0 (ตัวอย่าง) และใช้กฎข้อ จำกัด ที่นั่น

ตรวจสอบ URL ของ Linux Foundation นี้: http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

และสคริปต์นี้ที่ จำกัด การเข้ามาใช้และการสังเกต bandwight: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

ตรวจสอบ wondershaper: http://lartc.org/wondershaper/

เกี่ยวกับการรับส่งข้อมูล:

This is slightly trickier as we can't really influence how fast the internet
ships us data. We can however drop packets that are coming in too fast,
which causes TCP/IP to slow down to just the rate we want. Because we don't
want to drop traffic unnecessarily, we configure a 'burst' size we allow at
higher speed.

Now, once we have done this, we have eliminated the downstream queue totally
(except for short bursts), and gain the ability to manage the upstream queue
with all the power Linux offers.

ใช้ UFW (กำแพงไฟที่ไม่ซับซ้อน) http://ubuntuforums.org/showthread.php?t=1260812

เธรดนี้แสดงตัวอย่างง่ายๆที่ค่าเริ่มต้นสำหรับ IP ที่มี 6 Hit ภายใน 30 วินาทีถูกปฏิเสธ:

sudo ufw limit ssh/tcp

นอกจากนี้ยังมีคำสั่ง 'ขั้นสูง' เพิ่มเติมด้วยค่าที่ระบุสำหรับเวลาและจำนวนการเข้าชม

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP