پراکسی کے ذریعے TCP Zero Window: وصول کنندہ کی شناخت کریں
رکے ہوئے ڈاؤن لوڈ کو window scaling یا buffer سائز سے منسوب کرنے سے پہلے یہ طے کریں کہ TCP فلو کنٹرول پراکسی کے کلائنٹ یا سرور کی طرف ہے۔
پیکٹ ٹریس TCP ZeroWindow دکھاتا ہے۔ kernel کی ترتیب بدلنے سے پہلے یہ شناخت کریں کہ صفر کا اعلان کون سا endpoint کر رہا ہے۔
وہ endpoint اُس TCP کنکشن پر اپنی وصولی کی صلاحیت بیان کر رہا ہے۔ یہ نہیں بتا رہا کہ پوری پراکسی کے پاس کتنی bandwidth دستیاب ہے۔ zero-window probe بھیجنے والے کو یہ جاننے دیتا ہے کہ اعلان کردہ صلاحیت بدلی ہے یا نہیں؛ probe بذات خود نہ packet loss ثابت کرتا ہے نہ خراب پراکسی۔
browser <-- TCP A --> proxy <-- TCP B --> websiteیہ دو الگ TCP گفتگو ہیں۔ فرض کریں کہ browser ایک بڑی response پڑھنا بند کر دیتا ہے اور A پر صفر کا اعلان کرتا ہے۔ پراکسی اپنے buffers بھرتے ہی B سے کھینچنا بند کر سکتی ہے۔ بعد میں B پر آنے والا zero window سست کلائنٹ کا نتیجہ ہو سکتا ہے، اصل مسئلہ نہیں۔
اپ لوڈ کے دوران اُلٹ صورت ممکن ہے۔ اگر منزل کا ایپلیکیشن ڈیٹا استعمال کرنا بند کر دے تو B پر اس کی window بند ہو سکتی ہے۔ دباؤ پھر پراکسی کے buffers کے ذریعے کلائنٹ کی طرف واپس جا سکتا ہے۔
مشاہدات کو ترتیب دیں
- کنکشن کے دونوں سرے اور متاثرہ ڈیٹا کی منتقلی کی سمت درج کریں۔
- شناخت کریں کہ سب سے پہلے کس endpoint نے سکڑتی یا صفر ہوتی receive window کا اعلان کیا۔
- دیکھیں کہ اس کا ایپلیکیشن پڑھ رہا تھا، کسی اور عمل پر رکا تھا، یا وسائل سے محدود تھا۔
- اصل وجہ مقرر کرنے سے پہلے پراکسی کے دوسرے کنکشن پر وقت کا موازنہ کریں۔
Wireshark کے window تجزیے کے لیبل capture کی مفید تشریحات ہیں، ہر receive buffer بڑھانے کی ہدایت نہیں۔ window scaling کو بھی کنکشن کی گفت و شنید کے تناظر میں سمجھنا ضروری ہے۔
پراکسی فہرست سے دوسرا endpoint آزمانا اور منتقلی کا بحال ہونا اس بات کا مفید ثبوت ہے کہ راستہ بدل گیا۔ یہ بذات خود ثابت نہیں کرتا کہ کسی آپریٹنگ سسٹم کا TCP نفاذ معیوب تھا۔ وضاحت کو وصول کرنے والے عمل اور اُس کنکشن سے جوڑے رکھیں جہاں انتظار شروع ہوا۔