টিসিপি / আইপি পদগুলিতে, কোনও অফিসে ডাউনলোডের গতি সীমাবদ্ধকরণ কীভাবে করে?


8

জনগণের অফিস হিসাবে ধরে নিন, তারা HTTP ডাউনলোডগুলি তাদের ইন্টারনেট সংযোগের গতির সর্বোচ্চ 40% ব্যান্ডউইদথের মধ্যে সীমাবদ্ধ করতে চান যাতে এটি অন্যান্য ট্র্যাফিককে বাধা না দেয়।

আমরা বলি "এটি আপনার ফায়ারওয়ালে সমর্থিত নয়" এবং তারা অনিবার্য রেখাকে বলে যে "আমরা এটি আমাদের নেটগার / ডিলিঙ্ক / ড্রেটেক দিয়ে করতে সক্ষম হতাম"।

এটি নিয়ে ভাবনা, একটি ডাউনলোডের মতো:

HTTP GET request
Server sends file data as TCP packets
Client acknowledges receipt of TCP packets
Repeat until download finished.

সার্ভারটি আপনাকে কত দ্রুত ডেটা প্রেরণ করে এবং আপনি এটি কত দ্রুত স্বীকার করেছেন তার দ্বারা গতি নির্ধারিত হয়।

সুতরাং, ডাউনলোডের গতি সীমাবদ্ধ করতে আপনার দুটি পছন্দ আছে:

1) সার্ভারকে আপনার কাছে আরও ধীরে ধীরে ডেটা প্রেরণের নির্দেশ দিন - এবং আমি মনে করি না যে টিসিপি বা এইচটিটিপি-তে অনুরোধ করার জন্য কোনও প্রোটোকল বৈশিষ্ট্য রয়েছে।

2) আপনার আপলোডের গতি সীমাবদ্ধ করে আরও ধীরে ধীরে প্যাকেটগুলি স্বীকার করুন এবং আপনার আপলোডের গতিও নষ্ট করুন।

ডিভাইসগুলি কীভাবে এই সীমাবদ্ধ করে? মানক উপায় আছে কি?


ল্যানের মধ্যে ফায়ারওয়াল থেকে কীভাবে দ্রুত প্যাকেট প্রাপ্ত প্যাকেটগুলি অনুমোদিত তা সীমাবদ্ধ করার হারকে প্রেরণকারীর সার্ভারের টিসিপি স্ট্যাক থ্রোটল প্রেরণের গতি ফেরত দেওয়ার জন্য ধীর স্বীকৃতি এবং কনজেশন হ্যান্ডলিংয়ের কারণ হয়। ধন্যবাদ। টেস্টিংয়ের মাধ্যমে আমি এটির মতো কাজ করতে পারি। আমি বেশ কয়েকটি উত্তরকে উক্ত করে দিয়েছি তবে আমি কেবল উত্তর হিসাবে চিহ্নিত করতে পারি।
TessellatingHeckler

উত্তর:


11

টিসিপি নিজেই যানজট নিয়ন্ত্রণ প্রয়োগ করে।

এই হার সীমাবদ্ধকারীরা কেবল প্যাকেটগুলি সীমা ছাড়িয়ে ফেলে দেবে। টিসিপি এটি পরিচালনা করে, প্যাকেটগুলি সমস্ত উপস্থিত হয় এবং সমস্ত ক্রমে আগত তা নিশ্চিত করে; ক্লায়েন্টটি বাদ প্যাকেটগুলির জন্য এসি কে করে না এবং তারা সার্ভারের মাধ্যমে পুনরায় বিরক্ত হয়।

সার্ভারের টিসিপি স্ট্যাক প্যাকেটগুলি পুনরায় প্রেরণ করবে এবং এটি প্রেরণের হারে কিছুটা ডায়াল করবে কারণ এটির এবং ক্লায়েন্টের মধ্যে কোথাও ভিড় রয়েছে figures হার সীমাবদ্ধকারী প্যাকেটগুলি আবার ড্রপ না করা অবধি গতি বাড়িয়ে দেবে এবং এ জাতীয় কিছু।


