Streaming fia forward-proxy tsjin folsleine antwurdbuffering

As in download te wachtsjen liket, skied dan trije barren: antwurdkoppen komme oan, lichemsbytes komme oan, en de applikaasje kin it resultaat brûke of werjaan. In spinner allinnich kin net fêststelle hokker fan dizze fertrage is.

De normale streamingstadia kinne oerlaapje:

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

In proxy kin geskikte ynhâld yn de cache skriuwe wylst er it trochstjoert. Cachejen freget net om op it hiele bestân te wachtsjen. Squid syn read_ahead_gap regelet it opheljen dat foar de levering út rint, wat in oar soarte bufferjen is.

Tsjindruk kin tydlik it lêzen streamop stopje as in stadige klant de útfierrigen follet. Content-Length jout ek de lingte sûnder folsleine buffering te freegjen. HTTP/1.1 chunked-kodearring lit stadige levering ta, mar kin gjin lege latinsje belove as in earder ûnderdiel de gegevens tsjinhâldt.

Undersykje dêrnei de ferwurkingsstadia. Weromskriuwen of ynspeksje kin in part of it hiele lichem nedich hawwe. Kompresje en applikaasjekadering kinne nuttige útfier fertrage. Oan de klantkant wachtet in metoade dy't in folsleine byte-array ferwachtet foardat er weromkomt, en in browser kin bytes ûntfange foardat er se werjaan kin.

Nei in slagge CONNECT stjoert in gewoane proxy de tsjinststream troch sûnder de definitive lingte fan it tunnelbestân te kennen. Folgje it earste ûntbrekkende barren hjirboppe foardat jo de buffer- of time-outynstellingen feroarje. As curl de waarnimmer is, feroaret syn no-buffer-opsje it lokale útfierstadium.