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

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

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

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

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

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

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

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