नेटस्टैट कमांड आउटपुट में रिकव-क्यू और सेंड-क्यू कॉलम का उपयोग क्या है और जब हम रीयलटाइम परिदृश्य में इसका उपयोग करते हैं? मेरे सिस्टम में दोनों कॉलम हमेशा शून्य के रूप में दिखाया जाता है। इसके लिए क्या अर्थ है?रिकव-क्यू और सेंड-क्यू
मेरा आदमी पृष्ठ से:
Recv-क्यू
स्थापित: उपयोगकर्ता कार्यक्रम इस सॉकेट से जुड़ा द्वारा कॉपी नहीं बाइट्स की गिनती।
सुनना: कर्नेल 2.6.18 के बाद से इस कॉलम में वर्तमान syn बैकलॉग है।
संदेश-क्यू
स्थापित: दूरस्थ मेजबान द्वारा स्वीकार नहीं बाइट्स की गिनती।
सुनना: कर्नेल 2.6.18 के बाद से इस कॉलम में अधिकतम बैकलॉग के अधिकतम आकार शामिल हैं।
यदि आप 0 पर फंस गए हैं, तो इसका मतलब यह है कि कनेक्शन के दोनों तरफ आपके अनुप्रयोग, और उनके बीच नेटवर्क ठीक है। वास्तविक तत्काल मान 0 से अलग हो सकते हैं, लेकिन इस तरह के क्षणिक, भगोड़े तरीके से आपको वास्तव में इसका निरीक्षण करने का मौका नहीं मिलता है।
वास्तविक जीवन परिदृश्य के उदाहरण हैं, जहां इस 0 से अलग हो सकता (स्थापित कनेक्शन पर है, लेकिन मुझे लगता है कि आप अनुमान लगा सकेंगे कि):
मैं हाल ही में एक लिनक्स एम्बेडेड डिवाइस एक से बात कर रही पर काम किया (खराब डिजाइन) तीसरे पक्ष के उपकरण। इस तीसरे पक्ष के डिवाइस पर, एप्लिकेशन कभी-कभी अटक जाता है, टीसीपी कनेक्शन पर प्राप्त डेटा को नहीं पढ़ता है, जिसके परिणामस्वरूप इसकी टीसीपी विंडो 0 पर जा रही है और सेकंड के दस सेकंड के लिए वहां रहती है (घटना के बीच एक प्रतिबिंबित बंदरगाह पर वायरसहार्क के माध्यम से देखी गई घटना 2 मेजबान)। इस तरह के मामले में:
Recv-क्यू: तृतीय पक्ष डिवाइस (जो मैं था नहीं करने के लिए मतलब है) पर netstatचल रहा है, एक बढ़ती हुई Recv-क्यू दिखाने के लिए हो सकता है कुछ छत मूल्य तक जहां दूसरी तरफ (मुझे) डेटा भेजना बंद कर देता है क्योंकि विंडो 0 से नीचे हो जाती है, क्योंकि एप्लिकेशन पर उपलब्ध डेटा को नहीं पढ़ता है, और इन डेटा को ओएस में टीसीपी कार्यान्वयन में बफर नहीं किया जाता है, ओएस नहीं जा रहा है अटकने के लिए आवेदन ->रिसीवर तरफ से, आवेदन मुद्दा
संदेश-क्यू:netstatपर चल रहा है मेरी पक्ष (जो मैंने कोशिश नहीं की क्योंकि 1/समस्या wireshark से स्पष्ट हो गया था और और 2 से ऊपर पहला मामला था/यह नहीं 100% थी प्रतिलिपि प्रस्तुत करने योग्य) एक गैर शून्य संदेश-क्यू, अगर ओएस स्तर पर दूसरे पक्ष टीसीपी कार्यान्वयन stucked दिया है दिखाने के लिए और अपने डेटा को स्वीकार करना बंद कर दिया हो सकता है - इस ओर से>, टीसीपी कार्यान्वयन प्राप्त (आमतौर पर टी पर वह ओएस स्तर) मुद्दा।
ध्यान दें कि संदेश-क्यू परिदृश्य ऊपर दर्शाया भी एक भेजने के पक्ष मुद्दा (मेरी तरफ) अगर मेरी लिनक्स टीसीपी कार्यान्वयन दुर्व्यवहार करने और डेटा भेजने के लिए जारी किया गया था के बाद TCP विंडो 0 तक नीचे चला गया हो सकता है : प्राप्तकर्ता पक्ष के पास इस डेटा के लिए और अधिक जगह नहीं है -> ACKnowledge नहीं है।
यह भी ध्यान दें कि प्रेषक की वजह से सेंड-क्यू समस्या कारण नहीं हो सकती है, लेकिन प्रेषक और रिसीवर के बीच कहीं कुछ रूटिंग समस्या द्वारा। कुछ पैकेट 2 मेजबानों के बीच "फ्लाई पर" हैं, लेकिन अभी तक ACKnowledge नहीं हैं। दूसरी ओर, रिकव-क्यू समस्या निश्चित रूप से मेजबान पर है: प्राप्त पैकेट, ACKnowledged, लेकिन अभी तक एप्लिकेशन से नहीं पढ़ा गया है।
संपादित करें:
वास्तविक जीवन में, गैर भद्दा मेजबान और अनुप्रयोगों के रूप में आप काफी उम्मीद कर सकते हैं, मैं शर्त लगा सकता था संदेश-क्यू मुद्दे को कुछ मार्ग समस्या से समय की सबसे कारण होने की साथ/भेजने और प्राप्त करने के बीच नेटवर्क खराब प्रदर्शन। "मक्खी पर" पैकेट के राज्य कभी नहीं भूल जाना चाहिए:
पैकेट प्रेषक और प्राप्तकर्ता के बीच नेटवर्क पर हो सकता है,
(या प्राप्त लेकिन एसीके अभी तक नहीं भेजा, ऊपर देखें)
या एसीके रिसीवर और प्रेषक के बीच नेटवर्क पर हो सकता है।
यह एक पैकेट के लिए एक RTT (राउंड समय यात्रा) लेता जा और भेजने के लिए तो acked।