आने वाले ट्रैफ़िक को सीमित करना

Question

मैंने कभी नहीं समझा कि आने वाले ट्रैफ़िक को रेट-लिमिट करना संभव है या नहीं । मुझे पता है कि पैकेट भेजने के रिमोट सर्वर की दर को नियंत्रित करने के लिए कोई प्रत्यक्ष तरीका नहीं है (जब तक कि आप दोनों समापन बिंदुओं के नियंत्रण में नहीं हैं), लेकिन इस सीमा को ध्यान में रखते हुए, कैसे डाउनलोड प्रबंधक मुझे सफलतापूर्वक डाउनलोड गति सीमा निर्धारित करने की अनुमति देते हैं ?

क्या टीसीपी धीमी-शुरुआत और दर-सीमित आने वाले यातायात के बीच कोई लिंक है? क्या पैकेट भेजने की दर को कृत्रिम रूप से सीमित करने के लिए धीमी शुरुआत से वर्णित विधियों का उपयोग करना संभव है?

एक अतिरिक्त विचार के रूप में, यह ध्यान दिया जाना चाहिए कि जिस सर्वर पर मैं ट्रैफ़िक को आकार देना चाहता हूं, वह PPPoE कनेक्शन स्थापित करता है, और बाकी नेटवर्क के लिए एक राउटर के रूप में कार्य करता है।

अद्यतन: इस प्रकार अब तक के उत्तरों ने मेरे द्वारा पूछे गए प्रश्नों का उचित अवलोकन किया है, लेकिन मुझे अभी भी नहीं पता है कि डाउनलोड प्रबंधक आने वाले ट्रैफ़िक को कैसे सीमित करने में सक्षम हैं, और अधिक विशेष रूप से, क्या एक समान रणनीति को लागू करना संभव है लिनक्स गेटवे बॉक्स।

Comments

नि: शुल्क डाउनलोड प्रबंधक शायद अपने स्वयं के अपलोड सर्वर और टोरेंट क्लाइंट का उपयोग करता है जो ज्यादातर कनेक्शन का उपयोग करते हैं। इसके अलावा, क्या आपने 'QOS' में देखा है?

— डच युन्नान

अधिकांश डाउनलोड प्रबंधक केवल एसीके को वापस भेजते हैं, जिससे डेटा की आवक धीमी हो जाती है।

— क्रिस एस

Answer 1

ट्रिकल पेपर में बताए अनुसार डाउनलोड मैनेजर सबसे अधिक काम करते हैं ।

बीएसडी सॉकेट्स का उपयोग करने वाली एक प्रक्रिया अपनी दर सीमित कर सकती है। अपस्ट्रीम लिमिटिंग के लिए, एप्लीकेशन केवल सॉकेट को लिखे गए डेटा की दर को सीमित करके ऐसा कर सकता है। इसी तरह, डाउनस्ट्रीम लिमिटिंग के लिए, एक एप्लिकेशन सॉकेट से पढ़े जाने वाले डेटा की दर को सीमित कर सकता है। हालांकि, इस काम का कारण तुरंत स्पष्ट नहीं है। जब एप्लिकेशन सॉकेट से कुछ डेटा को पढ़ने की उपेक्षा करता है, तो इसका सॉकेट बफ़र्स को भरता है। यह बदले में टीसीपी प्राप्त करने का कारण होगा एक छोटे रिसीवर विंडो (आरडब्ल्यूएन) का विज्ञापन करना, अंतर्निहित टीसीपी कनेक्शन पर वापस दबाव बनाना और इस प्रकार इसके डेटा प्रवाह को सीमित करना। आखिरकार यह "ट्रिकल-डाउन" प्रभाव एंड-टू-एंड रेट लिमिट को प्राप्त करता है। नेटवर्क स्टैक की सभी परतों में बफरिंग के आधार पर, इस प्रभाव को प्रचारित होने में कुछ समय लग सकता है।

यदि आपको कभी-कभी एक प्रोग्राम को UNIX सिस्टम पर रेट-लिमिट करने की आवश्यकता होती है, तो एक सरल उपाय ट्रिकल है । असली ट्रैफ़िक को आकार देने, जैसे आप गेटवे पर प्रदर्शन करेंगे, के साथ किया जा सकता है tc। यह अध्याय 9 में प्रलेखित है । लिनक्स एडवांस्ड रूटिंग एंड ट्रैफिक कंट्रोल HOWTO के बैंडविड्थ प्रबंधन के लिए कतारबद्ध अनुशासन ।

Comments

शानदार जवाब, बिल्कुल वही, जिसकी मुझे तलाश थी। धन्यवाद, इनाम आपके पास जाता है।

— रिचर्ड केलर

Answer 2

56 एमबी मॉडेम बनाम 4 एमबीपीएस डीएसएल लाइन के मामले में, गति के अंतर को बनाने (आमतौर पर) का कोई आकार नहीं होता है, यह लिंक की गति में सिर्फ एक अंतर है।

आने वाले ट्रैफ़िक को आकार देना कठिन होने का कारण यह है कि ट्रांसमिशन माध्यम में कोई बफर नहीं है। आप या तो आने वाले बिट्स को स्वीकार करते हैं या वे खो जाते हैं। ट्रैफ़िक के लिए taht एक इंटरफ़ेस छोड़ने वाला है, आप पैकेट को री-ऑर्डर कर सकते हैं और जितने चाहें उतने री-ऑर्डर कर सकते हैं (या, कम से कम डिवाइस में उपलब्ध बफर मेमोरी तक)।

