प्रॉक्सी के ज़रिए TCP शून्य विंडो: प्राप्तकर्ता की पहचान करें

पैकेट ट्रेस कहता है TCP ZeroWindow। कर्नेल सेटिंग बदलने से पहले उस अंतिम बिंदु की पहचान करें जो शून्य की घोषणा कर रहा है।

वह अंतिम बिंदु उस TCP कनेक्शन पर अपनी प्राप्ति क्षमता बता रहा है। यह नहीं बता रहा कि पूरे प्रॉक्सी के पास कितनी बैंडविड्थ है। शून्य-विंडो प्रोब भेजने वाले को यह जानने देता है कि घोषित क्षमता बदली है या नहीं; अकेले प्रोब पैकेट हानि या खराब प्रॉक्सी सिद्ध नहीं करते।

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

ये अलग TCP बातचीत हैं। मान लें कि ब्राउज़र एक बड़ी प्रतिक्रिया पढ़ना बंद कर देता है और A पर शून्य घोषित करता है। प्रॉक्सी के अपने बफ़र भरते ही वह अंततः B को खाली करना बंद कर सकता है। B पर बाद में दिखने वाली शून्य विंडो मूल समस्या नहीं, बल्कि धीमे क्लाइंट का परिणाम हो सकती है।

अपलोड के दौरान उलटी स्थिति संभव है। यदि गंतव्य एप्लिकेशन डेटा उपभोग करना बंद कर दे, तो B पर उसकी विंडो बंद हो सकती है। तब दबाव प्रॉक्सी के बफ़र से होते हुए क्लाइंट की ओर वापस जा सकता है।

अवलोकनों को क्रम में रखें

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

Wireshark के विंडो विश्लेषण लेबल कैप्चर की उपयोगी व्याख्या हैं, हर प्राप्ति बफ़र बढ़ाने का निर्देश नहीं। विंडो स्केलिंग को भी कनेक्शन की बातचीत के संदर्भ में समझना चाहिए।

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