Spegelrotasjon endrar kva Squid kan bruke på nytt
Forklar kvifor identiske RPM-pakkar henta frå ulike spegel-URL-ar kan ta separate Squid-bufferoppføringar.
To klientar hentar den same RPM-en gjennom Squid, men den andre overføringa når framleis ein spegel. Samanlikn dei fullstendige førespurnads-URL-ane:
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpmFilnamna til pakken stemmer; mål-URI-ane deira er ulike. HTTP-buffernøklar inneheld minst førespurnadsmetoden og mål-URI-en, så samsvarande kontrollsummar for pakken slår ikkje automatisk saman desse oppføringane.
Yum og DNF kan bruke ein fast baseurl eller oppdage speglar via mirrorlist og metalink. Identiske installasjonar kan difor velje ulike nedlastings-URL-ar.
Bruk av éin godkjend spegel gir synlege førespurnader ein konsistent bufferidentitet. Hald lagringsbanar, arkitektur og suite på linje. Festing endrar òg tilgjenge og åtferd ved spegelval, så gjer det til ei avgjerd om lagringspolicy.
Kontroller om objektbufring er tilgjengeleg
Inne i ein vanleg HTTPS CONNECT-tunnel kan ikkje Squid sjå RPM-svarskroppen for HTTP-bufring. Eit felles spegel-vertsnamn endrar ikkje det. Hald HTTPS-lager krypterte.
For svar som Squid kan bufre, er gjenbruk framleis avhengig av ferskleik, førespurnads- og svardirektiv og lokal bufferpolicy. Registrer den valde URL-en, om transaksjonen var synleg HTTP eller ein kryptert tunnel, og bufferresultatet for å forklare eit bomtreff.