Streaming tramite proxy diretto contro buffering dell'intera risposta

Quando un download sembra attendere, separate tre eventi: l'arrivo delle intestazioni di risposta, l'arrivo dei byte del corpo e la capacità dell'applicazione di usare o visualizzare il risultato. Un solo indicatore di caricamento non identifica quale di essi è in ritardo.

Le normali fasi di streaming possono sovrapporsi:

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

Un proxy può scrivere contenuti idonei nella cache mentre li inoltra. La memorizzazione nella cache non richiede di attendere l'intero file. Il read_ahead_gap di Squid controlla il recupero che procede in anticipo rispetto alla consegna, che è un altro tipo di buffering.

La contropressione può sospendere temporaneamente le letture a monte quando un client lento riempie le code di uscita. Content-Length fornisce anche la lunghezza senza richiedere un buffering completo. La codifica HTTP/1.1 chunked consente la consegna incrementale, ma non può garantire una bassa latenza se un componente precedente trattiene i dati.

Esaminate poi le fasi di elaborazione. La riscrittura o l'ispezione possono richiedere parte o tutto il corpo. La compressione e l'inquadratura dell'applicazione possono ritardare l'uscita utile. Sul client, un metodo che attende l'array di byte completo ritorna più tardi, e un browser può ricevere byte prima di poterli visualizzare.

Dopo un CONNECT riuscito, un proxy ordinario inoltra il flusso del servizio senza bisogno della lunghezza finale del file incapsulato. Seguite il primo evento mancante sopra prima di modificare le impostazioni di buffer o di timeout. Quando curl è l'osservatore, la sua opzione no-buffer modifica la fase di uscita locale.