केबललाई दोष दिनुअघि प्याकेट लस कसरी पढ्ने

लामो पिङ दौडमा दुई प्रतिशत लस तपाईंले कारबाही गर्न सक्ने अङ्क जस्तो लाग्छ, र त्यस्तो हुनु दुर्लभ छ। यसले उत्तरहरू कहाँ हराए, तिनीहरू सँगै हराए कि, वा कुनै विशेष एप्लिकेसनले त्यो अन्तराल कसरी अनुभव गर्यो भन्ने बताउँदैन। एक मिनेटभरि समान रूपमा फैलिएको लस र एउटै आदानप्रदानभित्र जम्मा भएको लस एउटै प्रतिशतका लागि धेरै फरक नतिजा दिन्छन्।

एउटामा भरोसा गर्नुको सट्टा तीन मापनको तुलना गर्नुहोस्: प्रोबले के देख्यो, इन्टरफेस काउन्टरले के गर्यो र एप्लिकेसनले वास्तवमा के कुरिरहेको थियो।

पिङ प्रतिशतले वास्तवमा के नाप्छ

इको प्रोबले एउटा प्रोटोकलको एउटा दिशा एउटा प्याकेट आकारमा, तपाईंले छानेको जुनसुकै दरमा जाँच्छ। ठूलो अपलोड बोक्ने सुरुङ पूर्ण रूपमा अर्कै काम गरिरहेको हुन्छ, र साना प्रोब फाल्ने लिङ्क स्थानान्तरणलाई हानि गरिरहेको लिङ्क हुनैपर्छ भन्ने छैन। प्रतिशतले सबैभन्दा महत्त्वपूर्ण समयको जानकारी पनि किचलेर फाल्छ, किनकि एउटै झोकमा हराएका दस उत्तर एक घण्टाको अन्तरालमा हराएका दस उत्तरसँग बराबर हुँदैनन्। सुरुङको कुन पक्षले केही फाल्यो भन्ने पनि यसले बताउन सक्दैन।

प्रोबको नतिजालाई मार्गबारे सङ्केतका रूपमा राख्नुहोस्। त्यसपछि त्यो उत्पन्न गर्ने समय र सीमा खोज्नुहोस्।

जीवनभरका जोड नभई काउन्टर भिन्नताको तुलना गर्नुहोस्

लक्षण देखा परेको झ्यालअघि र पछि, दुवै छेउमा र तपाईंले नियन्त्रण गर्ने जुनसुकै स्विच पोर्टमा समय-छापिएका पठन लिनुहोस्। त्रुटि, फालिएका र लिङ्क-अवस्थाका परिवर्तनसँगै ट्राफिकको मात्रा लेख्नुहोस्, किनकि महिनौँमा जम्मा भएको शून्य नभएको जोडले यो घटना होइन, इतिहास वर्णन गर्छ। रोकावटका बेला तीनले सरेको काउन्टर तीन हजार देखाउने र कहिल्यै नबदलिएको काउन्टरभन्दा फरक अवलोकन हो।

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

ग्रहण त्रुटिका कारण फालिएका प्याकेट र अन्य कारणले फालिएका प्याकेट छुट्टाछुट्टै काउन्टरमा बस्छन्, र यो भिन्नताले अर्को कदम बदल्छ। त्रुटि काउन्टरले भौतिक वा ड्राइभर तहतिर सङ्केत गर्छन्, जबकि लाइनको दबाब र नीति-फाल्नेले त्यसभन्दा माथि कतै सङ्केत गर्छन्। दिशा र इन्टरफेसको नाम पनि सुरक्षित राख्नुहोस्, किनकि अपलिङ्कमा ग्रहण-त्रुटिको वृद्धि र सुरुङ प्याकेट काउन्टर परस्पर बदल्न मिल्दैन।

यदि ड्राइभरले विस्तृत भौतिक काउन्टर देखाउँछ भने, ती त्यो एडाप्टरको कागजातबाट पढ्नुहोस्। दुई उत्पादकमा “drop” नामको प्रत्येक क्षेत्रलाई एउटै अर्थ दिनु भनेको सामान्य लेखा-सम्बन्धी अनौठोपनलाई हार्डवेयर निदानमा बदल्ने बाटो हो।

हराएको खण्ड कसरी लामो प्रतीक्षा बन्छ

खण्ड हराएपछि एप्लिकेसनले एक फेरीभन्दा धेरै लामो समय कुर्न सक्छ। TCP यात्राको समय अनुमान गर्छ, त्यो अनुमानबाट पुनःपठन टाइमर गणना गर्छ र पुनःपठन पनि असफल भएमा पछि हट्छ, त्यसैले गलत क्षणमा हराएको एउटै खण्डले अनुरोधलाई देखिने अन्तरालसम्म रोक्न सक्छ। यो संयन्त्र RFC 6298 मा निर्दिष्ट छ, र क्षुल्लक देखिने लस दर पनि किन महसुस हुन्छ भन्ने यसले स्पष्ट पार्छ।

तर प्रत्येक विराम पुनःपठन समय-समाप्ति होइन। त्यही प्रतीक्षा नाम-समाधान, सुस्त सर्भर वा असफलतापछि आफ्नै अनुरोध फेरि प्रयास गर्ने एप्लिकेसनबाट आउन सक्छ। असफल कार्यलाई यातायात अवलोकन र सुरुङकै सत्र घटनासँग मिलाएर ती केसहरू छुट्याउनुहोस्। पुनःजडान बिना डेटा मार्गमा अवरोध नयाँ ह्यान्डसेक र प्रमाणपत्र आदानप्रदानभन्दा फरक घटना हो।

जहाँ क्याप्चर अनुमति छ त्यहाँ यसलाई साँघुरो राख्नुहोस्। तपाईंलाई चाहिने कुरा अपेक्षित प्याकेट वा स्वीकृतिहरू कुनै विशेष सीमामा रोकिन्छन् कि भन्ने हो, व्यस्त ट्रेसमा कतै पुनःपठन छ भन्ने तथ्य होइन।

अरूलाई नसारी एउटा सीमा बदल्नुहोस्

यदि प्रमाणले स्थानीय लिङ्कतिर सङ्केत गर्छ भने, नियन्त्रित तुलनाका रूपमा स्वीकृत केबल वा पोर्ट बदल्नुहोस् र बाँकी सबै त्यसै छोड्नुहोस्। छेउ, एप्लिकेसन र कामको भार तुलनीय राख्नुहोस्, र प्रत्येक प्रयासमा ठ्याक्कै एउटा सीमा बदल्नुहोस्। वायर भएको ल्यापटपलाई वायरलेससँग तुलना गर्दा निकास र प्रोटोकल पनि बदल्नु भनेको तपाईंले आरोपित गर्न सक्ने केही पनि थाहा नपाउनु हो।

सफा स्थानीय काउन्टरले बाँकी मार्गको प्रमाण दिँदैनन्। तिनीहरूले तपाईंले देख्ने भाग सीमित गर्छन्, र इमानदार प्रतिवेदनले कुन सीमा अवलोकन गरियो र कुन गरिएन भन्छ। अन्तमा तपाईंलाई एउटा हस्तक्षेप हुँदा एउटा अवलोकन बदलियो भन्ने कथन चाहिन्छ, नराम्रो केबलबारेको कथा जसलाई सार्वभौमिक नियम बनाइयो त्यो होइन।