Ротация зеркал меняет то, что 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 или зашифрованным туннелем, и результат кэша, чтобы объяснить промах.