Эмне үчүн CONNECT трафиги Squid объекттеринин кэшин толтурбайт?
Кадимки HTTPS туннели түз проксиге кайра колдонулуучу HTTP жооп объекттерин бербестен эмне үчүн көп байт өткөрө алат.
Кадимки CONNECT туннели Squid-ке кэштеле турган веб-сайттын жообун эмес, шифрленген байттарды берет. Ошондуктан чоң HTTPS жүктөөсү объекттердин кэшине кайра колдонулуучу бир да жазуу кошпостон көп трафик жаратышы мүмкүн.
Squid туннелдин көздөгөн жерин, узактыгын жана байт санын каттай алат. Ал ички URL жолун, кэш көрсөтмөлөрүн, көрсөтүлүштү жана валидаторлорду сактап, кайра колдоно турган кадимки HTTP билдирүүлөрү катары албайт. Дисктеги көбүрөөк орун же объект өлчөмүнүн жогорураак чеги аларды ачып көрсөтпөйт.
Кэш бузук деп айтуудан мурда суроо ыкмаларын жана туннель жазууларын текшериңиз. CONNECT басымдуулук кылган жүктөмдө чоң көлөмдөгү өткөрүүлөр менен объекттердин аз кайра колдонулушу шайкеш келет. Кэшти чындап текшерүү үчүн өзүңүз көзөмөлдөгөн, кэш баштары ачык көрсөтүлгөн жана мазмуну белгилүү HTTP ресурсун колдонуңуз; туннелди, браузердин кэшин же көздөгөн жердин CDN тармагын эмес, Squid-тин объекттерди иштетүү жолун сынап жатканыңызды ырастагыла.
Проксиге чейинки TLS — өзүнчө катмар. Өзүнүн угуучусунда TLS туташуусун аяктагандан кийин Squid HTTP көздөгөн жерине кадимки суроону иштете алат. Эгер ошол туташуу анын ордуна HTTPS үчүн CONNECT сураса, көздөгөн жердин ички TLS туташуусу өзүнчө жана тунук эмес бойдон калат.
HTTPSти ортодон кармап чечмелөө сертификаттарга ишеним, уруксат берүү жана купуялык талаптарын өзгөртөт. Бул кэш мейкиндигин кадимки жөндөө эмес жана кадимки түз проксиге иштөө үчүн мындай кармоонун кереги жок.