Ратацыя люстэркаў змяняе тое, што Squid можа паўторна выкарыстаць

Два кліенты спампоўваюць адзін і той жа RPM праз Squid, але другое пераданне ўсё яшчэ дасягае люстэрка. Параўнайце поўныя адрасы запытаў:

http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpm

Імёны файлаў пакета супадаюць; іх мэтавыя URI розныя. Ключы кэша HTTP уключаюць як мінімум метад запыту і мэтавы URI, таму супадаючыя кантрольныя сумы пакета не аб'ядноўваюць гэтыя запісы аўтаматычна.

Yum і DNF могуць выкарыстоўваць фіксаваны baseurl або знаходзіць люстэркі праз mirrorlist і metalink. Таму аднолькавыя ўсталёўкі могуць выбраць розныя адрасы спампоўкі.

Выкарыстанне аднаго зацверджанага люстэрка дае бачным запытам паслядоўную ідэнтычнасць кэша. Трымайце шляхі рэпазіторыя, архітэктуру і набор узгодненымі. Замацаванне таксама змяняе даступнасць і паводзіны выбару люстэрка, таму рабіце гэта рашэннем палітыкі рэпазіторыя.

Праверце, ці даступна кэшаванне аб'ектаў

Унутры звычайнага тунэля HTTPS CONNECT Squid не бачыць цела адказу RPM для кэшавання HTTP. Агульнае імя хоста люстэрка гэтага не зменіць. Трымайце рэпазіторыі HTTPS зашыфраванымі.

Для адказаў, якія Squid можа кэшаваць, паўторнае выкарыстанне ўсё яшчэ залежыць ад свежасці, дырэктыў запыту і адказу і лакальнай палітыкі кэша. Запішыце выбраны адрас, ці была транзакцыя бачным HTTP або зашыфраваным тунэлем, і яе вынік кэша, каб патлумачыць прамах.