Streaming via forward-proxy kontra buffring av hela svaret

När en nedladdning verkar vänta, skilj på tre händelser: svarshuvuden anländer, kroppsbyten anländer och programmet kan använda eller visa resultatet. En snurra ensam kan inte avgöra vilken av dem som är fördröjd.

De normala streamingstegen kan överlappa:

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

En proxy kan skriva lämpligt innehåll till cachen medan den vidarebefordrar det. Cachning kräver inte att man väntar på hela filen. Squids read_ahead_gap styr hämtningen som löper före leveransen, vilket är en annan sorts buffring.

Mottryck kan tillfälligt stoppa läsning uppströms när en långsam klient fyller utdataköerna. Content-Length ger också längden utan att kräva full buffring. HTTP/1.1 chunked-kodning tillåter gradvis leverans, men kan inte lova låg latens om en tidigare komponent håller kvar data.

Undersök sedan bearbetningsstegen. Omskrivning eller inspektion kan kräva en del av eller hela kroppen. Komprimering och programramverk kan fördröja användbar utdata. På klientsidan väntar en metod som kräver en fullständig byte-array innan den returnerar, och en webbläsare kan ta emot byten innan den kan visa dem.

Efter en lyckad CONNECT vidarebefordrar en vanlig proxy tjänsteströmmen utan att behöva den tunnlade filens slutliga längd. Följ den första saknade händelsen ovan innan du ändrar buffrings- eller tidsgränsinställningarna. När curl är observatören, ändrar dess no-buffer-alternativ det lokala utsteget.