उन प्रोटोकॉल के लिए जिनकी टीसीपी के ऊपर एक परत है (मुझे नहीं पता कि अगर यह टोरेंट के लिए मामला है), तो यह आगे के डेटा के लिए अनुरोधों को रखने का एक सरल मामला होगा। अन्यथा, पैकेट को बंद करने के लिए एप्लिकेशन को ओएस के साथ संवाद करने की आवश्यकता होगी। अधिकांश यूडीपी-आधारित प्रोटोकॉल, आवश्यकता के अनुसार ऐप-विशिष्ट प्रोटोकॉल में तर्क / पुनरावृत्ति तर्क है, इसलिए उस समय यह उन्हें गति देने के लिए तुच्छ पर सीमा कर रहा है।

एक संभावित मार्ग आपके DSL राउटर के लैन साइड पर इंटरनेट से ट्रैफ़िक को आकार देने के लिए होगा, जैसा कि उस समय, आप एक ईगोर पोर्ट पर आकार दे रहे होंगे।

Answer 3

मैं जवाब नहीं दे सकता कि आपने कोई समाधान क्यों नहीं पाया है जो आने वाले डेटा को आकार देने की अनुमति देता है (और मेरे सिर के ऊपर से कोई भी पता नहीं है), लेकिन प्रेषक को पता है कि रिसीवर कितनी तेजी से डेटा प्राप्त कर सकता है:

टीसीपी / आईपी का मूल डिजाइन यह है कि प्रत्येक पैकेट जिसे स्रोत गंतव्य पर भेजता है, उसे गंतव्य के लिए वापस जवाब देने के लिए इंतजार करना होगा (एक ACKपैकेट के साथ ) यह कहते हुए कि उसे पैकेट प्राप्त हुआ।

इसलिए यदि आपके पास 4Mbps प्रेषक और 56Kbps रिसीवर है, तो प्रेषक को प्रत्येक पैकेट का जवाब देने के लिए रिसीवर को पैकेट भेजने के बीच बैठकर इंतजार करना होगा (इस ओवरहेड को कम करने के लिए कुछ तकनीकी विवरण हैं, लेकिन आधार अभी भी एक सार पर है। स्तर)।

तो क्या होता है अगर प्रेषक पहले से ही 56Kbps डेटा भेज रहा है और फिर थोड़ा और भेजने की कोशिश करता है?

पैकेट खो जाता है। (ठीक है, संभावित रूप से एक स्विच के बफर में पंक्तिबद्ध, लेकिन जब वह भर जाता है, तो पैकेट खो जाता है)। चूंकि पैकेट खो गया, रिसीवर इसे प्राप्त नहीं करता है, और इसलिए कभी ACKपैकेट नहीं भेजता है । चूंकि प्रेषक को यह ACKपैकेट कभी नहीं मिलता (क्योंकि इसे कभी नहीं भेजा गया था, लेकिन यह भी खो सकता है, या एक नेटवर्क व्यवधान हो सकता है), प्रेषक को अतिरिक्त पैकेट को फिर से भेजने की आवश्यकता है । यह बैठता है और पैकेट को फिर से शुरू करने का प्रयास करता है जब तक कि वह इसके माध्यम से नहीं जाता है और ACKउत्तर इसे वापस मिल जाता है।

इसलिए, पुनः प्राप्त करने के लिए, जब एक बार प्रेषक ने रिसीवर की बैंडविड्थ को अधिकतम कर दिया, तो उसे अगले पैकेट को बार-बार रोकना और फिर से भेजना होगा जब तक कि इसके माध्यम से प्राप्त करने के लिए पर्याप्त उपलब्ध बैंडविड्थ न हो। यह प्रभावी रूप से ग्राहक को प्राप्त हो सकने वाली अधिकतम को भेजने की गति को कम कर देता है। (और एक पैकेट को इस मामले में नाराज होने के लिए कई बार कम करने के लिए अनुकूलन के तरीके हैं, जहां मूल रूप से प्रेषक को हर बार एक पैकेट को फिर से भेजना पड़ता है, लेकिन यह इस सरलीकृत विवरण के दायरे से परे है।

Answer 4

आप इसे एक ifb इंटरफ़ेस के साथ कर सकते हैं।

एक ifb इंटरफेस के साथ, आप if00 (उदाहरण के लिए) में eth0 (या जो भी) के अंतर्ग्रहण प्रवाह को रूट कर सकते हैं, और वहां सीमा नियम लागू कर सकते हैं।

लिनक्स फाउंडेशन के इस यूआरएल की जाँच करें: http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

और यह स्क्रिप्ट जो इनकमिंग और आउटकमिंग बैंडवाइट को सीमित करती है: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

Answer 5

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.

Answer 6

UFW का उपयोग करें (बिना आग वाली दीवार) http://ubuntuforums.org/showthread.php?t=606012

यह धागा एक सरल उदाहरण दिखाता है कि 30 सेकंड के भीतर 6 हिट के साथ आईपी को डिफॉल्ट करता है:

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

Comments

यह वास्तव में सवाल के साथ कुछ नहीं करना है।

— 3molo