Поточно предаване през преден прокси срещу буфериране на целия отговор

Когато изтеглянето изглежда чака, разделете три събития: пристигането на заглавките на отговора, пристигането на байтовете на тялото и възможността приложението да използва или покаже резултата. Само индикатор за зареждане не може да покаже кое от тях се бави.

Нормалните етапи на поточно предаване могат да се припокриват:

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

Проксито може да записва подходящо съдържание в кеша, докато го препраща. Кеширането не изисква изчакване на целия файл. read_ahead_gap на Squid управлява извличането, което върви преди доставянето — друг вид буфериране.

Обратното налягане може временно да спре четенето отгоре, когато бавен клиент запълни изходните опашки. Content-Length също дава дължината, без да изисква пълно буфериране. Кодирането HTTP/1.1 chunked позволява поетапно доставяне, но не гарантира ниска латентност, ако по-ранен компонент задържа данните.

След това прегледайте етапите на обработка. Пренаписването или проверката може да изискват част или цялото тяло. Компресията и рамкирането на приложението могат да забавят полезния изход. От страна на клиента метод, който чака цял байтов масив, се връща по-късно, а браузърът може да получи байтове, преди да може да ги покаже.

След успешен CONNECT обикновеното прокси препредава потока на услугата, без да му е нужна крайната дължина на тунелирания файл. Проследете първото липсващо събитие по-горе, преди да променяте настройките на буфера или изчакването. Когато curl е наблюдателят, опцията му no-buffer променя локалния етап на изхода.