Streaming über Forward-Proxy vs. Pufferung der vollständigen Antwort

Wenn ein Download zu warten scheint, trennen Sie drei Ereignisse: Antwortheader kommen an, Body-Bytes kommen an, und die Anwendung kann das Ergebnis nutzen oder darstellen. Ein Spinner allein zeigt nicht, welches davon verzögert ist.

Die normalen Streaming-Stufen können sich überlappen:

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

Ein Proxy kann geeignete Inhalte während der Weiterleitung in den Cache schreiben. Caching erfordert nicht, auf die ganze Datei zu warten. Squids read_ahead_gap steuert das Abrufen, das der Auslieferung vorausläuft — eine andere Art der Pufferung.

Gegendruck kann Upstream-Lesevorgänge vorübergehend stoppen, wenn ein langsamer Client die Ausgabewarteschlangen füllt. Content-Length liefert die Länge ebenfalls, ohne vollständige Pufferung zu verlangen. HTTP/1.1-Chunked-Kodierung erlaubt schrittweise Auslieferung, kann aber keine niedrige Latenz versprechen, wenn eine frühere Komponente die Daten zurückhält.

Prüfen Sie als Nächstes die Verarbeitungsstufen. Umschreiben oder Inspektion können einen Teil oder den gesamten Body benötigen. Kompression und Anwendungs-Framing können nützliche Ausgabe verzögern. Auf Clientseite wartet eine Methode, die ein vollständiges Byte-Array erwartet, vor der Rückgabe, und ein Browser kann Bytes empfangen, bevor er sie darstellen kann.

Nach einem erfolgreichen CONNECT leitet ein gewöhnlicher Proxy den Dienststrom weiter, ohne die endgültige Länge der getunnelten Datei zu benötigen. Verfolgen Sie das erste fehlende Ereignis oben, bevor Sie Puffer- oder Timeout-Einstellungen ändern. Wenn curl der Beobachter ist, ändert seine no-buffer-Option die lokale Ausgabestufe.