নেটওয়ার্ক ল্যাটেন্সি ব্যান্ডউইথ ক্যালকুলেটর

নেটওয়ার্ক ল্যাটেন্সি এবং ব্যান্ডউইথ বোঝার উপায়

একটি একক TCP ফ্লো-এর বাস্তবসম্মত কর্মক্ষমতার সর্বোচ্চ সীমা নির্ধারণ করতে নেটওয়ার্কের বিভিন্ন প্যারামিটার বিশ্লেষণ করা প্রয়োজন। নেটওয়ার্ক ল্যাটেন্সি ব্যান্ডউইথ ক্যালকুলেটর মূলত লিঙ্ক রেট, রাউন্ড-ট্রিপ টাইম (RTT) এবং স্থানান্তরের সাইজ ব্যবহার করে সংযোগের প্রধান বাধা বা বটলেনেক চিহ্নিত করে। এটি প্রত্যাশিত TCP থ্রুপুট এবং মোট স্থানান্তর সময় হিসাব করে।

এই হিসাব প্রক্রিয়ায় তিনটি স্বাধীন সীমা কাজ করে: লিঙ্ক ক্ষমতা, রিসিভ উইন্ডো এবং প্যাকেট লস। এই তিনটির মধ্যে যেটি সবচেয়ে কম, সেটিই কার্যকর থ্রুপুট নির্ধারণ করে। এই টুলটি সম্পূর্ণভাবে আপনার ওয়েব ব্রাউজারে রান করে এবং সমস্ত হিসাব স্থানীয়ভাবে সম্পন্ন হয়। আপনার ইনপুট করা প্রতিটি মান এই ব্রাউজারেই হিসাব করা হয় — কোথাও কোনো তথ্য পাঠানো হয় না।

ক্যালকুলেটরের ইনপুট প্যারামিটারসমূহ

টুলটি সঠিকভাবে ব্যবহারের জন্য নিম্নলিখিত ইনপুটগুলো প্রদান করতে হবে:

• লিঙ্ক রেট: পাথের সবচেয়ে ধীরগতির হপ — সাধারণত আপনার প্ল্যানের নির্ধারিত গতি। এর মান অবশ্যই শূন্যের চেয়ে বেশি হতে হবে।
• রাউন্ড-ট্রিপ টাইম (RTT): দূরবর্তী প্রান্তের পিং টাইম — লোডের অধীনে আপনি যে সর্বোচ্চ মানটি আশা করেন তা ব্যবহার করুন। এর মান অবশ্যই শূন্যের চেয়ে বেশি হতে হবে।
• ডেটার সাইজ: স্থানান্তর করার পেলোড — একটি ফাইল, একটি ব্যাকআপ, একটি ডেটাসেট। এর মান অবশ্যই শূন্যের চেয়ে বেশি হতে হবে।
• রিসিভ উইন্ডো: রিসিভার যে পরিমাণ বাইট বাফার করতে পারে। ৬৫,৫৩৫ হলো আনস্কেলড সর্বোচ্চ সীমা। খালি রাখার অর্থ কোনো উইন্ডো সীমা নেই। এর মান অবশ্যই শূন্যের চেয়ে বেশি হতে হবে এবং এটি ১,০৭৩,৭২৫,৪৪০ বাইটের বেশি হতে পারবে না।
• এমএসএস (MSS): প্রতি প্যাকেটে পেলোড বাইট — ১,৪৬০ একটি স্ট্যান্ডার্ড ইথারনেট ফ্রেম পূরণ করে। খালি রাখলে ওভারহেড এবং লস উপেক্ষা করা হয়। এর মান ১ থেকে ৬৫,৪৯৫-এর মধ্যে একটি পূর্ণসংখ্যা হতে হবে।
• প্যাকেট লস (%): গড় প্যাকেট লসের সম্ভাবনা। খালি বা ০ রাখার অর্থ কোনো লস সীমা নেই। এর মান অবশ্যই ০ থেকে ১০০ শতাংশের মধ্যে হতে হবে।
• প্রদর্শিত দশমিক সংখ্যা: আউটপুট মানের দশমিকের পরের সংখ্যা নিয়ন্ত্রণ করে।

ইন্টারফেসে থাকা উদাহরণ লোড করুন বোতামটি দিয়ে নমুনা ডেটা ব্যবহার করা যায় এবং মুছে ফেলুন বোতাম দিয়ে ইনপুটগুলো রিসেট করা যায়।

আউটপুট এবং হিসাবের ফলাফল

