미러 순환은 Squid가 재사용할 수 있는 것을 바꾼다
서로 다른 미러 URL에서 내려받은 동일한 RPM 패키지가 별도의 Squid 캐시 항목을 차지할 수 있는 이유를 설명합니다.
두 클라이언트가 Squid를 통해 같은 RPM을 내려받지만 두 번째 전송은 여전히 미러에 도달합니다. 전체 요청 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을 선택할 수 있습니다.
승인된 미러 하나를 사용하면 보이는 요청에 일관된 캐시 ID가 부여됩니다. 저장소 경로, 아키텍처, 스위트를 맞춰 두세요. 고정은 가용성과 미러 선택 동작도 바꾸므로 저장소 정책 결정으로 다루세요.
객체 캐싱을 사용할 수 있는지 확인
일반적인 HTTPS CONNECT 터널 안에서는 Squid가 HTTP 캐싱을 위해 RPM 응답 본문을 볼 수 없습니다. 공통 미러 호스트 이름으로도 그것은 바뀌지 않습니다. HTTPS 저장소는 암호화된 상태로 유지하세요.
Squid가 캐시할 수 있는 응답이라도 재사용은 신선도, 요청 및 응답 지시문, 로컬 캐시 정책에 달려 있습니다. 미스를 설명하려면 선택된 URL, 트랜잭션이 가시적 HTTP였는지 암호화된 터널이었는지, 그리고 그 캐시 결과를 기록하세요.