प्रॉक्सीमधून TCP शून्य विंडो: प्राप्तकर्ता ओळखा

पॅकेट ट्रेस TCP ZeroWindow दाखवतो. कर्नेल सेटिंग बदलण्यापूर्वी शून्य जाहीर करणारा टोकाचा बिंदू ओळखा.

तो टोकाचा बिंदू त्या TCP कनेक्शनवरील आपली स्वीकारण्याची क्षमता वर्णन करत आहे. तो संपूर्ण प्रॉक्सीकडे किती बँडविड्थ आहे हे जाहीर करत नाही. शून्य-विंडो प्रोब पाठवणाऱ्याला जाहीर केलेली क्षमता बदलली आहे का हे जाणून घेण्यास अनुमती देतो; फक्त प्रोब पॅकेट हानी किंवा बिघडलेली प्रॉक्सी सिद्ध करत नाहीत.

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

हे वेगळे TCP संवाद आहेत. ब्राउझरने मोठा प्रतिसाद वाचणे थांबवले आणि A वर शून्य जाहीर केले असे समजा. प्रॉक्सीचे स्वतःचे बफर भरताच तो शेवटी B रिकामे करणे थांबवू शकतो. B वर नंतर दिसणारी शून्य विंडो मूळ समस्या नसून संथ क्लायंटचा परिणाम असू शकते.

अपलोडच्या वेळी उलट परिस्थिती शक्य आहे. जर गंतव्य ॲप्लिकेशनने डेटा वापरणे थांबवले, तर B वरील त्याची विंडो बंद होऊ शकते. मग दबाव प्रॉक्सीच्या बफरमधून क्लायंटकडे परत जाऊ शकतो.

निरीक्षणे क्रमाने ठेवा

1. कनेक्शनची टोके आणि प्रभावित डेटा हस्तांतरणाची दिशा नोंदवा.
2. कोणत्या टोकाने प्रथम आकुंचन पावणारी किंवा शून्य स्वीकार विंडो जाहीर केली ते ओळखा.
3. त्याचे ॲप्लिकेशन वाचत होते का, दुसऱ्या क्रियेवर थांबले होते का, किंवा संसाधनांमुळे मर्यादित होते का ते तपासा.
4. मूळ कारण निश्चित करण्यापूर्वी प्रॉक्सीच्या दुसऱ्या कनेक्शनवरील वेळेशी तुलना करा.

Wireshark ची विंडो विश्लेषण लेबले कॅप्चरची उपयुक्त व्याख्या आहेत, प्रत्येक स्वीकार बफर वाढवण्याची सूचना नाही. विंडो स्केलिंगचाही कनेक्शनच्या वाटाघाटीच्या संदर्भात अर्थ लावावा लागतो.

प्रॉक्सी यादीमधून दुसरा टोकाचा बिंदू वापरून पाहणे आणि हस्तांतरण सुधारल्याचे दिसणे हा मार्ग बदलल्याचा उपयुक्त पुरावा आहे. पण ते स्वतःच कोणत्याही ऑपरेटिंग सिस्टमची TCP अंमलबजावणी दोषपूर्ण होती हे सिद्ध करत नाही. स्पष्टीकरण स्वीकारणाऱ्या प्रक्रियेशी आणि जिथे प्रतीक्षा सुरू झाली त्या कनेक्शनशी जोडून ठेवा.