আগত ট্র্যাফিক রেট-সীমাবদ্ধ

Question

আগত ট্র্যাফিককে রেট-সীমাবদ্ধ করা সম্ভব কিনা তা আমি কখনই পুরোপুরি বুঝতে পারি নি । আমি বুঝতে পারি যে প্রত্যন্ত সার্ভারের প্যাকেটগুলি প্রেরণের হার নিয়ন্ত্রণ করার জন্য কোনও সরাসরি পদ্ধতি নেই (যদি না আপনি উভয় প্রান্তের নিয়ন্ত্রণে থাকেন) তবে এই সীমাবদ্ধতাটিকে বিবেচনায় রেখে কীভাবে ডাউনলোড ম্যানেজার আমাকে ডাউনলোডের গতির সীমাটি সফলভাবে সেট করতে দেয়? ?

টিসিপি স্লো-স্টার্ট এবং আসন্ন ট্র্যাফিককে রেট-সীমাবদ্ধ করার মধ্যে কোনও যোগসূত্র রয়েছে কি ? প্যাকেট প্রেরণের প্রেরকের হারকে কৃত্রিমভাবে সীমাবদ্ধ করতে ধীর-সূচনা দ্বারা বর্ণিত পদ্ধতিগুলি ব্যবহার করা কি সম্ভব?

অতিরিক্ত বিবেচনা হিসাবে, এটি লক্ষ করা উচিত যে আমি যে সার্ভারটিতে ট্র্যাফিকের আকারের প্রয়োগ করতে চাই তা পিপিপিওই সংযোগটি নিজেই প্রতিষ্ঠিত করে এবং নেটওয়ার্কের বাকি অংশের রাউটার হিসাবে কাজ করে।

আপডেট: উত্তর এখনও পর্যন্ত আমি জিজ্ঞাসা করা প্রশ্নগুলির একটি ন্যায্য সংক্ষিপ্ত বিবরণ দিয়েছে, কিন্তু এখনও আমি জানি না যে ডাউনলোড ম্যানেজারগুলি কীভাবে আগমন ট্র্যাফিককে সীমাবদ্ধ রাখতে সক্ষম হয় এবং আরও সুনির্দিষ্টভাবে বলা যায় যে এটি কোনও একই ধরণের কৌশল প্রয়োগ করা সম্ভব কিনা। লিনাক্স গেটওয়ে বক্স

Comments

ফ্রি ডাউনলোড ম্যানেজার সম্ভবত তাদের নিজের আপলোড সার্ভার এবং টরেন্ট ক্লায়েন্টদের বেশিরভাগ ব্যবহার করে তারা সংযোগের সংখ্যা সীমিত করে। এছাড়াও, আপনি কিউওএস-এর দিকে নজর রেখেছেন?

— ডাচউঙ্কল

বেশিরভাগ ডাউনলোড ম্যানেজাররা এসিকে ফেরত পাঠানো সীমাবদ্ধতার হার নির্ধারণ করে, যার ফলে ডেটার আগত বাষ্প ধীর হয়ে যায়।

— ক্রিস এস

Answer 1

ডাউনলোড ম্যানেজার সম্ভবত ট্রিকল পেপারে বর্ণিত হিসাবে কাজ করে ।

বিএসডি সকেট ব্যবহার করে এমন একটি প্রক্রিয়া তার নিজস্ব রেট সীমাবদ্ধতা সম্পাদন করতে পারে। প্রবাহ সীমিত করার জন্য, অ্যাপ্লিকেশনটি কেবল সকেটে লিখিত তথ্যের হার সীমাবদ্ধ করে এটি করতে পারে। একইভাবে, ডাউন স্ট্রিম সীমাবদ্ধতার জন্য, একটি অ্যাপ্লিকেশন কোনও সকেট থেকে পড়া ডেটার হার সীমাবদ্ধ করতে পারে। তবে এই কাজ করার কারণটি অবিলম্বে সুস্পষ্ট নয়। অ্যাপ্লিকেশনটি যখন সকেট থেকে কিছু তথ্য পড়তে অবহেলা করে, তার সকেট বাফারগুলি পূরণ করে। ফলস্বরূপ এটি গ্রহণকারী টিসিপিকে একটি ছোট রিসিভার উইন্ডো (rwnd) বিজ্ঞাপন দেবে, যার ফলে অন্তর্নিহিত টিসিপি সংযোগের উপর চাপ চাপ সৃষ্টি হবে যার ফলে এটির ডেটা প্রবাহকে সীমাবদ্ধ রাখবে। শেষ পর্যন্ত এই "ট্রিকল ডাউন-এফেক্ট" এন্ড-টু-এন্ড হার সীমাবদ্ধতা অর্জন করে। নেটওয়ার্ক স্ট্যাকের সমস্ত স্তরগুলিতে বাফারিংয়ের উপর নির্ভর করে এই প্রভাবটি প্রচারে কিছুটা সময় নিতে পারে।

