Voortstuur-proksie stroming teenoor volledige antwoordbuffering

Wanneer 'n aflaai lyk of dit wag, skei drie gebeure: die antwoordopskrifte kom aan, die liggaamsgrepe kom aan, en die toepassing kan die resultaat gebruik of vertoon. 'n Wyser alleen kan nie vasstel watter een vertraag word nie.

Die normale stromingstadia kan oorvleuel:

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

'n Proksie kan geskikte inhoud na die kas skryf terwyl dit dit deurstuur. Kasstoor vereis nie dat daar op die hele lêer gewag word nie. Squid se read_ahead_gap beheer die ophaal wat voor die aflewering loop, wat 'n ander soort buffering is.

Teendruk kan opwaartse lees tydelik stop wanneer 'n stadige kliënt die uitvoerrye vol maak. Content-Length gee ook die lengte sonder om volledige buffering te vereis. HTTP/1.1 se stuk-gebaseerde kodering laat inkrementele aflewering toe, maar kan nie lae latensie belowe as 'n vroeëre komponent die data vashou nie.

Ondersoek vervolgens die verwerkingstadia. Herskrywing of inspeksie kan 'n deel of die hele liggaam nodig hê. Kompressie en toepassingsraamwerk kan nuttige uitset vertraag. Aan die kliëntkant wag 'n metode wat die volledige greepversameling verwag voordat dit terugkeer, en 'n blaaier kan grepe ontvang voordat dit dit kan vertoon.

Ná 'n suksesvolle CONNECT stuur 'n gewone proksie die diensstroom deur sonder om die finale lengte van die tonnelde lêer te ken. Volg die eerste ontbrekende gebeurtenis hierbo voordat u sy buffer- of tydverstekinstellings verander. Wanneer curl die waarnemer is, verander sy no-buffer-opsie die plaaslike uitsetstadium.