Стримовање кроз forward proxy наспрам пуног баферовања одговора

Када се чини да преузимање чека, раздвојите три догађаја: долазак заглавља одговора, долазак бајтова тела и могућност да апликација искористи или прикаже резултат. Сам показивач учитавања не може утврдити који од њих касни.

Нормалне фазе стримовања могу се преклапати:

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

Прокси може уписати подобан садржај у кеш док га прослеђује. Кеширање не захтева чекање целе датотеке. read_ahead_gap у Squidu управља добављањем које иде испред испоруке, што је друга врста баферовања.

Повратни притисак може привремено зауставити читање узводно када спор клијент напуни излазне редове. Content-Length такође даје дужину без пуног баферовања. HTTP/1.1 chunked кодирање допушта постепену испоруку, али не може обећати ниску латенцију ако претходна компонента држи податке.

Затим прегледајте фазе обраде. Преписивање или инспекција могу захтевати део или цело тело. Компресија и оквири апликације могу одложити користан излаз. На страни клијента метода која чека цео низ бајтова враћа се касније, а прегледач може примити бајтове пре него што их може приказати.

Након успешног CONNECT-а обични прокси прослеђује ток услуге без потребе за коначном дужином тунелиране датотеке. Пратите први недостајући догађај горе пре промене подешавања бафера или временског ограничења. Када је curl посматрач, његова no-buffer опција мења локалну фазу излаза.