Форвард прокси аркылуу агым жана толук жоопту буферлөө

Жүктөө күтүп жаткандай көрүнгөндө үч окуяны бөлүңүз: жооп аталыштарынын келиши, дененин байттарынын келиши жана колдонмонун натыйжаны колдонуу же көрсөтүү мүмкүнчүлүгү. Жалгыз жүктөө көрсөткүчү кайсынысы кечигип жатканын аныктай албайт.

Агымдын кадимки этаптары кабатташы мүмкүн:

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

Прокси өткөрүп жатып ылайыктуу мазмунду кэшке жаза алат. Кэштөө бүт файлды күтүүнү талап кылбайт. Squidдин read_ahead_gap жеткирүүдөн мурун жүргөн алууну башкарат, бул буферлөөнүн башка түрү.

Жай кардар чыгуу кезектерин толтурганда каршы басым жогорку агымдагы окууну убактылуу токтото алат. Content-Length да толук буферсиз узундукту берет. HTTP/1.1 chunked коддоо акырындык менен жеткирүүгө жол берет, бирок мурунку компонент маалыматты кармап турса, төмөн кечигүүгө кепилдик бере албайт.

Андан кийин иштетүү этаптарын карап чыгыңыз. Кайра жазуу же текшерүү дененин бир бөлүгүн же баарын талап кылышы мүмкүн. Кысуу жана колдонмо алкагы пайдалуу чыгууну кечиктириши мүмкүн. Кардар тарапта толук байт массивин күткөн ыкма кечирээк кайтат, ал эми браузер байттарды көрсөтө алганга чейин кабыл алышы мүмкүн.

Ийгиликтүү CONNECT кийин кадимки прокси туннелденген файлдын акыркы узундугун билбей эле кызмат агымын өткөрөт. Буфер же таймаут жөндөөлөрүн өзгөртүүдөн мурун жогорудагы биринчи жок окуяны ээрчиңиз. curl байкоочу болгондо, анын no-buffer параметри жергиликтүү чыгуу этабын өзгөртөт.