Streaming via proxy direct ou mise en tampon de la réponse complète

Lorsqu'un téléchargement semble attendre, distinguez trois événements : l'arrivée des en-têtes de réponse, l'arrivée des octets du corps et la capacité de l'application à utiliser ou afficher le résultat. Un simple indicateur de chargement ne permet pas d'identifier lequel est retardé.

Les étapes normales de streaming peuvent se chevaucher :

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

Un proxy peut écrire le contenu éligible dans le cache tout en le relayant. La mise en cache n'exige pas d'attendre le fichier entier. Le read_ahead_gap de Squid contrôle la récupération qui progresse en avance sur la livraison, ce qui constitue un autre type de mise en tampon.

La contre-pression peut interrompre temporairement les lectures amont lorsqu'un client lent remplit les files de sortie. Content-Length fournit aussi la longueur sans exiger une mise en tampon complète. L'encodage HTTP/1.1 chunked permet une livraison progressive, mais ne peut pas promettre une faible latence si un composant antérieur retient les données.

Examinez ensuite les étapes de traitement. La réécriture ou l'inspection peuvent nécessiter une partie ou la totalité du corps. La compression et le cadrage applicatif peuvent retarder la sortie utile. Côté client, une méthode qui attend le tableau d'octets complet ne revient qu'ensuite, et un navigateur peut recevoir des octets avant de pouvoir les afficher.

Après un CONNECT réussi, un proxy ordinaire relaie le flux du service sans avoir besoin de la longueur finale du fichier tunnelisé. Suivez le premier événement manquant ci-dessus avant de modifier ses réglages de tampon ou de délai. Lorsque curl est l'observateur, son option no-buffer modifie l'étape de sortie locale.