Streamování přes forward proxy versus bufferování celé odpovědi

Když se stahování zdá čekat, oddělte tři události: příchod hlaviček odpovědi, příchod bajtů těla a možnost aplikace výsledek použít nebo vykreslit. Samotný indikátor načítání nedokáže určit, která z nich se zdržela.

Běžné fáze streamování se mohou překrývat:

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

Proxy může zapisovat vhodný obsah do mezipaměti, zatímco jej předává dál. Ukládání do mezipaměti nevyžaduje čekání na celý soubor. read_ahead_gap v Squidu řídí načítání, které běží před doručením — to je jiný druh bufferování.

Zpětný tlak může dočasně zastavit čtení proti proudu, když pomalý klient zaplní výstupní fronty. Content-Length také udává délku, aniž by vyžadoval plné bufferování. Kódování HTTP/1.1 chunked umožňuje postupné doručování, ale nemůže slíbit nízkou latenci, pokud data drží dřívější komponenta.

Dále prozkoumejte fáze zpracování. Přepisování nebo kontrola mohou potřebovat část nebo celé tělo. Komprese a rámování aplikace mohou zpozdit užitečný výstup. Na straně klienta metoda čekající na celé pole bajtů vrací až později a prohlížeč může přijmout bajty dřív, než je dokáže vykreslit.

Po úspěšném CONNECT běžná proxy předává tok služby, aniž by potřebovala konečnou délku tunelovaného souboru. Než změníte nastavení bufferu nebo časového limitu, sledujte první chybějící událost výše. Když je pozorovatelem curl, jeho volba no-buffer mění místní fázi výstupu.