프록시 서버 캐싱 개요

캐시는 프록시 서버가 클라이언트가 요청하는 파일의 로컬 사본을 저장하여, 동일한 클라이언트나 기타 클라이언트로부터 파일을 다시 요청받을 때 캐시에서 직접 제공할 수 있는 기능입니다.

캐싱 프록시는 HTTP 1.1 을 준수하며, 일반적으로 문서의 캐싱 및 최신성 판단을 위해 HTTP 1.1 프로토콜을 따릅니다.

이 섹션에는 프록시 서버 캐시의 일부 기능에 대한 정보가 포함되어 있습니다. 구성할 수 있는 기능의 경우, 적절한 값을 설정하는 방법에 대한 세부사항은 다음 장에 포함되어 있습니다.

캐시 저장영역

프록시 서버는 캐시를 물리적 저장 장치나 시스템 메모리에 저장할 수 있습니다. 시스템에 더 적합한 캐시 스토리지의 유형은 하드웨어의 기능 및 캐시에 저장되는 항목의 수가 많은 것이 중요한지 또는 빠른 캐시 응답이 중요한지에 따라 달라집니다. 메모리 캐시의 응답 시간은 일반적으로 디스크 캐시보다 빠르지만, 메모리 캐시의 크기는 프록시 서버 머신의 RAM 용량에 의해 제한됩니다. 디스크 캐시의 크기는 저장영역 장치의 크기로 제한되며 일반적으로 RAM 용량보다는 훨씬 큽니다.

디스크 캐시의 경우, 캐싱 프록시는 원시 디스크 캐싱을 사용합니다. 이는 프록시 서버가 운영 체제의 읽기 및 쓰기 프로토콜을 사용하지 않고 캐시 장치에 직접 기록함을 의미합니다. 디스크 캐시용 저장영역 장치는 htcformat 명령을 사용하여 준비되어 있어야 합니다.

캐시 색인

메모리 캐시나 디스크 캐시 모두에서 캐싱 프록시는 시스템 메모리 공간을 사용하여 캐시의 인덱스를 보관합니다. 이는 캐시된 파일을 찾는 데 걸리는 처리 시간을 줄여줍니다.

캐싱 프록시의 캐시 디렉터리 구조와 조회 방식은 다른 프록시 서버와 다릅니다. 캐싱 프록시는 캐시 내 파일 정보가 담긴 인덱스를 메모리에 유지합니다. 조회할 때 디스크나 다른 매체 대신 RAM을 사용하면 보다 빨리 파일을 조회하고 검색할 수 있습니다.

색인에는 URL, 캐시 위치 및 캐시된 오브젝트에 대한 만기 정보가 들어 있습니다. 이러한 이유로, 색인을 보유하는 데 필요한 메모리 용량은 캐시의 오브젝트 수에 비례합니다.

클라이언트에서 요청이 수신될 때, 프록시가 해당 URL에 대한 메모리에서 캐시 색인을 확인합니다.

파일이 색인에 없는 경우, 버대상 서버로 요청합니다.
- 그런 다음 검색된 파일이 캐시될 수 있는지 여부를 판별하기 위해 URL을 확인합니다. 허용될 경우, 프록시 서버는 검색된 파일을 캐시합니다.
- 그러면 캐시 색인이 URL, 위치 및 새로 캐시된 오브젝트에 대한 만기 정보로 업데이트됩니다.
파일이 색인에 있는 경우,
- 만기 정보를 확인하여 캐시된 파일이 새로운 파일인지 판별합니다.
  - 오브젝트가 만기된 경우, 대상 서버가 접속되며 만기 오브젝트는 새로 검색된 문서로 바뀝니다. 만기 정보가 캐시 색인에서 업데이트됩니다.
  - 오브젝트가 만기되지 않았으면, 프록시 캐시에서 문서가 제공됩니다.

FTP 캐시

프록시가 요청을 캐시하도록 구성되면, FTP 파일 요청과 HTTP 파일 요청을 캐시할 수 있습니다. 그러나 FTP 파일에는 HTTP 파일과 동일한 유형의 헤더 정보가 들어있지 않기 때문에, 캐시된 FTP 파일의 만기 날짜는 기타 캐시된 파일과 다르게 계산됩니다.

