فارورڈ پراکسی TCP سیگمنٹ کی حدود محفوظ نہیں رکھتی

فرض کریں کہ Squid سے گزرنے کے بعد کوئی HTTP جواب کئی قبضہ شدہ TCP سیگمنٹس میں نظر آتا ہے۔ یہ عام TCP رویہ ہو سکتا ہے، اس بات کا ثبوت نہیں کہ جواب غلط طریقے سے تقسیم ہوا۔

فارورڈ پراکسی کے عام طور پر دو کنکشن ہوتے ہیں:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

ہر کنکشن کی اپنی TCP حالت، ترتیبی نمبر اور پیکٹ بندی ہوتی ہے۔ پراکسی ایک کنکشن سے ڈیٹا پڑھ کر دوسرے میں لکھ سکتی ہے، اصل سیگمنٹ سائز محفوظ رکھے بغیر۔ بفرنگ، بھیجنے کا وقت، رش اور راستے کی سائز حدود کوئی دوسرا گروپ بنا سکتے ہیں۔

تین حدود جنہیں الگ رکھنا چاہیے

ایک ریڈ میں ہیڈر کا کوئی حصہ، پورا ہیڈر ساتھ باڈی بائٹس، یا ایک سے زیادہ ایپلیکیشن سطح کی حدود عبور کرنے والا ڈیٹا ہو سکتا ہے۔ TCP ”HTTP جواب کے اختتام“ کو کامیاب ریڈ کے اختتام سے نہیں جوڑتا۔

اسی لیے HTTP/1.1 پارسر ہیڈر جمع کرتا ہے اور لاگو باڈی فریمنگ اصول استعمال کرتا ہے، جن میں لمبائی، ٹرانسفر کوڈنگ یا اجازت شدہ کنکشن بندش شامل ہے۔ HTTP/2 فریم ایک پروٹوکول ساخت ہے جو خود TCP سیگمنٹس عبور کر سکتی ہے؛ یہ نیٹ ورک پیکٹ کا دوسرا نام نہیں۔

کامیاب CONNECT سرنگ سرنگ کے اندر بائٹ بہاؤ محفوظ رکھتی ہے، پھر بھی دو TCP ٹانگیں استعمال کرتی ہے۔ پراکسی نے سرنگ کے اندر بائٹس نہ بدلے ہوں تب بھی اس کی سیگمنٹ حدود مختلف ہو سکتی ہیں۔

خرابی کی چھان بین کرتے وقت دوبارہ جوڑا گیا ایپلیکیشن ڈیٹا موازنہ کریں۔ پیکٹ گنتی کا موازنہ کرنا یا دونوں طرف یکساں پیکٹ لمبائی کی توقع کرنا TCP سے ایسی حد کی ضمانت مانگنا ہے جو وہ نہیں دیتا۔