فارورڈ پراکسی اسٹریمنگ بمقابلہ مکمل جواب کی بفرنگ

جب ڈاؤن لوڈ انتظار کرتا دکھے تو تین واقعات الگ کریں: جوابی ہیڈرز کا آنا، باڈی بائٹس کا آنا، اور ایپلی کیشن کا نتیجہ استعمال یا دکھا سکنا۔ صرف اسپنر یہ نہیں بتا سکتا کہ کون سی چیز تاخیر کا شکار ہے۔

عام اسٹریمنگ مراحل ایک دوسرے پر آ سکتے ہیں:

origin produces a chunk → proxy forwards bytes → client consumes them

پراکسی ریلیٹ کرتے ہوئے موزوں مواد کیش میں لکھ سکتی ہے۔ کیشنگ کے لیے پوری فائل کا انتظار ضروری نہیں۔ Squid کا read_ahead_gap ڈیلیوری سے آگے چلنے والی بازیافت کو کنٹرول کرتا ہے، جو بفرنگ کی دوسری قسم ہے۔

سست کلائنٹ آؤٹ پٹ قطاریں بھر دے تو بیک پریشر اوپر کی جانب پڑھائی کو عارضی طور پر روک سکتا ہے۔ Content-Length بھی مکمل بفرنگ کے بغیر لمبائی فراہم کرتا ہے۔ HTTP/1.1 chunked انکوڈنگ بتدریج ڈیلیوری کی اجازت دیتی ہے، لیکن اگر پہلا کوئی جزو ڈیٹا روکے رکھے تو کم تاخیر کا وعدہ نہیں کر سکتی۔

پھر پروسیسنگ مراحل دیکھیں۔ دوبارہ لکھنے یا معائنے کے لیے باڈی کا کچھ حصہ یا پوری باڈی درکار ہو سکتی ہے۔ کمپریشن اور ایپلی کیشن فریمنگ مفید آؤٹ پٹ میں تاخیر کر سکتے ہیں۔ کلائنٹ پر مکمل بائٹ ایرے کا انتظار کرنے والا طریقہ دیر سے واپس آتا ہے، اور براؤزر دکھانے سے پہلے بائٹس وصول کر سکتا ہے۔

کامیاب CONNECT کے بعد عام پراکسی ٹنل شدہ فائل کی حتمی لمبائی جانے بغیر سروس اسٹریم ریلیٹ کرتی ہے۔ بفر یا ٹائم آؤٹ کی ترتیبات بدلنے سے پہلے اوپر دیے گئے پہلے غائب واقعے کی پیروی کریں۔ جب curl ناظر ہو، اس کا no-buffer آپشن مقامی آؤٹ پٹ مرحلہ بدل دیتا ہے۔