파일을 검색하기 위해서 FTP 서버에 요청이 이루어지면, 프록시는 우선 파일에 대한 FTP 디렉토리 정보를 얻기 위해서 FTP 서버에 파일의 LIST 요청을 전송합니다. FTP 서버가 LIST 요청에 대해 긍정적인 완료 응답과 파일의 디렉터리 정보를 반환하면, 프록시는 FTP 디렉터리 정보에서 파싱된 날짜로 HTTP Last-Modified 헤더를 생성합니다. 그러면 프록시의 캐싱 기능에서는 구성 파일의 CacheLastModifiedFactor 지시문에 설정된 값과 함께 이 마지막 수정 헤더를 사용하여 FTP 파일이 만료되기 전까지 캐시에 남아 있는 기간을 판별합니다.

anonymous 로그인이 아니라 고유한 사용자 ID로 검색된 FTP 파일은 개인용 파일로 간주되며 캐시되지 않습니다.

DNS 캐시

웹 콘텐츠 캐싱 외에도 프록시 서버는 도메인 이름 서버(DNS) 캐싱을 수행합니다. 예를 들어, 클라이언트가 www.myWebsite.com에서 URL을 요청하면, 프록시는 DNS 서버에 www.myWebsite.com 호스트 이름을 IP 주소로 해석하도록 요청합니다. 그러면 IP 주소가 캐시되어 이 호스트 이름에 대한 후속 요청의 응답 시간을 줄여줍니다. DNS 캐시는 자동으로 실행되며 재구성할 수 없습니다.

캐시 제외

일부 파일과 문서는 캐시되지 않습니다. 캐시되지 않는 파일은 다음과 같습니다.

GET 외의 HTTP를 사용하여 요청에서 리턴되는 파일(예: POST 및 PUT).
문서와 같은 캐싱이 원래 서버에 의해 허용되지 않으면 인증을 요구하는 모든 문서.
CGI 스크립트의 동적 출력(이는 요청될 때마다 고유하기 때문임) IBM® WebSphere® Application Server 에서 실행되는 서블릿 및 JavaServer Pages(JSP)에서 동적으로 생성된 결과는 동적 캐싱이 활성화된 경우 캐시될 수 있습니다. 자세한 내용은 동적으로 생성된 콘텐츠 캐싱을 참조하십시오.
SSL 터널링 연결에 전달되는 정보(프록시는 프록시를 통과하는 데이터를 복호화할 수 없으므로).
URL 에서 반환되는 파일 중 물음표(?)가 포함된 파일은 쿼리 캐싱이 허용되지 않는 한 모두 해당됩니다. (쿼리 결과 캐싱 구성에 대한 정보는 캐시되는 항목 제어 항목을 참조하십시오.)

캐싱 필터를 설정하여 캐시되는 항목을 추가로 제한할 수 있습니다. 예를 들어, 프록시 서버가 프록시에서 로컬로 제공되는 파일을 캐시하지 않도록 설정할 수 있습니다.

캐시 관리

캐시 관리에는 많은 요소가 연관되어 있습니다. 서버 관리자로서 다음 사항을 지정할 수 있습니다.

어떤 문서가 캐시되는가(자세한 내용은 캐시되는 항목 제어 참조).
캐싱할 수 있는 문서 수는 몇 개인가요? (자세한 내용은 기본 캐싱 구성 참조).
캐시된 문서가 최신으로 간주되는 기간(자세한 내용은 캐시 콘텐츠 유지 관리 참조).
캐시가 얼마나 자주 정리되는지(가비지 컬렉션) 및 어떤 유형의 파일이 주로 유지되는지(자세한 내용은 캐시 내용 유지 관리 참조).
캐시된 문서가 색인되는 방식 (자세한 내용은 기본 캐싱 구성 참조).
캐시가 새로 고쳐질 때 (자세한 내용은 캐시 에이전트의 자동 새로 고침 및 사전 로드 구성을 참조하십시오).
원격 캐시 액세스(자세한 내용은 공유 캐시 사용을 참조하십시오).
로그가 어떻게 보관 및 아카이빙되는지 (자세한 내용은 기본 캐싱 구성 참조).

또한 캐싱 프록시의 전반적인 성능을 향상시키기 위해 캐시 구성에 대한 조정이 가능합니다.