আপনার যদি মাঝে মাঝে ইউনিক্স সিস্টেমে একক প্রোগ্রামকে রেট-সীমাবদ্ধ করার প্রয়োজন হয়, তবে একটি সহজ সমাধান জটিল । আপনি যেমন একটি গেটওয়েতে পারফর্ম করবেন ঠিক তেমন ট্র্যাফিক গঠনের কাজও করা যেতে পারে tc। লিনাক্স অ্যাডভান্সড রাউটিং অ্যান্ড ট্র্যাফিক কন্ট্রোল হাওটো-র ব্যান্ডউইদথ ম্যানেজমেন্টের জন্য অনুশাসনমূলক শৃঙ্খলা রক্ষা করার জন্য এটি অধ্যায় 9 এ নথিভুক্ত করা হয়েছে ।

Comments

দুর্দান্ত উত্তর, ঠিক আমি যা খুঁজছিলাম। ধন্যবাদ, অনুগ্রহ আপনার কাছে যায়।

— রিচার্ড কেলার

Answer 2

৪ এমবিপিএস ডিএসএল লাইন বিপরীতে ৫k কে মডেমের ক্ষেত্রে, (সাধারণত) গতির পার্থক্য তৈরি করে এমন কোনও আকার নেই (এটি সাধারণত লিঙ্কের গতিতে পার্থক্য)।

আসন্ন ট্র্যাফিকের পক্ষে এটি গঠন করা শক্ত কারণ হ'ল সংক্রমণ মাধ্যমের কোনও বাফার নেই। আপনি হয় আগত বিট গ্রহণ করুন বা সেগুলি হারিয়ে গেছে। ট্র্যাফিক তহত একটি ইন্টারফেস ছেড়ে চলে যাওয়ার জন্য, আপনি প্যাকেটগুলি বাফার এবং পুনরায় অর্ডার করতে পারেন যতটা আপনি চান (বা কমপক্ষে ডিভাইসে উপলব্ধ বাফার মেমরি পর্যন্ত)।

টিসিপির উপরে একটি স্তর রয়েছে এমন প্রোটোকলগুলির জন্য (টরেন্টগুলির ক্ষেত্রে এটি কিনা তা আমি জানি না), পরবর্তী ডেটার জন্য অনুরোধগুলি প্যাকিং করা এটি একটি সাধারণ বিষয় হবে। অন্যথায়, অ্যাপ্লিকেশনটির ওএসের সাথে যোগাযোগ করতে হবে, প্যাকেটগুলির ACKing বিলম্ব করতে। বেশিরভাগ ইউডিপি-ভিত্তিক প্রোটোকলগুলির প্রয়োজন অনুসারে অ্যাপ্লিকেশন-নির্দিষ্ট প্রোটোকলে ACK / পুনরায় যুক্তি যুক্ত করা হবে, সুতরাং সেই সময়ে এটি তাদের ত্বরান্বিত করার জন্য তুচ্ছ ord

একটি সম্ভাব্য রুট হ'ল আপনার ডিএসএল রাউটারের ল্যান পাশের ইন্টারনেট থেকে ট্র্যাফিকের আকার তৈরি করা, যেমনটি আপনি একটি অ্যাড্রেস বন্দরে রূপ নিচ্ছেন।

Answer 3

আপনি কেন এমন কোনও সমাধান খুঁজে পেলেন না যে আপনি আগত ডেটা গঠনের অনুমতি দিচ্ছেন (এবং আমার মাথার উপরের দিক থেকে কোনওটি জানেন না), তবে প্রেরক কীভাবে ডেটা গ্রহণ করতে পারবেন তা কীভাবে জানবে:

