Ուղղորդող պրոքսիի հոսքն ընդդեմ ամբողջական պատասխանի բուֆերացման

Երբ ներբեռնումը կարծես սպասում է, տարանջատեք երեք իրադարձություն՝ պատասխանի վերնագրերի ժամանումը, մարմնի բայթերի ժամանումը և հավելվածի կարողությունը օգտագործել կամ ցուցադրել արդյունքը։ Միայն բեռնման ցուցիչը չի կարող որոշել, թե որն է ուշանում։

Սովորական հոսքի փուլերը կարող են համընկնել՝

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

Պրոքսին կարող է համապատասխար բովանդակությունը գրել քեշում՝ այն փոխանցելիս։ Քեշավորումը չի պահանջում սպասել ամբողջ ֆայլին։ Squid-ի read_ahead_gap-ը կառավարում է առբերումը, որը ընթանում է առաքումից առաջ, ինչը բուֆերացման այլ տեսակ է։

Հետադարձ ճնշումը կարող է ժամանակավորապես կանգնեցնել վերևի ընթերցումները, երբ դանդաղ հաճախորդը լցնում է ելքի հերթերը։ Content-Length-ը նույնպես տալիս է երկարությունը՝ առանց ամբողջական բուֆերացման։ HTTP/1.1 chunked կոդավորումը թույլ է տալիս աստիճանական առաքում, բայց չի կարող խոստանալ ցածր ուշացում, եթե նախորդ բաղադրիչը պահում է տվյալները։

Հաջորդիվ ուսումնասիրեք մշակման փուլերը։ Վերագրումը կամ ստուգումը կարող են պահանջել մարմնի մի մասը կամ ամբողջը։ Սեղմումը և հավելվածի շրջանակավորումը կարող են հետաձգել օգտակար ելքը։ Հաճախորդի կողմում ամբողջ բայթային զանգվածին սպասող մեթոդը վերադառնում է ավելի ուշ, և զննարկիչը կարող է բայթեր ստանալ նախքան դրանք ցուցադրելը։

Հաջող CONNECT-ից հետո սովորական պրոքսին փոխանցում է ծառայության հոսքը՝ առանց թունելավորված ֆայլի վերջնական երկարության։ Նախքան բուֆերի կամ ժամկետի կարգավորումները փոխելը հետևեք վերևի առաջին բացակայող իրադարձությանը։ Երբ curl-ը դիտորդն է, նրա no-buffer տարբերակը փոխում է տեղական ելքի փուլը։