Струменне праз прамы проксі супраць поўнага буферавання адказу

Калі здаецца, што загрузка чакае, аддзяліце тры падзеі: прыход загалоўкаў адказу, прыход байтаў цела і магчымасць праграмы выкарыстаць або адлюстраваць вынік. Адзін індыкатар не можа вызначыць, што менавіта затрымалася.

Звычайныя этапы струмення могуць перакрывацца:

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

Проксі можа запісваць прыдатны змест у кэш падчас перадачы. Кэшаванне не патрабуе чакання ўсяго файла. read_ahead_gap у Squid кіруе выбаркай, якая ідзе наперадзе выдачы, — гэта іншы від буферавання.

Зваротны ціск можа часова спыніць чытанне зверху, калі павольны кліент запаўняе чаргі вываду. Content-Length таксама дае даўжыню без поўнага буферавання. Кодаванне HTTP/1.1 chunked дазваляе паступовую выдачу, але не гарантуе нізкую затрымку, калі папярэдні кампанент трымае даныя.

Далей агледзьце этапы апрацоўкі. Перазапіс або праверка могуць патрабаваць частку ці ўсё цела. Сцісканне і фармаванне праграмы могуць затрымаць карысны вывад. На баку кліента метад, што чакае поўны масіў байтаў, вяртаецца пазней, а браўзер можа атрымаць байты раней, чым зможа іх адлюстраваць.

Пасля паспяховага CONNECT звычайны проксі перадае паток сэрвісу, не патрабуючы канчатковай даўжыні тунеляванага файла. Прасачыце першую адсутную падзею вышэй, перш чым змяняць налады буфера або тайм-аўту. Калі назіральнікам з'яўляецца curl, яго опцыя no-buffer змяняе лакальны этап вываду.