Spiegelrotation ändert, was Squid wiederverwenden kann
Erklären Sie, warum identische RPM-Pakete, die von unterschiedlichen Spiegelserver-URLs geladen werden, getrennte Squid-Cache-Einträge belegen können.
Zwei Clients laden dasselbe RPM über Squid, aber die zweite Übertragung erreicht trotzdem einen Spiegelserver. Vergleichen Sie die vollständigen Anforderungs-URLs:
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpmDie Dateinamen des Pakets stimmen überein; ihre Ziel-URIs unterscheiden sich. HTTP-Cache-Schlüssel enthalten mindestens die Anforderungsmethode und die Ziel-URI, daher führen übereinstimmende Paketprüfsummen diese Einträge nicht automatisch zusammen.
Yum und DNF können eine feste baseurl verwenden oder Spiegelserver über mirrorlist und metalink ermitteln. Identische Installationen können daher unterschiedliche Download-URLs wählen.
Ein einziger freigegebener Spiegelserver gibt sichtbaren Anforderungen eine einheitliche Cache-Identität. Halten Sie Repository-Pfade, Architektur und Suite deckungsgleich. Das Anheften ändert zudem Verfügbarkeit und Verhalten der Spiegelauswahl, machen Sie es daher zu einer Entscheidung der Repository-Richtlinie.
Prüfen, ob Objekt-Caching verfügbar ist
Innerhalb eines gewöhnlichen HTTPS-CONNECT-Tunnels kann Squid den RPM-Antwortkörper nicht für HTTP-Caching sehen. Ein gemeinsamer Spiegelserver-Hostname ändert daran nichts. Halten Sie HTTPS-Repositories verschlüsselt.
Bei Antworten, die Squid zwischenspeichern kann, hängt die Wiederverwendung weiterhin von Aktualität, Anforderungs- und Antwortdirektiven sowie lokaler Cache-Richtlinie ab. Notieren Sie die gewählte URL, ob die Transaktion sichtbares HTTP oder ein verschlüsselter Tunnel war, und ihr Cache-Ergebnis, um einen Fehlgriff zu erklären.