Ротація дзеркал змінює те, що Squid може використати повторно
Поясніть, чому однакові RPM-пакети, завантажені з різних адрес дзеркал, можуть займати окремі записи кешу Squid.
Два клієнти завантажують той самий RPM через Squid, але друге передавання все одно потрапляє на дзеркало. Порівняйте повні URL запитів:
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. Тому однакові встановлення можуть вибирати різні URL завантаження.
Використання одного схваленого дзеркала дає видимим запитам узгоджену ідентичність у кеші. Тримайте шляхи репозиторію, архітектуру та набір узгодженими. Закріплення також змінює доступність і поведінку вибору дзеркал, тому зробіть це рішенням політики репозиторію.
Перевірте, чи доступне кешування об'єктів
Усередині звичайного тунелю HTTPS CONNECT Squid не бачить тіла відповіді RPM для HTTP-кешування. Спільна назва хоста дзеркала цього не змінить. Тримайте репозиторії HTTPS зашифрованими.
Для відповідей, які Squid може кешувати, повторне використання все ще залежить від свіжості, директив запиту та відповіді й локальної політики кешу. Записуйте вибраний URL, чи обмін був видимим HTTP або зашифрованим тунелем, і результат кешу, щоб пояснити промах.