Streaming sa forward proxy kumpara sa buffering ng buong tugon

Kapag ang isang download ay tila naghihintay, ihiwalay ang tatlong pangyayari: pagdating ng mga header ng tugon, pagdating ng mga byte ng katawan, at kakayahan ng aplikasyon na gamitin o ipakita ang resulta. Ang spinner lamang ay hindi matukoy kung alin ang naantala.

Ang mga normal na yugto ng streaming ay maaaring magsalap.

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

Maaaring isulat ng proxy ang karapat-dapat na nilalaman sa cache habang ipinapasa ito. Ang caching ay hindi nangangailangan ng paghihintay sa buong file. Ang read_ahead_gap ng Squid ay kumokontrol sa pagkuha na nauuna sa paghahatid, na isa pang uri ng buffering.

Ang backpressure ay maaaring pansamantalang magpahinto sa pagbasa sa upstream kapag pinuno ng mabagal na kliyente ang mga pila ng output. Ang Content-Length ay nagbibigay din ng haba nang hindi nangangailangan ng buong buffering. Ang HTTP/1.1 chunked encoding ay nagpapahintulot ng unti-unting paghahatid, ngunit hindi makakapangako ng mababang latency kung may naunang bahagi na humahawak sa data.

Susunod, siyasatin ang mga yugto ng pagpoproseso. Ang muling pagsulat o inspeksyon ay maaaring mangailangan ng bahagi o buong katawan. Ang compression at application framing ay maaaring magpabagal sa kapaki-pakinabang na output. Sa kliyente, ang isang paraang naghihintay sa buong byte array ay huling bumabalik, at ang browser ay maaaring makatanggap ng mga byte bago pa ito maipakita.

Pagkatapos ng matagumpay na CONNECT, ipinapasa ng ordinaryong proxy ang stream ng serbisyo nang hindi kailangan ang huling haba ng naka-tunnel na file. Sundin ang unang nawawalang pangyayari sa itaas bago baguhin ang mga setting ng buffer o timeout. Kapag ang curl ang tagamasid, binabago ng no-buffer na opsyon nito ang lokal na yugto ng output.