ଫରୱାର୍ଡ ପ୍ରକ୍ସି ଷ୍ଟ୍ରିମିଂ ବନାମ ସମ୍ପୂର୍ଣ୍ଣ-ପ୍ରତିକ୍ରିୟା ବଫରିଂ

ଡାଉନଲୋଡ୍ ଅପେକ୍ଷା କରୁଥିବା ପରି ଲାଗିଲେ ତିନିଟି ଘଟଣା ଅଲଗା କରନ୍ତୁ: ପ୍ରତିକ୍ରିୟା ହେଡର ଆସିବା, ବଡି ବାଇଟ୍ ଆସିବା, ଏବଂ ଆପ୍ଲିକେସନ ଫଳାଫଳ ବ୍ୟବହାର କିମ୍ବା ଦେଖାଇବାରେ ସକ୍ଷମ ହେବା। କେବଳ ସ୍ପିନର କେଉଁଟି ବିଳମ୍ବିତ ତାହା ଚିହ୍ନଟ କରିପାରିବ ନାହିଁ।

ସାଧାରଣ ଷ୍ଟ୍ରିମିଂ ପର୍ଯ୍ୟାୟଗୁଡ଼ିକ ଓଭରଲ୍ୟାପ୍ ହୋଇପାରେ:

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

ପ୍ରକ୍ସି ରିଲେ କରିବା ସମୟରେ ଉପଯୁକ୍ତ ବିଷୟବସ୍ତୁ କ୍ୟାଶେକୁ ଲେଖିପାରେ। କ୍ୟାଶିଂ ସମ୍ପୂର୍ଣ୍ଣ ଫାଇଲ ଅପେକ୍ଷା ଆବଶ୍ୟକ କରେ ନାହିଁ। Squid ର read_ahead_gap ଡେଲିଭରି ପୂର୍ବରୁ ଚାଲୁଥିବା ପୁନଃପ୍ରାପ୍ତିକୁ ନିୟନ୍ତ୍ରଣ କରେ, ଯାହା ଅନ୍ୟ ଏକ ପ୍ରକାରର ବଫରିଂ।

ମନ୍ଥର କ୍ଲାୟେଣ୍ଟ ଆଉଟପୁଟ ଧାଡ଼ି ଭରିଦେଲେ ବ୍ୟାକପ୍ରେସର ଉପର ପଠନକୁ ସାମୟିକ ଭାବେ ଅଟକାଇପାରେ। Content-Length ମଧ୍ୟ ସମ୍ପୂର୍ଣ୍ଣ ବଫରିଂ ବିନା ଲମ୍ବ ଦିଏ। HTTP/1.1 chunked ଏନକୋଡିଂ କ୍ରମିକ ଡେଲିଭରି ଅନୁମତି ଦିଏ, କିନ୍ତୁ ପୂର୍ବ ଉପାଦାନ ତଥ୍ୟ ଧରି ରଖିଲେ କମ୍ ଲେଟେନ୍ସିର ପ୍ରତିଶ୍ରୁତି ଦେଇପାରିବ ନାହିଁ।

ତାପରେ ପ୍ରକ୍ରିୟାକରଣ ପର୍ଯ୍ୟାୟ ଯାଞ୍ଚ କରନ୍ତୁ। ପୁନଃଲେଖନ କିମ୍ବା ନିରୀକ୍ଷଣକୁ ବଡିର ଅଂଶ କିମ୍ବା ସମ୍ପୂର୍ଣ୍ଣ ଆବଶ୍ୟକ ହୋଇପାରେ। ସଙ୍କୋଚନ ଏବଂ ଆପ୍ଲିକେସନ ଫ୍ରେମିଂ ଉପଯୋଗୀ ଆଉଟପୁଟକୁ ବିଳମ୍ବିତ କରିପାରେ। କ୍ଲାୟେଣ୍ଟରେ ସମ୍ପୂର୍ଣ୍ଣ ବାଇଟ୍ ଆରେ ଅପେକ୍ଷା କରୁଥିବା ପଦ୍ଧତି ଡେରିରେ ଫେରେ, ଏବଂ ବ୍ରାଉଜର ଦେଖାଇବା ପୂର୍ବରୁ ବାଇଟ୍ ଗ୍ରହଣ କରିପାରେ।

ସଫଳ CONNECT ପରେ ସାଧାରଣ ପ୍ରକ୍ସି ଟନେଲ୍ ହୋଇଥିବା ଫାଇଲର ଅନ୍ତିମ ଲମ୍ବ ନଜାଣି ସେବା ଷ୍ଟ୍ରିମ୍ ରିଲେ କରେ। ବଫର କିମ୍ବା ଟାଇମଆଉଟ ସେଟିଂ ବଦଳାଇବା ପୂର୍ବରୁ ଉପରର ପ୍ରଥମ ଅନୁପସ୍ଥିତ ଘଟଣା ଅନୁସରଣ କରନ୍ତୁ। ଯେତେବେଳେ curl ପର୍ଯ୍ୟବେକ୍ଷକ, ଏହାର no-buffer ବିକଳ୍ପ ସ୍ଥାନୀୟ ଆଉଟପୁଟ ପର୍ଯ୍ୟାୟ ବଦଳାଏ।