د فارورډ پروکسي سټریمینګ د بشپړ ځواب بفر کولو په مقابل کې
کله چې ډاونلوډ په پروکسي کې د انتظار په حال کې ښکاري، سټریمینګ، مخکې لوستلو بفر او د بشپړ ځواب پروسس کول جلا کړئ.
کله چې ډاونلوډ د انتظار په حال کې ښکاري، درې پېښې جلا کړئ: د ځواب سرلیکونو راتګ، د بدن بایټونو راتګ، او د اپلیکیشن وړتیا چې پایله وکاروي یا ښکاره کړي. یوازې سپینر نشي کولی وټاکي چې کوم یو ځنډېدلی دی.
د سټریمینګ نور مرحلې کولی شي یو بل ته ورتېرې شي:
origin produces a chunk → proxy forwards bytes → client consumes themپروکسي کولی شي د لېږد په مهال مناسب منځپانګه کېش ته ولیکي. کېش کول د ټول فایل انتظار ته اړتیا نلري. Squid read_ahead_gap هغه ترلاسه کول کنټرولوي چې له سپارلو مخکې روان دي، او دا د بفر کولو بله بڼه ده.
کله چې ورو کلاینټ د وتلو کرښې ډکې کړي، ضد فشار کولی شي د پورتنۍ لوستنې لنډمهاله ودروي. Content-Length هم پرته له بشپړ بفر اوږدوالی درکوي. HTTP/1.1 chunked کوډ کول پرلهپسې سپارل اجازه ورکوي، خو که پخوانی برخه ډاټا وساتي، ټیټ ځنډ نشي ژمن کولی.
بیا د پروسس مرحلې وګورئ. بیا لیکل یا پلټنه ممکن د بدن یوه برخه یا ټول بدن ته اړتیا ولري. کمپریشن او د اپلیکیشن چوکاټ کولی شي ګټور وتل وځنډوي. په کلاینټ کې هغه طریقه چې د بشپړ بایټ ارې انتظار کوي وروسته راګرځي، او براوزر ممکن بایټونه ترلاسه کړي مخکې لدې چې ښکاره یې کړي.
له بریالي CONNECT وروسته عادي پروکسي د تونل شوي فایل نهايي اوږدوالی ته اړتیا پرته د خدمت جریان لیږدوي. مخکې لدې چې د بفر یا وخت محدودیت تنظیمات بدل کړئ، پورتنی لومړی ورک شوی پېښه تعقیب کړئ. کله چې curl څارونکی وي، د هغه no-buffer انتخاب محلي وتلو مرحله بدلوي.