Streaming via forward-proxy kontra full responsbuffering

Når ei nedlasting ser ut til å vente, skil tre hendingar: svarhovuda kjem, kroppsbyta kjem, og applikasjonen kan bruke eller vise resultatet. Ein spinner åleine kan ikkje avgjere kva for ein som er forseinka.

Dei vanlege streamingtrinna kan overlappe kvarandre:

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

Ein proxy kan skrive eigna innhald til mellomlageret medan han sender det vidare. Bufring krev ikkje at ein ventar på heile fila. Squids read_ahead_gap styrer henting som går framom leveringa, noko som er ei anna form for bufring.

Mottrykk kan mellombels stoppe lesing oppstraums når ein treg klient fyller utkøane. Content-Length gjev òg lengda utan å krevje full bufring. HTTP/1.1 chunked-koding tillèt trinnvis levering, men kan ikkje love låg latens dersom ein tidlegare komponent held dataa tilbake.

Undersøk deretter handsamingstrinna. Omskriving eller inspeksjon kan krevje delar av eller heile kroppen. Komprimering og applikasjonsrammeverk kan forseinke nyttig utdata. På klientsida ventar ein metode som krev komplett byte-array før han returnerer, og ein nettlesar kan ta imot byte før han kan vise dei.

Etter ein vellukka CONNECT sender ein vanleg proxy tenestestraumen vidare utan å trenge den endelege lengda til den tunellerte fila. Følg den første manglande hendinga ovanfor før du endrar buffer- eller tidsavbrotinnstillingane. Når curl er observatøren, endrar no-buffer-valet det lokale uttrinnet.