Peilien vaihto muuttaa sitä, mitä Squid voi käyttää uudelleen
Selitä, miksi samanlaiset RPM-paketit eri peili-URL-osoitteista ladattuina voivat viedä erillisiä Squidin välimuistimerkintöjä.
Kaksi asiakasta lataa saman RPM:n Squidin kautta, mutta toinen siirto saavuttaa silti peilin. Vertaa täydellisiä pyyntöjen URL-osoitteita:
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpmPaketin tiedostonimet täsmäävät; niiden kohde-URI:t eroavat. HTTP-välimuistin avaimet sisältävät ainakin pyyntömenetelmän ja kohde-URI:n, joten täsmäävät paketin tarkistussummat eivät automaattisesti yhdistä näitä merkintöjä.
Yum ja DNF voivat käyttää kiinteää baseurl-asetusta tai löytää peilejä mirrorlist- ja metalink-mekanismien kautta. Siksi samanlaiset asennukset voivat valita eri lataus-URL-osoitteita.
Yhden hyväksytyn peilin käyttö antaa näkyville pyynnöille johdonmukaisen välimuisti-identiteetin. Pidä repositorion polut, arkkitehtuuri ja suite linjassa. Kiinnittäminen muuttaa myös saatavuutta ja peilin valintakäyttäytymistä, joten tee siitä repositorion käytäntöpäätös.
Tarkista, onko objektien välimuistitus käytettävissä
Tavallisen HTTPS CONNECT -tunnelin sisällä Squid ei näe RPM-vastauksen runkoa HTTP-välimuistitusta varten. Yhteinen peilin isäntänimi ei muuta sitä. Pidä HTTPS-repositoriot salattuina.
Vastauksille, jotka Squid voi tallentaa välimuistiin, uudelleenkäyttö riippuu edelleen tuoreudesta, pyynnön ja vastauksen direktiiveistä sekä paikallisesta välimuistikäytännöstä. Kirjaa valittu URL-osoite, oliko tapahtuma näkyvää HTTP:tä vai salattu tunneli, ja sen välimuistitulos, jotta voit selittää ohilyönnin.