সুতরাং ফায়ারওয়ালটি কত দ্রুত / ল্যান / ইন্টারফেসে এইচটিটিপি ট্র্যাফিক আটকায় তা সীমাবদ্ধ করে আমার কিউএস নীতি রেট প্রয়োগ করা উচিত? এবং তারপরে টিসিপি এটি পরিচালনা করতে দিন। "এটি তার প্রেরণের হারেও কিছুটা ডায়াল করবে" আমি অনুপস্থিত ছিল এমন আরও একটি অংশ।
TessellatingHeckler

2
হ্যাঁ, এটা ঠিক। সার্ভারটি আপনার লিঙ্কে কেবল ডেটা ফেলে রাখতে পারে , কিউএস প্রয়োগ করার আগে স্যাচুরেট করে - তবে, যতক্ষণ না এটি একজন ভাল টিসিপি নাগরিক, তার প্রেরণের হার যে পরিমাণে তার ডেটা পাচ্ছে তার সাথে একটি আনুমানিক ভারসাম্য প্রতিষ্ঠা করবে হার সীমাবদ্ধ।
শেন ম্যাডেন

হ্যাঁ, টিসিপি তার নিজস্ব যানজট নিয়ন্ত্রণ প্রয়োগ করে, তবে এটি কার্যকরভাবে কার্যকর হয় না। টরেন্টের সাথে যে কোনও অভিজ্ঞতার সাথে এটি জানেন। মূলত, নেটওয়ার্কে বেশ কয়েকটি সক্রিয় সংযোগ থাকা অবস্থায় টিসিপি কনজেশন নিয়ন্ত্রণের বেশিরভাগ বাস্তবায়ন ভেঙে যায়।
ব্যবহারকারী 606723

1
@ ইউজার 606723 যদি টরেন্টস সমস্যা হয় তবে আপনার ট্র্যাফিকটি বাতিল করতে আপনার ঠিকানাতে একটি প্যাকেট শেপার ব্যবহার করা উচিত। এটি ট্র্যাকার থেকে টরেন্টার কেটে ফেলবে এবং অন্যান্য লোকেরা একই টরেন্টটি ডাউনলোড করে রাখতে পারবে যাতে আপনার সংযোগগুলি দিয়ে প্রবেশ করা যায়। সমস্যা সমাধান.
MDMarra

1
@ ব্যবহারকারী 606723 কেন হ্যাঁ, দ্রুত প্রারম্ভিক টিসিপি দিয়ে পুরো সময় হাজার হাজার সংযোগ শুরু করা হওয়ায় যানজট নিয়ন্ত্রণের একটি চূড়ান্ত লড়াই হবে, যেহেতু নতুন সংযোগগুলি তারা যে সংযোগ তৈরি করছে তার অবস্থা সম্পর্কে কিছুই জানে না। শত শত সক্রিয় সংযোগ, যদিও? হতে পারে এটি ধীর গতির লিঙ্কটি ভেঙে ফেলবে ..
শেন ম্যাডেন

5

টিসিপির অন্তর্নিহিত থ্রোটলিং পদ্ধতির বোধগম্য হয়ে ওঠার সেরা বর্ণনাটি এখনকার সিকিউরিটি নাউ পডকাস্ট বন্ধ ছিল । স্টিভ গিবসনের উদ্ধৃতি দিতে:

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

