Sun Java System Web Proxy Server 4.0.4 관리 설명서

HTTP 문서 캐시

HTTP 문서는 다른 프로토콜의 문서에서 제공하지 않는 캐시 기능을 제공합니다. 그러나 캐시를 제대로 설정 및 구성하면 Proxy Server가 HTTP, FTP 및 Gopher 문서를 효과적으로 캐시할 수 있습니다.


주 –

Proxy Server 4는 HTTPS 문서를 캐시하지 않습니다.


모든 HTTP 문서에는 Proxy Server가 프록시 캐시의 문서 및 원격 서버의 문서를 비교하고 평가하는 데 사용하는 설명 헤더 섹션이 있습니다. 프록시가 HTTP 문서에 대한 최신 검사를 수행할 때 캐시 버전이 오래된 경우 서버에 문서를 반환하라는 요청을 보냅니다. 대개 마지막 요청 이후 문서가 변경되지 않기 때문에 전송되지 않습니다. HTTP 문서가 최신 상태인지 여부를 확인하기 위한 이러한 검사 방법은 대역폭을 절약하고 대기 시간을 단축합니다.

원격 서버와의 트랜잭션을 줄이기 위해 Proxy Server를 사용하여 HTTP 문서에 대한 캐시 만료 설정을 지정할 수 있습니다. 캐시 만료 설정에서는 HTTP 문서가 서버에 요청을 보내기 전에 최신 여부 확인이 필요한지 여부를 평가하기 위해 프록시에 정보를 제공합니다. 프록시는 헤더에 있는 HTTP 문서의 마지막으로 수정된 날짜를 기준으로 평가를 수행합니다.

또한 HTTP 문서를 통해 캐시 새로 고침 설정을 사용할 수 있습니다. 이 옵션은 프록시가 만료 설정을 대체할 수 있는 최신 여부 확인을 항상 수행하거나 검사를 수행하기 전에 프록시가 특정 시간 동안 대기할지 여부를 지정합니다. 다음 표는 만료 설정 및 새로 고침 설정이 모두 지정된 경우 프록시가 수행하는 작업을 보여줍니다. 새로 고침 설정을 사용하면 대기 시간이 단축되고 대역폭이 크게 줄어 듭니다.

표 12–1 HTTP를 통해 캐시 만료 및 캐시 새로 고침 설정 사용

Refresh 설정 

Expiration 설정 

Results 

Always do an up-to-date check 

(해당 없음) 

항상 최신 여부 확인 수행 

User-specified interval 

Use document’s “expires” header 

간격이 만료된 경우 최신 여부 확인 수행 

 

Estimate with document’s Last-Modified header 

측정 및 만료 헤더의 최소값* 


주 –

* 최소값을 사용하면 자주 변경되는 문서에 대해 캐시에서 오래된 데이터를 가져오는 것을 방지합니다.


HTTP 캐시 새로 고침 간격 설정

Proxy Server에서 HTTP 문서를 캐시하도록 결정하는 경우 캐시의 문서에 대해 항상 최신 여부 확인을 수행해야 하는지 여부 또는 캐시 새로 고침 설정(최신 여부 확인 간격)을 기준으로 검사해야 하는지 여부를 결정합니다. 예를 들어, HTTP 문서의 경우 적절한 새로 고침 간격은 4-8시간입니다. 새로 고침 간격이 길어질수록 프록시가 원격 서버와 연결되는 횟수가 줄어듭니다. 새로 고침 간격 동안 프록시가 최신 여부 확인을 수행하지 않더라도 클라이언트에서 Reload 버튼을 눌러 새로 고침을 강제로 수행할 수 있습니다. 이 작업을 통해 프록시가 원격 서버로 최신 여부 확인을 강제 수행합니다.

Set Cache Specifics 페이지 또는 Set Caching Configuration 페이지에서 HTTP 문서에 대한 새로 고침 간격을 설정할 수 있습니다. Set Cache Specifics 페이지에서 전역 캐시 절차를 구성할 수 있으며 Set Caching Configuration 페이지에서 특정 URL 및 자원에 대한 캐시 절차를 제어할 수 있습니다.

HTTP 캐시 만료 정책 설정

또한 마지막으로 수정된 요소 또는 명시적 만료 정보만 사용하여 캐시된 문서가 최신 상태인지 여부를 검사하도록 서버를 설정할 수 있습니다.

명시적 만료 정보는 해당 파일이 만기가 되는 날짜와 시간을 지정하는 일부 HTTP 문서에 있는 헤더입니다. HTTP 문서에서 명시적 만료 헤더를 사용하는 경우가 많지 않기 때문에 마지막으로 수정된 헤더를 기준으로 측정해야 합니다.

마지막으로 수정된 헤더를 기준으로 HTTP 문서를 캐시하도록 결정한 경우 만료 측정에 사용할 분율을 선택해야 합니다. LM 요소라고 하는 이 분율은 마지막 수정 시간과 문서에 대해 마지막 최신 여부 확인을 수행한 시간 사이의 간격을 곱한 값입니다. 결과 수치는 마지막 최신 여부 확인 이후 시간과 비교됩니다. 이 수치가 시간 간격보다 작은 경우 문서는 만료되지 않습니다. 분율이 작을수록 프록시가 문서를 검사하는 빈도가 높아집니다.

예를 들어, 10일 전에 마지막으로 변경한 문서가 있다고 가정합니다. 마지막으로 수정된 요소를 0.1로 설정하면 프록시는 이 요소를 문서가 하루 동안(10 * 0.1 = 1) 변경되지 않은 상태를 유지하는 것으로 해석합니다. 이러한 경우 프록시는 하루 이내에 검사된 문서가 있으면 캐시에서 문서를 반환합니다.

동일한 예에서 HTTP 문서의 캐시 새로 고침 설정을 1일 이하로 설정하면 프록시는 하루에 1회 이상 최신 여부 확인을 수행합니다. 프록시는 항상 값, 캐시 새로 고침 또는 캐시 만료를 사용하고 이를 위해 업데이트를 더 자주 수행해야 합니다.

Set Cache Specifics 페이지 또는 Set Caching Configuration 페이지에서 HTTP 문서에 대한 만료 설정을 설정할 수 있습니다. Set Cache Specifics 페이지에서 전역 캐시 절차를 구성할 수 있으며 Set Caching Configuration 페이지에서 특정 URL 및 자원에 대한 캐시 절차를 제어할 수 있습니다.

원격 서버에 HTTP 액세스 보고

문서가 Sun Java System Web Proxy Server에 의해 캐시된 경우 다시 새로 고치기 전에 여러 번 액세스할 수 있습니다. 원격 서버의 경우 캐시할 프록시에 하나의 복사본을 보내면 하나의 액세스 또는 "적중 횟수"만 표시합니다.Proxy Server는 최신 여부 확인 간격 사이에 프록시 캐시에서 제공된 문서에 액세스한 횟수를 계산한 후 다음에 문서를 새로 고칠 때 추가 HTTP 요청 헤더(Cache-Info)에서 해당 적중 횟수를 원격 서버에 다시 보낼 수 있습니다. 이와 같이 원격 서버가 이러한 유형의 헤더를 인식하도록 구성된 경우 문서에 액세스한 더욱 정확한 횟수 정보가 수신됩니다.