কেবলকে দোষ দেওয়ার আগে প্যাকেট লস কীভাবে পড়বেন

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

একটির ওপর ভরসা না করে তিনটি পরিমাপ তুলনা করুন: প্রোব কী দেখল, ইন্টারফেস কাউন্টার কী করল, আর অ্যাপ্লিকেশনটি আসলে কীসের জন্য অপেক্ষা করল।

পিং শতাংশ আসলে কী মাপে

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

প্রোবের ফলাফলটিকে পথ সম্পর্কে একটি ইঙ্গিত হিসেবে রাখুন। তারপর যে সময় ও সীমা এটি তৈরি করেছে তা খুঁজতে যান।

কাউন্টার ডেল্টা তুলনা করুন, আজীবন মোট নয়

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

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

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

যদি ড্রাইভার বিস্তারিত ভৌত কাউন্টার প্রকাশ করে, তবে সেই অ্যাডাপ্টারের ডকুমেন্টেশন দিয়ে সেগুলো পড়ুন। দুই প্রস্তুতকারকের মধ্যে “drop” নামের প্রতিটি ক্ষেত্রকে একটি অর্থ দেওয়াই স্বাভাবিক হিসাবি অদ্ভুততাকে হার্ডওয়্যার রোগনির্ণয়ে পরিণত করার উপায়।

হারানো সেগমেন্ট কীভাবে দীর্ঘ অপেক্ষা হয়

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

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

যেখানে ক্যাপচার অনুমোদিত, সেখানে তা সংকীর্ণ রাখুন। আপনার দরকার প্রত্যাশিত প্যাকেট বা স্বীকৃতি নির্দিষ্ট সীমায় থামে কি না, কোনো ব্যস্ত ট্রেসে কোথাও পুনঃপ্রেরণ আছে কি না তা নয়।

অন্যগুলো না সরিয়ে একটি সীমা বদলান

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

পরিষ্কার স্থানীয় কাউন্টার বাকি পথের সনদ দেয় না। তারা আপনি যে অংশ দেখেন তা সীমাবদ্ধ করে, আর সৎ প্রতিবেদন বলে কোন সীমাগুলো পর্যবেক্ষণ করা হয়েছে আর কোনগুলো হয়নি। শেষে আপনার দরকার এমন একটি বিবৃতি যে একটি হস্তক্ষেপ ঘটলে একটি পর্যবেক্ষণ বদলেছে, খারাপ কেবলের একটি উপকথা যা সর্বজনীন নিয়মে উন্নীত হয়েছে তা নয়।