সুতরাং এর সম্পর্কে চিন্তা করা যাক। আমরা প্রাপ্ত প্রতিটি স্বীকৃতি স্বীকার না করে আমরা অপ্রকাশিত প্যাকেটগুলির সংখ্যা একটি করে বাড়ানোর অনুমতি দিই। সুতরাং আমরা প্রথমে আমাদের সম্মতি অনুযায়ী দুটি প্যাকেট প্রেরণ করি। তারা স্বীকৃতি পায়। সুতরাং আমরা আমাদের প্রথম স্বীকৃতি আছে। আমরা আমাদের দু'জনকে পাঠানোর অনুমতি দিচ্ছিলাম। এখন, এই প্রথম স্বীকৃতি প্রাপ্তির সাথে, আমরা এটি এক থেকে তিন দ্বারা বাড়িয়েছি। সুতরাং আমরা এখন আর কোনও স্বীকৃতি ছাড়াই আরও তিনটি প্যাকেট পাঠাতে পারি। আমরা আগে যা কিছু পাঠিয়েছি তার জন্য যখন কোনও স্বীকৃতি ফিরে আসে, তখন আমরা তা বাড়িয়ে চারটে করে ফেলি। এটি "যানজট উইন্ডো" নামে পরিচিত। এটি কোনও উইন্ডো যা লাইনে কখনও প্রেরণ করা হয়নি, এটি হ'ল এটি রিসিভ উইন্ডোর মতো নয়, এটি টিসিপি শিরোনামের 16 বিট যা আমাদের জানায় যে আমরা কতগুলি ডেটা এগিয়ে পাঠাতে পারব। এটি একটি - এটি একটি উইন্ডো। এটা '

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

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

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

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

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


3

সুতরাং, ডাউনলোডের গতি সীমাবদ্ধ করতে আপনার দুটি পছন্দ আছে:

1) সার্ভারকে আপনার কাছে আরও ধীরে ধীরে ডেটা প্রেরণের নির্দেশ দিন - এবং আমি মনে করি না যে টিসিপি বা এইচটিটিপি-তে অনুরোধ করার জন্য কোনও প্রোটোকল বৈশিষ্ট্য রয়েছে।

2) আপনার আপলোডের গতি সীমাবদ্ধ করে আরও ধীরে ধীরে প্যাকেটগুলি স্বীকার করুন এবং আপনার আপলোডের গতিও নষ্ট করুন।

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

এটি পরিচালনা করে এমন কোনও ডিভাইস সন্ধান করার সময়, কনফিগারেশন / ডকুমেন্টেশনে QoS (পরিষেবার মানের) সন্ধান করুন। লিনাক্স (বা বিএসডি) বাক্সগুলিও এর জন্য কার্যকর।


এটি প্রায় উপলব্ধি করে - সুতরাং কৌশলটি স্বীকৃতিগুলির হারকে সীমাবদ্ধ করা এবং ল্যান ডিভাইসটি ভান করে সার্ভারটি যেটি আসলে তার চেয়ে ধীরে ধীরে প্রেরণ করছে? সুতরাং সেখানে প্রথমে সংযোগটি ফাটানো হবে, তারপরে নয়?
TessellatingHeckler

1
@ টেসেল্লাটিংহেকলার হ্যাঁ, এটিই। এছাড়াও, "বিস্ফোরণ" এন.ইউইউইকিপিডিয়া.আর / উইকি / স্লো - স্টার্টের খুব বড় ফোরস সৌজন্যে হওয়া উচিত নয় ।
জেফ ফেরল্যান্ড

2

আপনি একটি ফায়ারওয়াল বা ডিভাইস ব্যবহার করেন যা QoS (পরিষেবার মানের) সীমিতকরণকে সমর্থন করে।

অফিসের গেটওয়ে হিসাবে কাজ করতে আপনি একটি লিনাক্স সিস্টেম তৈরি করতে পারেন এবং এটি অর্জনের জন্য এটি ট্র্যাফিক শেপিং ব্যবহার করতে পারেন। কেবলমাত্র একাধিক এনআইসি ইনস্টল করা দরকার এবং তারপরে প্রতিটি মেশিন গেটওয়ে হিসাবে নির্দেশ করে।

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


কিউএস কীভাবে সাহায্য করে? আপনার ডিভাইস একটি ডাউনলোডে কিউএস প্রয়োগ করার সময়, আগত ট্র্যাফিক ইতিমধ্যে ইন্টারনেট সংযোগে এসে গেছে এবং এটি করার সময় এটি সম্ভবত অবরুদ্ধ করে রেখেছে। QoS বহির্গামী ট্র্যাফিকের জন্য প্রয়োগ করতে পারে, তবে আগত ট্র্যাফিক সম্পর্কে এটি কিছুই করতে পারে না কারণ ট্রাফিকটি দেখার সময়টি অনেক দেরি হয়ে গেছে।
TessellatingHeckler

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

