Streaming via forward proxy kontra fuld responsbuffering

Når en download ser ud til at vente, adskil tre hændelser: svarheadere ankommer, bodybytes ankommer, og applikationen kan bruge eller vise resultatet. En spinner alene kan ikke afgøre, hvilken der er forsinket.

De normale streamingtrin kan overlappe:

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

En proxy kan skrive egnet indhold til cachen, mens den videresender det. Cachelagring kræver ikke, at man venter på hele filen. Squids read_ahead_gap styrer hentning, der løber foran leveringen, hvilket er en anden form for buffering.

Modtryk kan midlertidigt stoppe læsning opstrøms, når en langsom klient fylder outputkøerne. Content-Length angiver også længden uden at kræve fuld buffering. HTTP/1.1 chunked-kodning tillader trinvis levering, men kan ikke love lav latens, hvis en tidligere komponent holder dataene.

Undersøg derefter behandlingstrinnene. Omskrivning eller inspektion kan kræve en del af eller hele bodyen. Komprimering og applikationsrammer kan forsinke nyttigt output. På klientsiden venter en metode, der kræver et komplet bytearray, før den returnerer, og en browser kan modtage bytes, før den kan vise dem.

Efter et vellykket CONNECT videresender en almindelig proxy tjenestestrømmen uden at kende den tunellerede fils endelige længde. Følg den første manglende hændelse ovenfor, før du ændrer buffer- eller timeoutindstillinger. Når curl er observatøren, ændrer dens no-buffer-indstilling det lokale outputtrin.