Srautas per forward proxy prieš viso atsakymo buferiavimą

Kai atrodo, kad atsisiuntimas laukia, atskirkite tris įvykius: atsakymo antraščių atėjimą, kūno baitų atėjimą ir galimybę programai panaudoti ar parodyti rezultatą. Vienas įkėlimo indikatorius negali nustatyti, kuris iš jų vėluoja.

Įprasti srauto etapai gali persidengti:

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

Proxy gali įrašyti tinkamą turinį į podėlį, perduodamas jį toliau. Podėlio naudojimas nereikalauja laukti viso failo. Squid read_ahead_gap valdo gavimą, kuris vyksta prieš pristatymą, ir tai yra kita buferiavimo rūšis.

Priešslėgis gali laikinai sustabdyti aukštupio skaitymą, kai lėtas klientas užpildo išvesties eiles. Content-Length taip pat pateikia ilgį be viso buferiavimo. HTTP/1.1 chunked koduotė leidžia laipsnišką pristatymą, bet negali pažadėti mažos delsos, jei ankstesnis komponentas sulaiko duomenis.

Tada peržiūrėkite apdorojimo etapus. Perrašymui ar patikrinimui gali prireikti dalies ar viso kūno. Suspaudimas ir programos rėminimas gali atidėti naudingą išvestį. Kliente viso baitų masyvo laukiantis metodas grąžina vėliau, o naršyklė gali gauti baitus anksčiau, nei gali juos parodyti.

Po sėkmingo CONNECT paprastas proxy perduoda paslaugos srautą, nereikalaudamas galutinio tuneliuojamo failo ilgio. Prieš keisdami buferio ar laiko limito nuostatas, sekite pirmą aukščiau trūkstamą įvykį. Kai curl yra stebėtojas, jo parinktis no-buffer keičia vietinį išvesties etapą.