এছাড়াও প্রক্সি সার্ভার পাশাপাশি কিছুটা ভিড়ও কমিয়ে আনতে সহায়তা করতে পারে। তবে অন্যথায়, আপনাকে এন্ট্রিং পয়েন্টে এটি আকার দিতে হবে।
বার্ট সিলভারস্ট্রিম

আমার আসল প্রশ্নটি ছিল: এটি প্রদর্শিত হচ্ছে আপনি ইন্ট্রিং পয়েন্টে আকৃতি তৈরি করতে পারবেন না, কারণ ট্র্যাফিকের বাধা পেরিয়ে যাওয়ার পরে আপনি যে কোনও নিয়ন্ত্রণ প্রয়োগ করতে পারেন, তাতে কী পরিমাণ প্রযুক্তি ব্যবহার করে? "কিউওএস যেমন প্রয়োগ করুন লিনাক্স সহ" এবং "ট্র্যাফিক শেপিং ব্যবহার করুন" ব্যবহারিকভাবে কী করা উচিত তা হতে পারে তবে কীভাবে এটি সম্ভবত সহায়তা করতে পারে তার একটি ব্যাখ্যা খুঁজছিলাম। (এবং এখন অন্যান্য জবাব কিছু আছে)।
TessellatingHecler

@ টেসেল্লাটিংহেকলার: আমার যে পদ্ধতিটি আমি পছন্দ করি তা ইসিএন ব্যবহার সক্ষম করে যা প্রেরণকারী সার্ভারকে প্যাকেট না ফেলেই ধীর করে দিতে বলে। এই পদ্ধতিটি হল ল্যান ইন্টারফেসে ছেড়ে যাওয়া প্যাকেটে রেডের মতো রেট সীমাবদ্ধতা প্রয়োগ করা, WAN ইন্টারফেসে একটি ইনগ্রেশন ফিল্টার ব্যবহার করার চেষ্টা না করে।
ঝ্যান লিংস

2

এইচটিটিপি প্রোটোকল ব্যবহৃত ব্যান্ডউইথকে সীমাবদ্ধ করার সুবিধাদি সরবরাহ করে না, এবং তা করা সত্ত্বেও এটি ক্লায়েন্ট-সাইড সেটিং হবে, যার উপরে নেটওয়ার্ক প্রশাসকদের কোনও নিয়ন্ত্রণ থাকতে পারে না।

ব্যান্ডউইথ সীমিতকরণ ("পরিষেবার মান হিসাবে পরিচিত") সাধারণত রাউটার / ফায়ারওয়ালগুলিতে পরিচালিত হয়, যা কোনও নেটওয়ার্কে / থেকে সমস্ত আগত এবং বহির্গামী ট্র্যাফিক পরিচালনা করে; এগুলি সমর্থন করে এমনগুলি সাধারণত আপনাকে নীতিগুলি কনফিগার করতে দেয় যেমন "যে কোনও একক ক্লায়েন্ট কম্পিউটারকে সমস্ত উপলব্ধ ব্যান্ডউইথের 10% ব্যবহার করুন" বা "এফটিপি-র উপর এসএমটিপিকে অগ্রাধিকার দিন যাতে কোনও ইমেল ভারী ডাউনলোড করার পরেও ইমেলগুলি প্রবাহিত হতে পারে" "।

এটি ঠিক কীভাবে সম্পন্ন হয় তা নির্ভর করে ব্যবহৃত রাউটার / ফায়ারওয়ালের উপর নির্ভর করে তবে সবচেয়ে প্রাথমিক উপায়টি কেবল কনফিগার করা সীমা ছাড়িয়ে যাওয়া প্যাকেটগুলি ফেলে দেওয়া; টিসিপি নিশ্চিত করবে যে তারা পুনঃপ্রেরণিত হবে এবং শেষ পর্যন্ত তারা বাধা পেরিয়ে যেতে সক্ষম হবে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.