प्याकेट ट्रेसले TCP ZeroWindow देखाउँछ। कर्नेल सेटिङ बदल्नुअघि शून्य घोषणा गर्ने अन्त्य बिन्दु पहिचान गर्नुहोस्।

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

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

यी छुट्टाछुट्टै TCP वार्तालाप हुन्। मानौं ब्राउजरले ठूलो प्रतिक्रिया पढ्न छोड्छ र A मा शून्य घोषणा गर्छ। प्रोक्सीले आफ्नै बफर भरिँदै जाँदा अन्ततः B खाली गर्न छोड्न सक्छ। B मा पछि देखिने शून्य विन्डो मूल समस्या नभई ढिलो क्लाइन्टको परिणाम हुन सक्छ।

अपलोडका बेला उल्टो अवस्था सम्भव छ। यदि गन्तव्य अनुप्रयोगले डेटा उपभोग गर्न छोड्यो भने B मा त्यसको विन्डो बन्द हुन सक्छ। त्यसपछि दबाब प्रोक्सीका बफर हुँदै क्लाइन्टतर्फ फर्कन सक्छ।

अवलोकनहरू क्रममा राख्नुहोस्

  1. जडानका दुवै अन्त्य र प्रभावित डेटा स्थानान्तरणको दिशा टिपोट गर्नुहोस्।
  2. कुन अन्त्यले पहिलो पटक घट्दै गएको वा शून्य प्राप्ति विन्डो घोषणा गर्‍यो पहिचान गर्नुहोस्।
  3. त्यसको अनुप्रयोग पढिरहेको थियो, अर्को कार्यमा रोकिएको थियो, वा स्रोतले सीमित थियो कि जाँच्नुहोस्।
  4. मूल कारण तोक्नुअघि प्रोक्सीको अर्को जडानमा समयको तुलना गर्नुहोस्।

Wireshark का विन्डो विश्लेषण लेबल क्याप्चरका उपयोगी व्याख्या हुन्, हरेक प्राप्ति बफर बढाउने निर्देशन होइन। विन्डो स्केलिङलाई पनि जडानको वार्तालापको सन्दर्भमा व्याख्या गर्नुपर्छ।

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

सम्बन्धित लेखहरू