টিসিপি / আইপির মূল নকশাটি হ'ল উত্সটি যে প্যাকেটটি গন্তব্যে প্রেরণ করে তার জন্য ACKপ্যাকেটটি পেয়েছে বলে গন্তব্যটির জবাব ( প্যাকেট সহ) ফেরার জন্য অপেক্ষা করতে হবে ।

সুতরাং আপনার কাছে যদি 4 এমবিপিএস প্রেরক এবং একটি 56 কেবিপিএস রিসিভার থাকে, তবে প্রেরককে প্রতিটি প্যাকেটের প্রতিক্রিয়া জানাতে রিসিভারের জন্য প্যাকেটগুলি প্রেরণের মধ্যে বসে বসে অপেক্ষা করতে হবে (এই ওভারহেড হ্রাস করার জন্য কিছু প্রযুক্তিগত বিশদ রয়েছে, তবে ভিত্তিটি এখনও একটি বিমূর্ত অংশে ধারণ করে স্তর)।

সুতরাং যদি প্রেরক ইতিমধ্যে ৫K কেবিপিএস ডেটা প্রেরণ করে এবং তারপরে আরও কিছু প্রেরণ করার চেষ্টা করে তবে কি হবে?

প্যাকেটটি হারিয়ে যায়। (ভাল, সম্ভাব্যভাবে একটি স্যুইচের বাফারে সারিবদ্ধ, কিন্তু যখন এটি পূর্ণ হয়, প্যাকেটটি নষ্ট হয়ে যায়)। যেহেতু প্যাকেটটি হারিয়ে গেছে, গ্রহীতা কখনই এটি গ্রহণ করে না এবং তাই কখনও ACKপ্যাকেট প্রেরণ করে না । যেহেতু প্রেরক কখনও এই ACKপ্যাকেটটি পান না (কারণ এটি কখনও প্রেরণ করা হয়নি, তবে এটি হারিয়ে যেতে পারে, বা কোনও নেটওয়ার্ক বিঘ্ন ঘটতে পারে), প্রেরকের অতিরিক্ত প্যাকেটটি পুনরায় পাঠাতে হবে । এটি বসে এবং প্যাকেটটি না পারা পর্যন্ত এটি পুনরায় ACKপাঠানোর চেষ্টা করে এবং উত্তরটি তার কাছে ফিরে না আসে।

সুতরাং, পুনরুদ্ধার করার জন্য, একবার প্রেরক গ্রাহকের ব্যান্ডউইদথকে সর্বাধিক সীমাবদ্ধ করে ফেললে, পরবর্তী প্যাকেটটি থামাতে এবং পুনরায় পুনরায় বিক্রয় করতে হবে যতক্ষণ না এটির জন্য পর্যাপ্ত উপলব্ধ ব্যান্ডউইদথ না পায়। এটি কার্যকরভাবে ক্লায়েন্টটি পেতে পারে এমন সর্বাধিক প্রেরণের গতি হ্রাস করে। (এবং এক্ষেত্রে কোনও প্যাকেটের বিরক্তি প্রকাশের সংখ্যা কমাতে অপ্টিমাইজেশন পদ্ধতি রয়েছে, যেখানে মূলত প্রেরকটি প্রতিবার প্যাকেটটি পুনরায় পাঠাতে হলে ধীরে ধীরে কমিয়ে দেয় তবে এটি সরল বর্ণনার পরিধির বাইরে নয়।

Answer 4

আপনি এটি ifb ইন্টারফেসের সাহায্যে করতে পারেন।

যদি একটি আইএফবি ইন্টারফেস থাকে, আপনি যদি ইথবি 0 (উদাহরণস্বরূপ) তে ঠিকানাটির কাছে eth0 (বা যাই হোক না কেন) এর প্রবেশ প্রবাহকে রুট করতে পারেন এবং সীমা বিধি প্রয়োগ করতে পারেন।

লিনাক্স ফাউন্ডেশনের এই ইউআরএলটি দেখুন: http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

এবং এই স্ক্রিপ্টগুলি অযোগ্য এবং বহির্মুখী ব্যান্ডউইট সীমাবদ্ধ করে: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

Answer 5

আশ্চর্যজনক পরীক্ষা করে দেখুন: 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

ইউএফডাব্লু (জটিল জটিল ফায়ার ওয়াল) ব্যবহার করুন http://ubuntuforums.org/showthread.php?t=1260812

এই থ্রেডটি একটি সাধারণ উদাহরণ দেখায় যা 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