Streaming por proxy direto versus buffering da resposta completa

Quando um download parece esperar, separe três eventos: a chegada dos cabeçalhos de resposta, a chegada dos bytes do corpo e a capacidade de a aplicação usar ou apresentar o resultado. Um indicador giratório sozinho não identifica qual deles está atrasado.

As etapas normais de streaming podem sobrepor-se:

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

Um proxy pode gravar conteúdo elegível na cache enquanto o retransmite. O armazenamento em cache não exige esperar pelo ficheiro completo. O read_ahead_gap do Squid controla a obtenção que avança à frente da entrega, que é outro tipo de buffering.

A contrapressão pode suspender temporariamente as leituras a montante quando um cliente lento enche as filas de saída. O Content-Length também fornece o comprimento sem exigir buffering completo. A codificação HTTP/1.1 chunked permite entrega incremental, mas não pode prometer baixa latência se um componente anterior retiver os dados.

De seguida, inspecione as etapas de processamento. A reescrita ou a inspeção podem precisar de parte ou da totalidade do corpo. A compressão e o enquadramento da aplicação podem atrasar a saída útil. No cliente, um método que espera pela matriz de bytes completa demora mais a devolver, e um navegador pode receber bytes antes de os poder apresentar.

Após um CONNECT bem-sucedido, um proxy comum retransmite o fluxo do serviço sem precisar do comprimento final do ficheiro tunelizado. Siga o primeiro evento em falta acima antes de alterar as definições de buffer ou de tempo limite. Quando o curl é o observador, a sua opção no-buffer altera a etapa de saída local.