Streaming mediante proxy directo fronte ao almacenamento da resposta completa

Cando unha descarga parece esperar, separe tres acontecementos: chegan as cabeceiras de resposta, chegan os bytes do corpo e a aplicación pode usar ou representar o resultado. Un indicador xiratorio por si só non identifica cal deles se atrasa.

As etapas normais de streaming poden solaparse:

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

Un proxy pode escribir contido apto na caché mentres o retransmite. O almacenamento en caché non require esperar o ficheiro completo. O read_ahead_gap de Squid controla a recuperación que vai por diante da entrega, que é outro tipo de almacenamento.

A contrapresión pode deter temporalmente as lecturas ascendentes cando un cliente lento enche as colas de saída. Content-Length tamén fornece a lonxitude sen requirir un almacenamento completo. A codificación HTTP/1.1 chunked permite a entrega incremental, pero non pode prometer baixa latencia se un compoñente anterior retén os datos.

A continuación, inspeccione as etapas de procesamento. A reescritura ou a inspección poden necesitar parte ou todo o corpo. A compresión e o encadrado da aplicación poden atrasar a saída útil. No cliente, un método que espera a matriz de bytes completa tarda máis en devolver, e un navegador pode recibir bytes antes de poder representalos.

Tras un CONNECT correcto, un proxy normal retransmite o fluxo do servizo sen necesitar a lonxitude final do ficheiro tunelizado. Siga o primeiro acontecemento ausente anterior antes de cambiar a configuración de búfer ou de tempo de espera. Cando curl é o observador, a súa opción no-buffer cambia a etapa de saída local.