Binabago ng pag-ikot ng mirror ang maaaring muling gamitin ng Squid
Ipaliwanag kung bakit ang magkatulad na RPM package na na-download mula sa magkaibang mirror URL ay maaaring sumakop ng magkahiwalay na Squid cache entry.
Dalawang kliyente ang nag-download ng parehong RPM sa pamamagitan ng Squid, ngunit ang ikalawang paglipat ay nakakarating pa rin sa isang mirror. Ihambing ang kumpletong URL ng mga kahilingan:
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpmNagtutugma ang mga pangalan ng file ng package; magkaiba ang kanilang target na URI. Kasama sa mga key ng HTTP cache ang hindi bababa sa paraan ng kahilingan at ang target na URI, kaya hindi awtomatikong pinagsasama ng magkatugmang checksum ng package ang mga entry na ito.
Maaaring gumamit ang Yum at DNF ng nakapirming baseurl o tumuklas ng mga mirror sa pamamagitan ng mirrorlist at metalink. Kaya maaaring pumili ng magkaibang URL ng download ang magkatulad na instalasyon.
Ang paggamit ng isang aprubadong mirror ay nagbibigay sa mga nakikitang kahilingan ng pare-parehong pagkakakilanlan sa cache. Panatilihing pantay ang mga landas ng repository, arkitektura at suite. Binabago rin ng pag-pin ang pagiging magagamit at pag-uugali ng pagpili ng mirror, kaya gawin itong desisyon sa patakaran ng repository.
Suriin kung may object caching
Sa loob ng ordinaryong HTTPS CONNECT tunnel, hindi nakikita ng Squid ang katawan ng tugon ng RPM para sa HTTP caching. Hindi iyon babaguhin ng karaniwang mirror hostname. Panatilihing naka-encrypt ang mga HTTPS repository.
Para sa mga tugon na maaaring i-cache ng Squid, nakasalalay pa rin ang muling paggamit sa pagiging sariwa, mga direktiba ng kahilingan at tugon at lokal na patakaran sa cache. Itala ang piniling URL, kung ang transaksyon ay nakikitang HTTP o naka-encrypt na tunnel, at ang resulta ng cache nito para ipaliwanag ang isang pagpalya.