Streaming via forward-proxy kontra full responsbuffering

Når en nedlasting ser ut til å vente, skill tre hendelser: svarheadere ankommer, kroppsbytes ankommer, og applikasjonen kan bruke eller vise resultatet. En spinner alene kan ikke avgjøre hvilken som er forsinket.

De normale streamtrinnene kan overlappe:

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

En proxy kan skrive egnet innhold til hurtigbufferen mens den videresender det. Bufring krever ikke at man venter på hele filen. Squids read_ahead_gap styrer hentingen som løper foran leveringen, noe som er en annen form for bufring.

Mottrykk kan midlertidig stoppe lesing oppstrøms når en treg klient fyller utkøene. Content-Length gir også lengden uten å kreve full bufring. HTTP/1.1 chunked-koding tillater trinnvis levering, men kan ikke love lav latens hvis en tidligere komponent holder dataene tilbake.

Undersøk deretter behandlingstrinnene. Omskriving eller inspeksjon kan kreve deler av eller hele kroppen. Komprimering og applikasjonsrammeverk kan forsinke nyttig utdata. På klientsiden venter en metode som krever komplett byte-array før den returnerer, og en nettleser kan motta bytes før den kan vise dem.

Etter en vellykket CONNECT videresender en vanlig proxy tjenestestrømmen uten å trenge den tunellerte filens endelige lengde. Følg den første manglende hendelsen ovenfor før du endrer buffer- eller tidsavbruddsinnstillingene. Når curl er observatøren, endrer no-buffer-valget det lokale uttrinnet.