Երբ Squid-ը կարող է քեշավորել APT փաթեթները
Նախքան փաթեթների հարցումների Squid-հարվածներ դառնալը սպասելը ստուգեք HTTP փոխադրումը, քեշի պահոցը, օբյեկտի չափը և APT-ի cache-control կարգավորումները։
APT-ն և aptitude-ն կարող են պահոցի ֆայլերը ստանալ HTTP-ի միջոցով։ Squid-ը կարող է քեշավորել համապատասխան HTTP պատասխան. հաճախորդը պարտադիր չէ, որ վեբ զննարկիչ լինի։
Squid 6 կամ 7 տեղակայման դեպքում ստուգեք այս մուտքերը, երբ յուրաքանչյուր փաթեթի փոխանցում դեռ հասնում է սկզբնաղբյուրին.
- Ներբեռնումը օգտագործում է HTTP, կամ Squid-ը այլ կերպ հասանելիություն ունի HTTP փոխանակմանը։ Միայն HTTPS CONNECT թունելը չի բացահայտում փաթեթի պատասխանը քեշավորման համար։
- Քեշում կարգավորված է համապատասխան պահոց։ Հաջող փոխանցումը չի ապացուցում, որ սկավառակի քեշ գոյություն ունի։
- Արխիվը տեղավորվում է համապատասխան քեշի պանակի առավելագույն օբյեկտի չափի մեջ։ Փոքր մետատվյալները և մեծ .deb-ը կարող են տարբեր արդյունքներ տալ։
- Հարցումը և պատասխանը թույլ են տալիս պահպանում և կրկնակի օգտագործում իրենց cache-control քաղաքականության համաձայն։
APT-ն առաջարկում է Acquire::http::No-Cache, Max-Age և No-Store։ No-Store-ը կարող է խոչընդոտել պահանջված արխիվային ֆայլերի պահպանմանը։ No-Cache-ը պահանջում է վերաստուգում նախքան պահված պատասխանի կրկնակի օգտագործումը։ Ստուգեք արդյունավետ APT կոնֆիգուրացիան և Squid-ի քաղաքականությունը։
Համեմատեք նույն ամբողջական URL-ը և ստուգեք քեշի արդյունքը access.log-ում։ Տարբեր հայելի-հոսթեր, փոխված պահոցի ուղիներ կամ տեղայնորեն քեշավորված փաթեթ կարող են նշանակել, որ երկու տեղակայում երբեք չեն հարցնում նույն ցանցային օբյեկտը։
Պահոցի հայելին դիտավորյալ պահպանում է պահոցի բովանդակությունը՝ փոխարենը հույսը դնելով միայն պահանջարկով պայմանավորված HTTP քեշի կրկնակի օգտագործման վրա։