ഫോർവേഡ് പ്രോക്സി സ്ട്രീമിംഗും പൂർണ്ണ-പ്രതികരണ ബഫറിംഗും

ഡൗൺലോഡ് കാത്തിരിക്കുന്നതായി തോന്നുമ്പോൾ മൂന്ന് സംഭവങ്ങൾ വേർതിരിക്കുക: പ്രതികരണ ഹെഡറുകൾ എത്തുന്നത്, ബോഡി ബൈറ്റുകൾ എത്തുന്നത്, ആപ്ലിക്കേഷന് ഫലം ഉപയോഗിക്കാനോ കാണിക്കാനോ കഴിയുന്നത്. സ്പിന്നർ മാത്രം ഏതാണ് വൈകുന്നതെന്ന് തിരിച്ചറിയാനാവില്ല.

സാധാരണ സ്ട്രീമിംഗ് ഘട്ടങ്ങൾ ഒന്നിനുമേൽ ഒന്ന് വരാം:

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

പ്രോക്സിക്ക് റിലേ ചെയ്യുമ്പോൾ യോഗ്യമായ ഉള്ളടക്കം കാഷെയിലേക്ക് എഴുതാം. കാഷിംഗിന് മുഴുവൻ ഫയലും കാത്തിരിക്കേണ്ടതില്ല. Squid-ന്റെ read_ahead_gap ഡെലിവറിക്ക് മുന്നോട്ട് പോകുന്ന റിട്രീവൽ നിയന്ത്രിക്കുന്നു, അത് മറ്റൊരു തരം ബഫറിംഗാണ്.

പതുക്കെയുള്ള ക്ലയന്റ് ഔട്ട്പുട്ട് ക്യൂകൾ നിറയ്ക്കുമ്പോൾ ബാക്ക്പ്രഷർ അപ്സ്ട്രീം വായന താൽക്കാലികമായി നിർത്താം. Content-Length പൂർണ്ണ ബഫറിംഗ് ഇല്ലാതെ നീളം നൽകുന്നു. HTTP/1.1 chunked എൻകോഡിംഗ് ക്രമാനുഗത ഡെലിവറി അനുവദിക്കുന്നു, എന്നാൽ മുൻ ഘടകം ഡാറ്റ പിടിച്ചുവെക്കുന്നെങ്കിൽ കുറഞ്ഞ ലാറ്റൻസി വാഗ്ദാനം ചെയ്യാനാവില്ല.

തുടർന്ന് പ്രോസസ്സിംഗ് ഘട്ടങ്ങൾ പരിശോധിക്കുക. വീണ്ടും എഴുത്തിനോ പരിശോധനയ്ക്കോ ബോഡിയുടെ ഒരു ഭാഗം അല്ലെങ്കിൽ മുഴുവൻ ആവശ്യമായേക്കാം. കംപ്രഷനും ആപ്ലിക്കേഷൻ ഫ്രെയിമിംഗും ഉപയോഗപ്രദമായ ഔട്ട്പുട്ട് വൈകിപ്പിക്കാം. ക്ലയന്റിൽ പൂർണ്ണ ബൈറ്റ് അറേ കാത്തിരിക്കുന്ന രീതി വൈകി മടങ്ങുന്നു, ബ്രൗസറിന് കാണിക്കുന്നതിന് മുൻപ് ബൈറ്റുകൾ ലഭിച്ചേക്കാം.

വിജയകരമായ CONNECT-ന് ശേഷം സാധാരണ പ്രോക്സി ടണൽ ചെയ്ത ഫയലിന്റെ അന്തിമ നീളം അറിയാതെ സേവന സ്ട്രീം റിലേ ചെയ്യുന്നു. ബഫർ അല്ലെങ്കിൽ ടൈംഔട്ട് ക്രമീകരണങ്ങൾ മാറ്റുന്നതിന് മുൻപ് മുകളിലെ ആദ്യ നഷ്ടപ്പെട്ട സംഭവം പിന്തുടരുക. curl നിരീക്ഷകനാകുമ്പോൾ അതിന്റെ no-buffer ഓപ്ഷൻ പ്രാദേശിക ഔട്ട്പുട്ട് ഘട്ടം മാറ്റുന്നു.