টুলটি হিসাব সম্পন্ন করে তিনটি প্রধান বিভাগে ফলাফল প্রদর্শন করে:

থ্রুপুট এবং স্থানান্তর সময়

• প্রত্যাশিত TCP থ্রুপুট: এর সাথে একটি সাব-লেবেল থাকে যা সক্রিয় বাধা নির্দেশ করে, যেমন: ‹constraint› দ্বারা সীমাবদ্ধ। এখানে বাধাটি ডাইনামিকালি লিঙ্ক ক্ষমতা, রিসিভ উইন্ডো, অথবা প্যাকেট লস হিসেবে প্রদর্শিত হয়।
• স্থানান্তর সময়
• প্রথম বাইট পাওয়ার সময় (১ RTT)
• বাল্ক স্থানান্তর সময়
• ব্যান্ডউইথ-ডিলে প্রোডাক্ট
• পাথ পূরণ করার উইন্ডো
• উইন্ডো-সীমিত থ্রুপুট
• লস-সীমিত থ্রুপুট (Mathis)
• ওভারহেডের পর লিঙ্ক সিলিং
• প্রটোকল দক্ষতা

ফলাফল কপি করার জন্য ইন্টারফেসে ফলাফল কপি করুন বোতামটি ব্যবহার করা যায়।

ডাইনামিক সিস্টেম নোটিশ

ইনপুট মানের ওপর ভিত্তি করে সিস্টেমে নির্দিষ্ট কিছু নোটিশ দেখা যেতে পারে:

• এই পাথটি পূরণ করতে একটি ‹window› উইন্ডো প্রয়োজন — যা ৬৫,৫৩৫-বাইটের আনস্কেলড সর্বোচ্চ সীমার উপরে, তাই উভয় প্রান্তকেই TCP উইন্ডো স্কেলিং (RFC 7323) নেগোশিয়েট করতে হবে।
• এই পাথটি পূরণ করতে ‹window› প্রয়োজন — যা TCP নেগোশিয়েট করতে পারে এমন বৃহত্তম উইন্ডোর (১,০৭৩,৭২৫,৪৪০ বাইট) চেয়ে বেশি। এই পাথে একটি একক ফ্লো কখনোই ‹value› অতিক্রম করতে পারবে না।
• রিসিভ উইন্ডো বাড়িয়ে ‹window› করলে এই স্থানান্তরটি সর্বোচ্চ ‹value› পর্যন্ত পৌঁছাতে পারবে।
• ১%-এর বেশি লস Mathis মডেলের নির্ভরযোগ্য সীমার বাইরে — লস সিলিংটিকে একটি আশাবাদী অনুমান হিসেবে বিবেচনা করুন।

গাণিতিক সূত্র এবং মান প্রতিস্থাপন

ক্যালকুলেটরটি তার হিসাবের জন্য নিম্নলিখিত সূত্রগুলো ব্যবহার করে:

• মূল সূত্র: থ্রুপুট = min(রেট × eff, উইন্ডো ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = রেট × RTT
• প্রোটোকল দক্ষতা: প্রোটোকল দক্ষতা = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B প্যাকেট হেডার + তারের ওপর 38 B)
• লিঙ্ক সিলিং: লিঙ্ক সিলিং = rate × efficiency = ‹rate› × ‹eff› = ‹value›
• BDP: BDP = রেট × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›
• পাথ পূরণ করার উইন্ডো: পাথ পূরণ করার উইন্ডো = BDP ÷ 8 = ‹bdp› → ‹window›
• উইন্ডো সিলিং: উইন্ডো সিলিং = window ÷ RTT = ‹window› ÷ ‹rtt› = ‹value›
• লস সিলিং (Mathis): লস সিলিং (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
• প্রত্যাশিত থ্রুপুট: প্রত্যাশিত থ্রুপুট = এই সিলিংগুলোর মধ্যে সর্বনিম্নটি = ‹value› → ‹constraint› দ্বারা সীমাবদ্ধ
• স্থানান্তর সময়: স্থানান্তর সময় = RTT + 8 × size ÷ throughput = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›

নিয়ম, সীমাবদ্ধতা এবং ত্রুটি বার্তা

• ইউনিট কনভেনশন: সমস্ত ইউনিট ডেসিমেল ভিত্তিক (যেমন: ১ kbit = ১,০০০ বিট, ১ MB = ১,০০০,০০০ বাইট)। ফাইল ম্যানেজারগুলো সাধারণত ১০২৪-ভিত্তিক বাইনারি ইউনিট ব্যবহার করে (যেখানে একটি "১০০ MB" ফাইল আসলে ১০০ MiB বা প্রায় ১০৪.৮৬ ডেসিমেল MB)।
• ওভারহেড হিসাব: প্রোটোকল ওভারহেড স্ট্যান্ডার্ড ইথারনেটের ওপর ভিত্তি করে তৈরি, যা প্রতি প্যাকেটে ৭৮ বাইট যোগ করে (৪০ বাইট TCP/IP হেডার এবং ৩৮ বাইট ফিজিক্যাল ওয়্যার ওভারহেড)।
• Mathis মডেলের সীমাবদ্ধতা: Mathis লস মডেল ধরে নেয় যে প্যাকেট লস সমানভাবে ছড়িয়ে রয়েছে এবং স্বাধীন। এটি কেবল ১%-এর কম লস রেটের জন্য নির্ভরযোগ্য। লস ১% অতিক্রম করলে সতর্কবার্তা প্রদর্শিত হয়।
• উইন্ডো স্কেলিং সীমা: আনস্কেলড TCP উইন্ডোর সর্বোচ্চ সীমা ৬৫,৫৩৫ বাইট। এর বেশি উইন্ডো প্রয়োজন হলে RFC 7323 উইন্ডো স্কেলিং প্রয়োজন। TCP উইন্ডো স্কেলিংয়ের মাধ্যমে সর্বোচ্চ ১,০৭৩,৭২৫,৪৪০ বাইট পর্যন্ত উইন্ডো নেগোশিয়েট করা সম্ভব।
• মডেলের আওতা বহির্ভূত বিষয়: এই হিসাবগুলো একটি স্থির অবস্থার একক TCP ফ্লো ধরে নেয়। বাস্তব জীবনের জটিলতা যেমন TCP স্লো স্টার্ট, কনজেশন-কন্ট্রোল টিউনিং, ধীরগতির রিসিভার এবং TLS হ্যান্ডশেক এই মডেলের আওতাভুক্ত নয়। তাই বাস্তব স্থানান্তর ধীরগতিতে শুরু হতে পারে।

সম্ভাব্য ত্রুটি বার্তাসমূহ:

• ইনপুট সংখ্যা না হলে: "‹field›: “‹token›” কোনো সংখ্যা নয়।"
• লিঙ্ক রেট শূন্য বা ঋণাত্মক হলে: "লিঙ্ক রেট অবশ্যই শূন্যের চেয়ে বেশি হতে হবে।"
• রাউন্ড-ট্রিপ টাইম শূন্য বা ঋণাত্মক হলে: "রাউন্ড-ট্রিপ টাইম অবশ্যই শূন্যের চেয়ে বেশি হতে হবে।"
• ডেটার সাইজ শূন্য বা ঋণাত্মক হলে: "ডেটার সাইজ অবশ্যই শূন্যের চেয়ে বেশি হতে হবে।"
• রিসিভ উইন্ডো শূন্য বা ঋণাত্মক হলে: "রিসিভ উইন্ডো অবশ্যই শূন্যের চেয়ে বেশি হতে হবে।"
• রিসিভ উইন্ডো RFC 7323 সীমা অতিক্রম করলে: "TCP ১,০৭৩,৭২৫,৪৪০ বাইটের বেশি উইন্ডো নেগোশিয়েট করতে পারে না (RFC 7323 উইন্ডো স্কেলিং)।"
• MSS সীমার বাইরে হলে: "MSS অবশ্যই ১ থেকে ৬৫,৪৯৫-এর মধ্যে একটি পূর্ণসংখ্যার বাইট হতে হবে।"
• প্যাকেট লস সীমার বাইরে হলে: "লস রেট অবশ্যই ০ থেকে ১০০ শতাংশের মধ্যে হতে হবে।"
• হিসাব সিস্টেমের সীমা অতিক্রম করলে: "একটি মান বা মধ্যবর্তী ফলাফল সমর্থিত সংখ্যার সীমা অতিক্রম করেছে।"

প্রায়শই জিজ্ঞাসিত প্রশ্ন (FAQ)

প্রশ্ন: ব্যান্ডউইথ-ডিলে প্রোডাক্ট কী, এবং এটি কেন উইন্ডোর সাইজ নির্ধারণ করে?
উত্তর: BDP — লিঙ্ক রেট × রাউন্ড-ট্রিপ টাইম — হলো যেকোনো মুহূর্তে ট্রানজিটে থাকা ডেটার পরিমাণ। TCP-তে সর্বোচ্চ একটি আন-অ্যাকনলেজড উইন্ডো বাকি থাকতে পারে, তাই BDP-এর চেয়ে ছোট উইন্ডো থাকলে পাইপটি আংশিক খালি থাকে: 50 ms RTT সহ 100 Mbit/s গতিতে পাইপটি 625 kB ধারণ করে, এবং একটি 65,535-বাইট উইন্ডো এর মাত্র দশ ভাগের এক ভাগ পূরণ করে। এই কারণেই দ্রুত ও দীর্ঘ পাথের জন্য TCP উইন্ডো স্কেলিং (RFC 7323) প্রয়োজন, যা নেগোশিয়েট করার সর্বোচ্চ সীমা 65,535 বাইট থেকে বাড়িয়ে প্রায় 1 GB করে দেয়।

প্রশ্ন: আমার ফাইল স্থানান্তর গতি কেন আমার কেনা লিঙ্ক রেটের চেয়ে ধীরগতির হয়?
উত্তর: একটি একক TCP ফ্লো তিনটি স্বাধীন সিলিংয়ের মুখোমুখি হয় এবং সর্বনিম্নটি কার্যকর হয়। প্রোটোকল ওভারহেড লিঙ্কটিকে নিজেই প্রায় ৫% কমিয়ে দেয় — একটি স্ট্যান্ডার্ড ইথারনেট ফ্রেম তারের ওপর ১,৫৩৮ বাইটের মধ্যে ১,৪৬০ পেলোড বাইট বহন করে। রিসিভ উইন্ডো থ্রুপুটকে window ÷ RTT-তে সীমাবদ্ধ করে, তাই ক্লাসিক ৬৫,৫৩৫-বাইট উইন্ডো একটি ৫০ ms পাথকে প্রায় ১০.৫ Mbit/s গতিতে আটকে রাখে, লিঙ্কটি যতই দ্রুত হোক না কেন। আর লস এটিকে (MSS ÷ RTT) ÷ √loss-এ সীমাবদ্ধ করে। উপরের ফলাফলটি দেখায় যে আপনার দেওয়া সংখ্যার ক্ষেত্রে কোন সিলিংটি বাধা সৃষ্টি করছে।

প্রশ্ন: প্যাকেট লস কীভাবে TCP থ্রুপুটকে সীমিত করে?
উত্তর: TCP লসকে কনজেশন বা নেটওয়ার্কের জ্যাম হিসেবে বিবেচনা করে এবং প্রতিটি লস ইভেন্টে তার পাঠানোর হার অর্ধেক করে দেয়, তাই দ্রুত পাথে সামান্য লস রেটও বড় প্রভাব ফেলে। Mathis মডেল সিলিংটিকে (MSS ÷ RTT) ÷ √p হিসেবে অনুমান করে — ১,৪৬০-বাইট MSS সহ একটি ৫০ ms পাথে ০.০১% লস হলে তা প্রায় ২৩ Mbit/s হয়, লিঙ্কের গতি যাই হোক না কেন। এই মডেলটি সমানভাবে ছড়িয়ে থাকা, স্বাধীন লস ইভেন্ট ধরে নেয়; প্রায় ১%-এর নিচে এটি বাস্তবতার সাথে ভালোভাবে মিলে যায়, এবং বার্স্টি লসের ক্ষেত্রে এটি আশাবাদী অনুমান দেখায়।

প্রশ্ন: এখানের মেগাবাইট কি আমার ফাইল ম্যানেজারের মেগাবাইটের সমান?
উত্তর: ঠিক তা নয়। এই পেজটি ডেসিমেল ইউনিট ব্যবহার করে, যা নেটওয়ার্কিংয়ের নিয়ম: ১ kbit = ১,০০০ বিট এবং ১ MB = ১,০০০,০০০ বাইট। বেশিরভাগ ফাইল ম্যানেজার ১০২৪-ভিত্তিক ইউনিটে হিসাব করে, যা প্রায়ই ভুলভাবে MB হিসেবে লেবেল করা থাকে — সেখানে একটি “১০০ MB” ফাইল সাধারণত ১০০ MiB ≈ ১০৪.৮৬ ডেসিমেল MB হয়, তাই এটি স্থানান্তর করতে ডেসিমেল হিসাবের চেয়ে প্রায় ৫% বেশি সময় নেয়। হুবহু মেলাতে এখানে ১০৪.৮৬ MB লিখুন।