12 장 캐시

이 장에서는 Sun Java™ System Web Proxy Server가 문서를 캐시하는 방법을 설명합니다. 또한 온라인 페이지를 사용하여 캐시를 구성하는 방법에 대해서도 설명합니다.

캐시 동작 원리

캐시는 네트워크 트래픽을 줄여 주며 원격 서버로 직접 이동하지 않고 프록시 서버를 사용하는 클라이언트에게 빠른 응답 시간을 제공합니다.

클라이언트가 프록시 서버에 웹 페이지나 문서를 요청하면 프록시 서버는 문서를 클라이언트로 보내는 동안 원격 서버에서 로컬 캐시 디렉토리로 문서를 복사합니다.

클라이언트가 이전에 요청하여 프록시 캐시에 복사된 문서를 다시 요청하는 경우 프록시는 이 문서를 원격 서버에서 다시 검색하지 않고 캐시에서 반환하게 됩니다(그림 12-1 참조). 프록시는 해당 파일이 최신 상태가 아니라고 판단하면 클라이언트에 문서를 보내기 전에 원격 서버로부터 문서를 새로 고치고 해당 캐시를 업데이트합니다.

캐시의 파일은 Sun Java™ System Web Proxy Server 가비지 수집 유틸리티(CacheGC)가 자동으로 관리합니다. CacheGC는 일정한 간격에 따라 자동으로 캐시를 비워 캐시가 시한이 지난 문서로 혼잡해지지 않도록 합니다.

Cache 구조 이해

캐시는 하나 이상의 파티션으로 구성됩니다. 파티션은 캐시를 위해 예비된 디스크의 저장 영역입니다. 캐시를 여러 디스크에 두려면 각 디스크에 대해 적어도 하나의 캐시 파티션을 구성해야 합니다. 각 파티션은 독립적으로 관리할 수 있습니다. 즉 한 파티션을 다른 모든 파티션에 독립적으로 설정, 해제 및 구성할 수 있습니다.

한 위치에 많은 수의 파일을 캐시하면 성능이 저하될 수 있으므로 각 파티션에 여러 개의 디렉토리 또는 구역을 만드는 것이 좋습니다. 구역은 캐시 구조에서 파티션 아래 단계입니다. 캐시에는 모든 파티션에 걸쳐 최대 256개의 구역을 설정할 수 있습니다. 캐시 구역의 수는 2의 제곱수여야 합니다(예: 1, 2, 4, 8, 16, ..., 256).

캐시 구조 계층에서 마지막 단계는 하위 구역입니다. 하위 구역은 구역 내의 디렉토리입니다. 각 구역에는 64개의 하위 구역이 있습니다. 캐시된 파일은 캐시에서 가장 낮은 단계인 하위 구역에 저장됩니다.

그림 12-2는 파티션과 구역이 있는 캐시 구조의 예를 보여 줍니다. 이 그림에서 캐시 디렉토리 구조는 전체 캐시를 3개의 파티션으로 나누고 있습니다. 첫 번째 파티션에는 4개의 캐시 구역이 있으며 다른 두 파티션에는 2개의 구역이 있습니다.

각 캐시 구역은 구역(section)을 나타내는 s와 구역 번호로 표시되어 있습니다. s3.4로 표시된 구역에서 3은 캐시 구역의 수에 대한 2의 제곱수(23 = 8)를 나타내며 4는 구역 번호를 나타냅니다(8개의 구역은 0부터 7까지로 표시됨). 따라서 s3.4는 8개의 구역 중 5번째 구역을 의미합니다.

캐시에 파일 분산

Proxy Server는 특정 알고리즘을 사용하여 문서를 저장할 디렉토리를 결정합니다. 이 알고리즘은 문서가 디렉토리에 균등하게 분산되도록 합니다. 디렉토리에 문서의 수가 많아지면 성능이 저하될 수 있기 때문에 균등한 분산은 중요합니다.

Proxy Server는 RSA MD5 알고리즘(Message Digest 5)을 사용하여 URL을 16바이트의 이진 데이터로 줄이고 이 중 8바이트는 문서를 캐시에 저장하는 데 사용되는 16자의 16진수 파일 이름을 계산하는 데 사용합니다.

캐시 특성 설정

캐시 특성을 설정하여 캐시를 사용하도록 하고 Proxy Server가 캐시할 프로토콜 유형을 제어할 수 있습니다. 캐시 특성에는 다음 항목이 포함됩니다.

캐시의 사용 여부

임시 파일을 저장하는 작업 디렉토리

캐시된 URL을 기록할 디렉토리의 이름

캐시 크기

캐시 용량

캐시할 프로토콜 유형

캐시된 문서를 새로 고침하는 시기

프록시가 문서 액세스 횟수를 추적하여 원격 서버에 보고하는지 여부

캐시 특성을 설정하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Set Cache Specifics 링크를 누릅니다. Set Cache Specifics 페이지가 표시됩니다.

적절한 옵션을 선택하여 캐시를 사용 또는 사용하지 않도록 설정할 수 있습니다. 기본으로 캐시는 사용함으로 설정되어 있습니다. 자세한 내용은 캐시 사용을 참조하십시오.

작업 디렉토리를 입력합니다. 기본적으로 작업 디렉토리는 프록시 인스턴스 아래에 있지만 이 디렉토리를 다른 위치에 두고 싶은 경우 변경할 수 있습니다. 자세한 내용은 캐시 작업 디렉토리 만들기를 참조하십시오.

Partition Configuration 링크를 누릅니다. Add/Edit Cache Partitions 페이지가 표시됩니다. 새 캐시 파티션을 추가하거나 기존 캐시 파티션을 편집할 수 있습니다. 캐시 크기는 캐시가 커질 수 있는 최대 크기입니다. 최대 캐시 크기는 32GB입니다. 자세한 내용은 캐시 크기 설정을 참조하십시오.

Cache Capacity Configuration 링크를 누릅니다. Set Cache Capacity 페이지가 표시됩니다. Set Cache Capacity 페이지에서 캐시 용량을 설정할 수 있습니다. 자세한 내용은 캐시 용량 편집을 참조하십시오.

HTTP 문서 캐시를 사용하려면 Cache HTTP 확인란을 선택합니다. 프록시 서버가 HTTP 문서를 캐시하도록 한 경우 캐시에 저장된 문서에 대해 항상 최신 여부를 확인하도록 할 것인지 또는 일정 간격으로 확인하도록 할 것인지 결정해야 합니다. 또한 Proxy Server에서 캐시 적중을 원격 서버로 보고할 것인지 여부를 설정할 수 있습니다. 자세한 내용은 HTTP 문서 캐시를 참조하십시오. 다음 옵션에서 선택하십시오.

HTTP를 항상 최신 상태로 유지하려면 Always Check That The Document Is Up To Date 옵션을 선택합니다.

Check Only If Last Check More Than 드롭다운 목록에서 프록시 서버의 새로 고침 간격을 시간 단위로 선택합니다. 최신 여부 확인은 다음 옵션 중 하나를 사용하여 수행됩니다.

Use Last-modified Factor. 문서와 함께 원본 서버에서 전송된 Last-modified 헤더입니다.

Use Only Explicit Expiration Information. 프록시 서버는 Expires 헤더를 사용하여 해당 캐시 항목이 새로운 것인지 오래된 것인지 판단합니다.

프록시 서버가 원격 서버에 대한 액세스 횟수를 보고하지 않도록 하려면 Never Report Accesses To Remote Server 옵션을 선택합니다.

문서가 액세스된 횟수를 추적하여 원격 서버에 보고하도록 하려면 Report Cache Hits To Remote Server 옵션을 선택합니다.

캐시된 FTP 문서에 대한 새로 고침 간격을 설정할 수 있습니다. Yes; Reload If Older Than 확인란을 선택한 다음 드롭다운 목록에서 값을 선택하여 시간 간격을 설정합니다. 자세한 내용은 FTP 및 Gopher 문서 캐시를 참조하십시오.

캐시된 Gopher 문서에 대한 새로 고침 간격을 설정할 수 있습니다. Yes; Reload If Older Than 확인란을 선택한 다음 드롭다운 목록에서 값을 선택하여 시간 간격을 설정합니다. 자세한 내용은 FTP 및 Gopher 문서 캐시를 참조하십시오.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

다음 절에서는 Set Cache Specifics 페이지에 표시되는 항목에 대한 자세한 내용을 제공하며 사용자의 요구에 가장 적합한 설정을 결정할 수 있도록 도움을 줍니다.

캐시 사용

캐시는 프록시 서버 사용자의 네트워크 트래픽을 감소시키는 효과적인 방법입니다. 캐시는 또한 원격 서버에서 문서를 검색할 필요가 없도록 하여 클라이언트에 더 빠른 응답 시간을 제공합니다. 프록시 서버는 캐시를 사용할 때 가장 효과적으로 작동합니다.

캐시 작업 디렉토리 만들기

캐시 파일은 캐시 파티션 아래에 있습니다. 대개의 경우 사용자는 Set Cache Specifics 페이지에서 캐시의 상위 디렉토리를 작업 디렉토리로 지정합니다. 캐시된 모든 파일은 캐시 디렉토리 아래에 구성된 디렉토리 구조에 표시됩니다. 캐시 디렉토리의 이름을 변경하거나 다른 위치로 이동시키면 프록시에게 새 위치를 알려주어야 합니다.

캐시 디렉토리 구조는 여러 파일 시스템으로 확장할 수 있습니다. 이렇게 하면 대용량 디스크 하나에 모든 파일을 둘 필요 없이 여러 개의 작은 디스크로 분할된 캐시 구조를 만들 수 있습니다. 각 프록시 서버는 자체 캐시 디렉토리 구조를 갖고 있어야 합니다. 즉, 여러 프록시 서버에서 캐시 디렉토리를 동시에 공유할 수 없습니다.

캐시 크기 설정

캐시 크기는 파티션 크기를 나타냅니다. 캐시 용량은 허용된 최대 크기이므로 캐시 크기는 캐시 용량보다 항상 작아야 합니다. 모든 파티션 크기의 합은 캐시 크기와 같거나 작아야 합니다.

프록시 캐시가 사용할 수 있는 디스크 공간의 크기는 캐시 성능에 중요한 영향을 미칩니다. 캐시가 너무 작으면 Cache GC가 디스크 공간 확보를 위해 그만큼 더 자주 캐시된 문서를 제거해야 하며, 문서를 컨텐트 서버에서 검색하는 일도 더 잦아집니다. 따라서 성능이 저하됩니다.

캐시 크기는 크게 하는 것이 좋은데, 더 많은 문서가 캐시될수록 네트워크 트래픽 부하는 줄어들고 프록시의 응답 시간은 더 빨라지기 때문입니다. Cache GC는 또한 사용자에게 더 이상 필요 없는 캐시된 문서를 제거합니다. 다른 시스템 제한이 없다면 캐시 크기는 크게 할수록 좋습니다. 초과되는 공간은 사용되지 않은 상태로 남아 있게 됩니다.

또한 캐시를 여러 디스크 파티션에 나누어 둘 수도 있습니다.

캐시 용량 편집


주의	캐시 구조 변경에는 많은 시간이 소요됩니다.

Set Cache Capacity 페이지 및 Set Cache Specifics 페이지에서 캐시 용량을 편집할 수 있습니다. 캐시 용량 편집에 대한 자세한 내용은 Cache 용량 설정을 참조하십시오.

HTTP 문서 캐시

HTTP 문서 캐시와 FTP 및 Gopher 문서 캐시는 내부적으로 다릅니다. HTTP 문서는 다른 프로토콜의 문서에는 없는 캐시 기능을 제공합니다. 캐시를 적절히 설정 및 구성하면 Proxy Server가 HTTP, FTP 및 Gopher 문서를 효과적으로 캐시하도록 할 수 있습니다.

모든 HTTP 문서에는 설명 헤더 섹션이 있어 Proxy Server에서 이를 사용하여 프록시 캐시와 원격 서버에 있는 문서를 비교 및 평가할 수 있습니다. 프록시는 HTTP 문서의 최신 여부를 확인할 때 캐시에 있는 문서가 오래된 버전일 경우 서버에 문서를 반환하라는 요청을 보냅니다. 마지막 요청 이후 문서가 변경되지 않아 서버에서 문서를 전송하지 않는 경우가 많습니다. 이 방법으로 HTTP 문서의 최신 상태를 확인함으로써 대역폭을 절약하고 지연을 줄일 수 있습니다.

Proxy Server에서는 HTTP 문서의 Cache Expiration을 설정하여 원격 서버와의 트랜잭션을 줄일 수 있습니다. Cache Expiration 설정에 따라 프록시는 서버에 요청을 보내기 전에 HTTP 문서의 최신 여부 확인이 필요한지 판단합니다. 프록시는 HTTP 문서의 Last-Modified 헤더에 있는 최종 수정 날짜를 기반으로 최신 여부 확인의 필요 여부를 판단합니다.

HTTP 문서에는 Cache Refresh 설정도 사용할 수 있습니다. 이 옵션은 프록시가 Expiration 설정을 무시하고 항상 최신 여부 확인을 수행할지, 아니면 최신 여부를 확인하기 전에 지정한 기간 동안 기다릴지 지정합니다. 표 12-1은 Expiration 및 Refresh 설정을 모두 지정한 경우 프록시의 동작을 보여 줍니다. Refresh 설정을 사용하면 지연을 줄이고 대역폭을 상당히 절약할 수 있습니다.

표 12-1
HTTP Cache Expiration 및 Cache Refresh 설정 사용
Refresh 설정	Expiration 설정	Results
Always do an up-to-date check	(해당 사항 없음)	항상 최신 여부 확인
User-specified interval	문서의 "expires" 헤더 사용	간격이 만료되었는지 최신 여부 확인
User-specified interval	문서의 Last-Modified 헤더로 평가	평가한 값과 expires 헤더 값 중 작은 값*

* 두 값 중 작은 값을 사용함으로써 자주 변경되는 문서에 대해 캐시에서 오래된 데이터를 가져오는 문제를 방지할 수 있습니다.

HTTP 캐시 새로 고침 간격 설정

Proxy Server가 HTTP 문서를 캐시하도록 한 경우 캐시에 저장된 문서에 대해 항상 최신 여부를 확인하도록 할 것인지 또는 Cache Refresh 설정(최신 여부 확인 간격)을 기반으로 확인하도록 할 것인지 결정해야 합니다. 예를 들어 HTTP 문서의 경우 적절한 새로 고침 간격은 4 ~ 8시간입니다. 새로 고침 간격이 길수록 프록시가 원격 서버에 연결하는 횟수는 줄어듭니다. 프록시가 새로 고침 간격 도중에 최신 여부 확인을 하지 않는 경우에도 클라이언트의 Reload 버튼을 눌러 프록시가 원격 서버에 연결해 최신 여부를 확인하도록 함으로써 새로 고침을 강제할 수 있습니다.

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

HTTP 캐시 만료 정책 설정

또한 최종 수정 요인 또는 명시적인 만료 정보만 사용하여 캐시된 문서의 최신 여부를 확인하도록 서버를 설정할 수 있습니다.

명시적인 만료 정보는 일부 HTTP 문서에서 파일의 시한이 만료되는 날짜 및 시간을 지정하는 헤더입니다. 명시적인 Expires 헤더를 사용하는 HTTP 문서는 많지 않기 때문에 Last-modified 헤더를 기반으로 판단하는 것이 좋습니다.

Last-modified 헤더를 기반으로 HTTP 문서를 캐시하도록 결정한 경우 만료 판단에 사용할 분수를 선택해야 합니다. LM 요인이라고 하는 이 분수에 마지막 수정 시간과 문서에서 마지막으로 최신 여부를 확인한 시간의 간격을 곱합니다. 결과 수와 최신 여부 확인을 마지막으로 수행한 이후 지난 시간을 비교합니다. 결과 수가 시간 간격보다 작으면 문서가 만료되지 않은 것입니다. 분수가 작을수록 프록시는 더 자주 문서를 확인합니다. 예를 들어 10일 전에 마지막으로 변경된 문서가 있습니다. 최종 수정 요인을 0.1로 설정하면 프록시는 문서가 1일(10 * 0.1 = 1) 동안 변경되지 않을 것이라는 의미로 해석합니다. 프록시는 문서를 마지막으로 확인한 후 1일 이내에는 이 문서를 캐시에서 반환합니다.

이 예에서 HTTP 문서에 대한 캐시 새로 고침 설정이 1일 미만으로 설정되어 있다면 프록시는 하루에 한 번 이상 최신 여부를 확인합니다. 프록시는 항상 캐시 새로 고침 또는 캐시 만료 값 중 더 빈번한 업데이트를 요구하는 값을 사용합니다.

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

원격 서버에 HTTP 액세스 보고

Sun Java™ System Web Proxy Server에서 캐시한 문서는 새로 고치기 전에 여러 번 액세스될 수 있습니다. 원격 서버에서 프록시가 캐시할 한 개의 사본을 보내는 것은 한 번의 액세스, 또는 "적중"을 의미합니다. Sun Java™ System Web Proxy Server는 지정한 문서가 최신 여부 확인 사이에 프록시 캐시에서 액세스된 횟수를 계산하고 문서의 다음 새로 고침 시 이 적중 수를 추가 HTTP 요청 헤더(Cache-Info)를 통해 원격 서버로 보낼 수 있습니다. 원격 서버가 이 유형의 헤더를 인식하도록 구성된 경우 더 정확한 문서 액세스 횟수를 받을 수 있습니다.

FTP 및 Gopher 문서 캐시

FTP 및 Gopher는 문서가 최신 상태인지 확인할 수 있는 방법을 포함하고 있지 않습니다. 따라서 FTP 및 Gopher 문서에서 캐시를 최적화하는 유일한 방법은 Cache Refresh 간격을 설정하는 것입니다. Cache Refresh 간격은 Proxy Server가 원격 서버에서 최신 버전의 문서를 검색하기 전까지 기다리는 시간입니다. Cache Refresh 간격을 설정하지 않으면 프록시는 캐시에 있는 문서가 최신 상태인 경우에도 이러한 문서를 검색하게 됩니다.

FTP 및 Gopher Cache Refresh 간격 설정

FTP 및 Gopher에 대한 캐시 새로 고침 간격을 설정하는 경우 프록시에서 가져오는 문서에 대해 안심할 수 있는 간격을 선택합니다. 예를 들어 거의 변경되지 않는 정보를 저장하는 경우 높은 수(며칠)를 사용합니다. 계속 변경되는 데이터인 경우 적어도 몇 시간 간격으로 검색되도록 설정합니다. 새로 고침 시간 중에는 오래된 파일을 클라이언트로 보낼 위험이 있습니다. 간격을 몇 시간 정도로 충분히 짧게 하면 현저히 빠른 응답 시간을 확보하면서 이러한 위험을 거의 없앨 수 있습니다.

FTP 및 Gopher 문서에 대한 캐시 새로 고침 간격은 Set Cache Specifics 페이지 또는 Set Caching Configuration 페이지에서 설정할 수 있습니다. Set Cache Specifics 페이지에서는 전역 캐시 절차를 구성할 수 있으며 Set Caching Configuration 페이지에서는 특정 URL 및 리소스에 대한 캐시 절차를 제어할 수 있습니다. Set Cache Specifics 페이지와 Set Caching Configuration 페이지 사용에 대한 자세한 내용은 각각 캐시 특성 설정과 캐시 구성을 참조하십시오.


참고	FTP 및 Gopher 문서가 일부는 자주 변경되고 일부는 거의 변경되지 않는 등 종류가 다양한 경우에는 Set Caching Configuration 페이지를 사용하여 각 문서 종류에 대해 별도의 템플릿을 만들어(예: ftp://.*.gif 리소스로 템플릿 생성) 해당 리소스에 대해 적절한 새로 고침 간격을 설정합니다.

Cache 생성 및 수정

캐시 파티션은 디스크 및 메모리에서 캐시에 사용하기 위해 예비된 부분입니다. 캐시 용량이 변경된 경우 Add/Edit Cache Partitions 페이지에서 파티션을 변경하거나 추가할 수 있습니다. 이 페이지에서 파티션의 위치, 연상 기억 이름, 최대 및 최소 크기를 편집할 수 있으며, 해당 파티션의 캐시 구역 테이블을 볼 수 있습니다.

캐시 파티션을 추가하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Add/Edit Cache Partitions 링크를 누릅니다. Add/Edit Cache Partitions 페이지가 표시됩니다.

Add Cache Partition 버튼을 누릅니다. Cache Partition Configuration 페이지가 표시됩니다.

새 파티션에 대해 적절한 값을 입력합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

cache 파티션을 수정하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Add/Edit Cache Partitions 링크를 누릅니다. Add/Edit Cache Partitions 페이지가 표시됩니다.

변경하려는 파티션의 이름을 누릅니다.

정보를 수정합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

Cache 용량 설정

캐시 용량 값은 캐시 디렉토리 구조를 유도하는 데 사용됩니다. 캐시 디렉토리에 있을 수 있는 구역의 수는 캐시 용량에 따라 결정됩니다. Set Cache Capacity 페이지가 나타나며, 이 페이지에서 캐시 용량을 설정할 수 있습니다. 용량이 클수록 계층도 커집니다. 캐시 용량은 캐시 크기와 같거나 더 커야 합니다. 이후 외부 디스크를 추가하는 등의 방법으로 캐시 크기를 늘릴 계획이 있는 경우 캐시 용량을 캐시 크기보다 크게 설정하는 것이 좋습니다. 최대 캐시 용량은 32GB이며 이 경우 256개의 구역이 생성됩니다.

캐시 용량을 설정하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Set Cache Capacity 링크를 누릅니다. Set Cache Capacity 페이지가 표시됩니다.

New Capacity Range 드롭다운 목록에서 용량을 선택합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

Cache 구역 관리

프록시 캐시는 하나 이상의 캐시 구역으로 분할되어 있습니다. 구역은 최대 256개입니다. 캐시 구역의 수는 2의 제곱수여야 합니다(예: 1, 2, 4, 8, 16, ..., 256). 최대 용량은 32GB(최적)로, 캐시 구역은 256개입니다.

캐시 용량을 500MB로 설정하면 설치 프로그램은 4개의 캐시 구역을 만들며(500 / 125 = 4), 2GB로 선택하면 16개의 구역을 만듭니다(2000 / 125 = 16). 각 구역에 대한 최적 값이 125MB로 선택되어 이와 같은 구역 수가 나오게 됩니다. 구역의 수가 많을수록 저장되고 구역으로 분산되는 URL의 수도 많아집니다.

캐시 구역을 관리하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Manage Sections 링크를 누릅니다. Manage Sections 페이지가 표시됩니다.

테이블의 정보를 변경합니다. 파티션 간에 구역을 이동할 수 있습니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

가비지 수집 기본 설정 지정

Set Garbage Collection Preferences 페이지는 가비지 수집 모드를 설정하는 데 사용됩니다.

캐시 가비지 수집기를 사용하여 캐시에서 파일을 제거할 수 있습니다. 가비지 수집은 자동 모드 또는 명시적 모드로 수행됩니다. 명시적 모드는 관리자가 외부에서 Schedule Garbage Collection 페이지를 사용하여 예약합니다. 두 모드 중 하나를 선택한 다음 OK를 누릅니다. Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다. Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

가비지 수집 일정

Schedule Garbage Collection 페이지에서 가비지 수집이 실행되는 날짜와 시간을 지정할 수 있습니다.

가비지 수집 일정을 지정하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Schedule Garbage Collection 링크를 누릅니다. Schedule Garbage Collection 페이지가 표시됩니다.

Schedule Garbage Collection At 목록에서 가비지 수집이 실행되는 시간을 선택합니다.

가비지 수집이 실행되는 주중 요일을 지정합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

캐시 구성

Set Caching Configuration 페이지를 사용하여 특정 리소스에 대해 사용하려는 캐시의 종류를 구성할 수 있습니다. 지정한 정규식 패턴에 일치하는 URL에 대한 몇 가지의 구성 매개 변수를 지정할 수 있습니다. 이 기능을 사용하면 캐시된 문서의 유형에 따라 프록시 캐시를 미세하게 제어할 수 있습니다. 캐시를 구성하는 과정에서 다음 항목들을 확인할 수 있습니다.

캐시 기본값

인증이 필요한 페이지를 캐시하는 방법

쿼리를 캐시하는 방법

캐시 파일의 최소, 최대 크기

캐시된 문서를 새로 고침하는 시기

캐시 만료 정책

클라이언트 중단에 대한 캐시 동작

원래 서버에 대해 실패한 연결에 대한 캐시 동작



참고	특정 리소스에 대한 캐시 기본값을 Derived Configuration, 또는 Don’t Cache로 설정한 경우 Set Caching Configuration 페이지에 캐시 구성 옵션이 표시되지 않습니다. 그러나 리소스에 대한 캐시 기본값을 캐시 사용함으로 선택하면 몇 가지 다른 구성 항목을 지정할 수 있습니다.

캐시를 구성하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Set Caching Configuration 페이지를 누릅니다. Set Caching Configuration 페이지가 표시됩니다.

드롭다운 목록에서 리소스를 선택하거나 Regular Expression 버튼을 누르고 정규식을 입력한 다음 OK를 누릅니다.

구성 정보를 변경합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

캐시 구성 요소

다음 절에서는 Set Caching Configuration 페이지에 표시되는 항목에 대해 설명합니다. 이 절은 사용자의 요구에 가장 적합한 구성을 결정하는 데 도움이 되는 정보를 포함하고 있습니다.

캐시 기본값 설정

프록시 서버는 특정 리소스에 대한 캐시 기본값을 확인할 수 있도록 합니다. 리소스는 사용자가 지정한 특정 기준에 일치하는 파일 유형입니다. 예를 들어 도메인 company.com의 모든 문서를 자동으로 캐시하도록 서버를 구성하려고 합니다. 이 경우 Set Caching Configuration 페이지의 상단에 있는 Regular Expression 버튼을 누르고 표시되는 필드에 다음을 입력합니다.

기본적으로 캐시 옵션이 선택되어 있습니다. 이렇게 하면 서버는 해당 도메인의 캐시 가능한 모든 문서를 자동으로 캐시합니다. 정규식에 대한 자세한 내용은 Understanding Regular Expressions를 참조하십시오.

HTTP, FTP, Gopher에 대한 캐시 기본값도 Set Cache Specifics 페이지에서 설정할 수 있습니다.

Caching Pages That Require Authentication

서버가 사용자 인증이 필요한 파일을 캐시하도록 할 수 있습니다. 이러한 파일을 캐시하도록 선택하면 Proxy Server는 캐시 파일에 표시를 남겨 사용자가 원격 서버의 인증이 필요한 파일을 요청하는 경우 이를 알 수 있도록 합니다.

프록시 서버는 원격 서버의 인증 방법과 사용자 ID 및 비밀번호를 알 수 없기 때문에, 인증이 필요한 문서 요청이 들어올 때마다 단순히 원격 서버를 통한 최신 여부 확인을 강제합니다. 따라서 해당 파일에 액세스하려면 사용자는 ID와 암호를 입력해야 합니다. 사용자가 Navigator 세션에서 이전에 이미 해당 서버에 액세스한 경우 Navigator는 사용자에게 입력을 요구하지 않고 자동으로 인증 정보를 전송합니다.

인증이 필요한 페이지의 캐시를 사용하도록 설정하지 않은 경우 프록시는 기본값으로 간주하여 이러한 페이지를 캐시하지 않습니다.

Caching Queries

캐시된 쿼리는 HTTP 문서에서만 동작합니다. 캐시된 쿼리의 길이를 제한하거나 쿼리 캐시를 완전히 금지할 수 있습니다. 쿼리가 길수록 캐시 내에서 중복될 가능성은 줄어들지만, 그만큼 캐시의 유용성도 작아집니다.

이러한 캐시 제한은 다음과 같은 조건의 쿼리에 적용됩니다. 액세스 메소드는 GET이어야 하며, 문서 보호가 적용되지 않아야 하고(인증된 페이지 캐시를 사용하지 않는 경우), 응답에는 최소한 Last-modified 헤더가 있어야 합니다. 따라서 쿼리 엔진은 해당 쿼리 결과 문서가 캐시될 수 있음을 표시해야 합니다. Last-Modified 헤더가 있는 경우 쿼리 엔진은 캐시 효과를 위해 조건부 GET 메소드(If-Modified-Since 헤더와 함께 사용)를 지원해야 합니다. 그렇지 않은 경우 Expires 헤더를 반환해야 합니다.

캐시 파일 최소 및 최대 크기 설정

Proxy Server에서 캐시하는 파일의 최소 및 최대 크기를 설정할 수 있습니다. 네트워크 연결 속도가 빠른 경우라면 최소 크기를 설정할 것입니다. 네트워크 속도가 빠르면 용량이 작은 파일은 빠르게 검색되므로 서버에서 캐시할 필요가 없습니다. 이 경우 용량이 비교적 큰 파일만 캐시할 것입니다. 최대 파일 크기를 설정하면 용량이 큰 파일이 프록시의 디스크 공간을 너무 많이 차지하지 않도록 할 수 있습니다.

최신 여부 확인 정책 설정

이 옵션을 사용하면 HTTP 문서가 항상 최신 상태가 되도록 할 수 있습니다. 또한 Proxy Server의 새로 고침 간격을 지정할 수 있습니다.

만료 정책 설정

마지막으로 수정된 요인 또는 명시적인 만료 정보를 사용하여 만료 정책을 설정할 수 있습니다.

클라이언트 중단에 대한 캐시 동작 설정

문서의 일부분만 가져온 상황에서 클라이언트가 데이터 전송을 중단한 경우에도 프록시는 캐시를 위해 해당 문서 전체를 가져올 수 있습니다. 프록시 기본값은 문서의 25% 이상을 이미 가져온 경우 문서 전체를 가져와 캐시에 저장하도록 합니다. 25% 미만이면 프록시는 해당 원격 서버와의 연결을 종료하고 가져온 파일 일부분을 제거합니다. 클라이언트 중단 비율을 높이거나 낮출 수 있습니다.

Behaviour On Failure To Connect To Server

원본 서버에 연결되지 않아 지난 문서의 최신 여부를 확인할 수 없는 경우 프록시가 캐시의 지난 문서를 전송할 것인지 지정할 수 있습니다.


참고	특정 리소스에 대한 캐시 기본값을 Derived Configuration, 또는 Don’t Cache로 설정한 경우 해당 리소스에 대한 캐시를 구성할 필요가 없습니다. 그러나 리소스에 대한 캐시 기본값을 캐시 사용함으로 선택하면 몇 가지 다른 구성 항목을 지정할 수 있습니다. 이러한 항목 목록은 캐시 구성을 참조하십시오.

로컬 호스트 캐시

로컬 호스트에서 요청한 URL에 도메인 이름이 없는 경우 Proxy Server는 중복 캐시를 막기 위해 이를 캐시하지 않습니다. 예를 들어 사용자가 로컬 서버에서 http://machine/filename.html과 http://machine.example.com/filename.html을 요청하면 두 URL은 모두 캐시에 표시됩니다. 이와 같은 파일들은 로컬 서버에서 전송되기 때문에 빠르게 가져올 수 있으며, 따라서 캐시할 필요가 없습니다.

그러나 많은 원격 위치에 서버를 두고 있는 기업에서는 모든 호스트의 문서를 캐시하도록 하여 네트워크 트래픽을 감소시키고 이 파일들에 액세스하는 데 필요한 시간을 줄일 수 있습니다.

로컬 호스트의 캐시를 사용하도록 설정하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Cache Local Hosts 링크를 누릅니다. Cache Local Hosts 페이지가 표시됩니다.

드롭다운 목록에서 리소스를 선택하거나 Regular Expression 버튼을 누르고 정규식을 입력한 다음 OK를 누릅니다. 정규식에 대한 자세한 내용은 템플릿 및 리소스 관리를 참조하십시오.

Enabled 버튼을 누릅니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

파일 캐시 구성

기본적으로 파일 캐시는 사용하도록 설정됩니다. 파일 캐시 설정은 server.xml 파일에 포함됩니다. Server Manager를 사용하여 파일 캐시 설정을 변경할 수 있습니다.

파일 캐시를 구성하려면 다음을 수행합니다.


참고	Configure File Cache 페이지는 사용자 인터페이스에 표시되지만 Proxy Server 4 릴리스에서 구현되지는 않았습니다.

Server Manager에서 Preferences 탭을 누릅니다.

File Cache Configuration 링크를 누릅니다. File Cache Configuration 페이지가 표시됩니다.

Enable File Cache가 선택되지 않았으면 선택합니다.

파일 전송 여부를 선택합니다.

Transmit File을 사용하면 서버는 파일 내용이 아닌 파일 캐시에서 파일의 열린 파일 설명자(descriptor)를 캐시하고 PR_TransmitFile은 파일 내용을 클라이언트로 전송하는 데 사용됩니다. Transmit File을 사용하면 열린 파일 설명자만 캐시되므로 일반적인 파일 캐시의 대, 중, 소 규모의 파일 구분이 더 이상 적용되지 않습니다. 기본적으로 Transmit File은 Windows에서는 사용하도록 설정되며 UNIX에서는 사용하지 않도록 설정됩니다. UNIX의 경우 PR_TransmitFile을 운영 체제에서 원시 지원하는 플랫폼에서만 Transmit File을 사용합니다. 현재 이러한 플랫폼에는 HP-UX와 AIX가 있습니다. 이 외의 UNIX/Linux 플랫폼에서는 Transmit File 사용을 권장하지 않습니다.

해시 테이블의 크기를 입력합니다. 기본 크기는 파일의 최대 수의 두 배 더하기 1입니다. 예를 들어, 파일의 최대 수가 1024로 설정되었으면 기본 해시 테이블 크기는 2049입니다.

유효한 캐시 항목의 최대 지속 시간을 입력합니다(초 단위). 기본값은 30입니다. 이 설정에 따라 파일이 캐시된 후 캐시된 정보가 계속하여 사용되는 시간이 달라집니다. 동일한 파일이 캐시를 통하여 참조된 경우, MaxAge 값보다 오래된 항목은 동일한 파일의 새 항목으로 대체됩니다. 컨텐트가 일정한 스케줄에 의하여 업데이트(기존 파일이 변경)되는지의 여부에 따라 최대 지속 시간을 설정합니다. 예를 들어 컨텐트가 하루에 네 번 일정 간격으로 업데이트 된다면 Maximum Age를 21600초(6시간)로 설정할 수 있습니다. 그렇지 않은 경우, 컨텐트 파일의 이전 버전을 수정 후 최대 얼마동안 서비스할지에 따라 Maximum Age를 설정하는 것이 좋습니다.

캐시할 최대 파일 개수를 입력합니다. 기본값은 1024입니다.

Medium File Size Limit 및 Small File Size Limit값을 입력합니다(바이트 단위). Medium File Size Limit 기본값은 537600, Small File Size Limit 기본값은 2048입니다.

캐시는 대, 중, 소형의 파일을 각기 다르게 처리합니다. 중간 크기 파일의 내용은 파일을 가상 메모리(현재 UNIX/Linux 플랫폼에만 적용)에 매핑하여 캐시합니다. 작은 파일의 내용은 힙 공간(heap space)을 할당하고 파일을 이 공간으로 읽어 캐시합니다. 큰 파일(중간 크기 파일보다 큰)의 경우 파일에 대한 정보는 캐시하지만 내용은 캐시하지 않습니다. 작은 파일과 중간 크기 파일을 구별하면 작은 파일이 많은 경우 가상 메모리의 페이지에서 많은 부분이 낭비되지 않도록 할 수 있는 장점이 있습니다. 따라서 Small File Size Limit값은 일반적으로 VM 페이지 크기보다 약간 작게 설정합니다.

중간 파일 공간 및 작은 파일 공간을 설정합니다. 중간 파일 공간은 모든 중간 크기 파일을 매핑하는 데 사용되는 가상 메모리의 크기(바이트 단위)입니다. 기본값은 10485760입니다. 작은 파일 공간은 캐시에 사용되는 힙 공간의 크기(바이트 단위)이며, 작은 파일을 캐시하는 데 사용되는 힙 공간을 포함합니다. UNIX/Linux 플랫폼에서 기본값은 1048576입니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

URL 데이터베이스 확인

캐시된 모든 URL의 기록에서 이름과 속성을 확인할 수 있습니다. URL 정보에서는 액세스 프로토콜과 사이트 이름에 따라 그룹화된 캐시된 문서 목록이 표시됩니다. 목록에서 제한된 URL만 보려면 Search 필드에 도메인 이름을 입력합니다. 이 정보를 통하여 캐시에서 문서를 제거하거나 기간을 만료하는 것과 같은 다양한 캐시 관리 기능을 수행할 수 있습니다.

데이터베이스에서 URL을 확인하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

View URL Database 링크를 누릅니다. View URL Database 페이지가 표시됩니다.

Regenerate 버튼을 누르면 캐시된 URL의 현재 목록을 생성합니다. 특정 URL에 대한 정보를 보려면 URL 또는 정규식을 Search 필드에 입력한 다음 Search 버튼을 누릅니다.

도메인 이름과 호스트에 따라 그룹화된 캐시 데이터베이스 정보를 보려면 목록에서 도메인 이름을 선택합니다. 해당 도메인의 호스트 목록이 표시됩니다. 호스트 이름을 누르면 URL 목록이 표시됩니다.

URL 이름을 누릅니다. 해당 URL에 대한 자세한 정보가 표시됩니다.

캐시에서 파일 만료 및 제거

View URL Database 페이지를 사용하여 캐시에서 문서의 기간을 만료하거나 문서를 제거할 수 있습니다.

캐시된 URL의 기간을 만료하거나 제거하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

View URL Database 링크를 누릅니다. View URL Database 페이지가 표시됩니다.

Regenerate 버튼을 누릅니다. 캐시 데이터베이스의 스냅숏이 생성됩니다. 나머지 단계는 이 스냅숏을 기반으로 합니다.

기간을 만료하거나 제거하려는 특정 URL을 아는 경우 Search 필드에 이 URL 또는 이 URL과 일치하는 정규식을 입력하고 Search 버튼을 누릅니다. 도메인 이름과 호스트에 따라 그룹화된 URL로 작업하려면 목록에서 도메인 이름을 선택합니다. 해당 도메인의 호스트 목록이 표시됩니다. 호스트 이름을 누르면 URL 목록이 표시됩니다.

개별 파일의 기간을 만료하려면 해당 파일에 대한 URL 옆에 있는 Ex 옵션을 선택하고 Exp/Rem Marked 버튼을 누릅니다. 목록에 있는 모든 파일의 기간을 만료하려면 양식 하단의 Exp All 버튼을 누릅니다. 캐시에서 개별 파일을 제거하려면 해당 파일에 대한 URL 옆에 있는 Rm 옵션을 선택하고 Exp/Rem Marked 버튼을 누릅니다. 목록에 있는 모든 파일을 제거하려면 Rem All 버튼을 누릅니다.

스냅숏을 다시 생성하려면 Regenerate 버튼을 누릅니다.



참고	Ex 또는 Rm 옵션을 사용하면 해당 파일은 처리되지만 스냅숏에는 변경 사항이 적용되지 않습니다. 변경 사항을 보려면 스냅숏을 다시 생성해야 합니다.

Cache Batch Updates 사용

Cache Batch Updates 기능을 사용하면 프록시 서버가 사용 중이 아닐 때 특정 웹 사이트의 파일을 미리 로드하거나 이미 캐시에 있는 문서의 최신 여부를 확인할 수 있습니다. Set Cache Batch Updates 페이지에서 URL을 일괄적으로 작성, 편집, 제거할 수 있으며 일괄 업데이트를 사용 또는 사용하지 않도록 설정할 수 있습니다.

일괄 업데이트 생성

파일을 일괄 업데이트하도록 지정하면 필요에 따라 캐시하는 것과 달리 활발하게 파일을 캐시할 수 있습니다. 프록시 서버는 현재 캐시에 있는 여러 파일의 최신 여부를 확인하거나 특정 웹 사이트에 있는 여러 파일을 미리 로드할 수 있도록 합니다.

일괄 업데이트를 만들려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Set Cache Batch Updates 링크를 누릅니다. Set Cache Batch Updates 페이지가 표시됩니다.

Create/Select a Batch Update Configuration 옆에 있는 드롭다운 목록에서 New and Create를 선택합니다.

OK를 누릅니다. Set Cache Batch Updates 페이지가 표시됩니다.

Name 섹션에 새로운 일괄 업데이트 항목의 이름을 입력합니다.

페이지의 Source 섹션에서 새로 만들 일괄 업데이트 유형에 해당하는 라디오 버튼을 누릅니다. 캐시에 있는 모든 문서의 최신 여부 확인을 수행하려면 첫 번째 라디오 버튼을 누릅니다. 주어진 원본 URL로 시작하는 URL을 반복적으로 캐시하려면 두 번째 라디오 버튼을 누릅니다.

Source 섹션 필드에 일괄 업데이트에서 사용할 문서를 지정합니다.

Exceptions 섹션에 일괄 업데이트에서 제외할 파일을 지정합니다.

Resources 섹션에 최대 동시 연결 수와 통과할 최대 문서 수를 입력합니다.

Timing 섹션에 일괄 업데이트의 생성 시작과 종료 시간을 입력합니다. 일괄 업데이트는 한 번에 하나만 활성화할 수 있으므로 다른 일괄 업데이트 구성과 겹치지 않도록 하는 것이 좋습니다.

OK를 누릅니다.



참고	일괄 업데이트를 사용하지 않는 경우에도 일괄 업데이트 구성을 작성, 편집, 제거할 수 있습니다. 그러나 Set Cache Batch Updates 페이지에서 설정한 시간에 따라 일괄 업데이트를 수행하려면 업데이트를 사용해야 합니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

일괄 업데이트 구성 편집 및 삭제

Set Cache Batch Updates 페이지에서 일괄 업데이트를 편집하거나 제거할 수 있습니다. 일괄 업데이트를 편집하여 특정 파일을 제외하거나 일괄 업데이트 간격을 더 작게 할 수 있습니다. 일괄 업데이트를 완전히 제거할 수도 있습니다.

일괄 업데이트 구성을 편집 또는 삭제하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Set Cache Batch Updates 링크를 누릅니다. Set Cache Batch Updates 페이지가 표시됩니다.

일괄 업데이트를 편집하려면 일괄 업데이트의 이름을 선택하고 Create/Select a Batch Update Configuration 옆에 있는 드롭다운 목록에서 "Edit"를 선택합니다. 일괄 업데이트를 삭제하려면 일괄 업데이트의 이름을 선택하고 드롭다운 목록에서 "Delete"를 선택합니다.

OK를 누릅니다. Set Cache Batch Updates 페이지가 표시됩니다.

원하는 대로 정보를 수정합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

캐시 명령줄 인터페이스 사용

프록시 서버에는 캐시 디렉토리 구조를 구성, 변경, 생성 및 수정할 수 있는 여러 개의 명령줄 유틸리티가 포함되어 있습니다. 이러한 유틸리티의 대부분은 Server Manager 페이지와 기능이 중복되지만 크론 작업과 같은 유지 보수 일정을 예약하는 경우 이 유틸리티를 사용할 수 있습니다. 모든 유틸리티는 extras 디렉토리에 있습니다.

명령줄 유틸리티를 실행하려면 다음을 수행합니다.

명령줄 프롬프트에서 server_root/proxy-serverid 디렉토리로 이동합니다.

./start -shell을 입력합니다.

다음 절에서는 다양한 유틸리티에 대해 설명합니다.

캐시 디렉토리 구조 구축

프록시에 포함된 cbuild 유틸리티는 오프라인 캐시 데이터베이스 관리자입니다. 이 유틸리티로 명령줄 인터페이스를 사용하여 새 캐시 구조를 만들거나 기존 캐시 구조를 수정할 수 있습니다. Server Manager 페이지를 사용하여 프록시에서 새로 만든 캐시를 사용하도록 할 수 있습니다. 이 유틸리티는 server.xml 파일을 업데이트하지 않습니다. cbuild는 여러 파티션이 있는 캐시의 크기를 조정할 수 없습니다. server.xml 파일에 있는 CACHE라는 요소에는 cachecapacity 매개 변수가 있습니다. cbuild에서 캐시를 만들거나 수정한 경우 cachecapacity 매개 변수를 server.xml 파일에서 직접 업데이트해야 합니다.

cbuild 유틸리티는 두 가지 모드로 실행할 수 있습니다. 첫 번째 모드는 다음과 같습니다.

cbuild -d server_root/proxy-serverid/config -c server_root/proxy-serverid/cache -s 512

cbuild -d server_root/proxy-serverid/config -c server_root/proxy-serverid/cache -s 512 -r

conf-dir은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

cache-dir은 캐시 구조에 대한 디렉토리입니다.

cache size는 캐시가 커질 수 있는 최대 크기입니다. 이 옵션은 cache-dim 매개 변수와 함께 사용할 수 없습니다. 최대 크기는 65135MB입니다.

-r은 기존 캐시 구조의 크기를 조정합니다(캐시에 파티션이 하나만 있는 경우). 캐시를 새로 만드는 경우에는 필요하지 않습니다.

cbuild -d server_root/proxy-serverid/config -c server_root/proxy-serverid/cache -n 3

cbuild -d server_root/proxy-serverid/config -c server_root/proxy-serverid/cache -n 3 -r

conf-dir은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

cache-dir은 캐시 구조에 대한 디렉토리입니다.

cache-dim은 구역의 수를 결정합니다. 예를 들어 그림 12-1의 s3.4로 표시된 구역에서 3은 캐시 구역의 수를 나타냅니다. cache-dim의 기본값은 0이며 최대값은 8입니다.

-r은 기존 캐시 구조의 크기를 조정합니다(캐시에 파티션이 하나만 있는 경우). 캐시를 새로 만드는 경우에는 필요하지 않습니다.

캐시 URL 목록 관리

프록시에 포함된 urldb 유틸리티는 캐시의 URL 목록을 관리합니다. 이 유틸리티를 사용하여 캐시된 URL을 나열할 수 있습니다. 또한 선택적으로 캐시 데이터베이스에서 캐시된 개체의 기간을 만료하거나 제거할 수 있습니다.

urldb 명령은 -o 옵션을 기반으로 다음의 세 그룹으로 분류할 수 있습니다.

도메인

사이트

URL

urldb -o matching_domains -e ".*phoenix.*" -d server_root/proxy-serverid/config

matching_domains는 정규식에 일치하는 도메인을 나열합니다.

reg_exp는 사용되는 정규식입니다.

conf-dir은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

도메인에서 일치하는 모든 사이트를 나열하려면 명령줄에서 다음을 입력합니다.

urldb -o matching_sites_in_domain -e “.*atlas” -m phoenix.com -d server_root/proxy-serverid/config

matching_sites_in_domain은 도메인에서 정규식에 일치하는 모든 사이트를 나열합니다.

reg_exp는 사용되는 정규식입니다.

domain_name은 도메인의 이름입니다.

conf-dir은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

일치하는 모든 사이트를 나열하려면 명령줄에서 다음을 입력합니다.

urldb -o all_matching_sites -e “.*atlas.*” -d server_root/proxy-serverid/config

all_matching_sites는 정규식에 일치하는 모든 사이트를 나열합니다.

reg_exp는 사용되는 정규식입니다.

conf-dir은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

사이트에서 일치하는 URL을 나열하려면 명령줄에서 다음을 입력합니다.

urldb -o matching_urls_from_site -e "http://.*atlas.*" -s atlas.phoenix.com -d server_root/proxy-serverid/config

matching_urls_from_site는 사이트에서 정규식에 일치하는 모든 URL을 나열합니다.

reg_exp는 사용되는 정규식입니다.

site_name은 사이트의 이름입니다.

conf-dir은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

사이트에서 일치하는 URL의 기간을 만료하거나 제거하려면 명령줄에서 다음을 입력합니다.

urldb -o matching_urls_from_site -e "http://.*atlas.*" -s atlas.phoenix.com -x e -d iserver_root/proxy-serverid/config

matching_urls_from_site는 사이트에서 정규식에 일치하는 모든 URL을 나열합니다.

reg_exp는 사용되는 정규식입니다.

site_name은 사이트의 이름입니다.

-x e는 캐시 데이터베이스에서 일치하는 URL의 기간을 만료하기 위한 옵션입니다. 이 옵션은 도메인 및 사이트 모드에서 사용할 수 없습니다.

-x r은 캐시 데이터베이스에서 일치하는 URL을 제거하기 위한 옵션입니다.

conf-dir은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

일치하는 모든 URL을 나열하려면 명령줄에서 다음을 입력합니다.

urldb -o all_matching_urls -e ".*cgi-bin.*" -d server_root/proxy-serverid/config

all_matching_urls는 정규식에 일치하는 모든 URL을 나열합니다.

reg_exp는 사용되는 정규식입니다.

conf-dir은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

일치하는 모든 URL의 기간을 만료하거나 제거하려면 명령줄에서 다음을 입력합니다.

urldb -o all_matching_urls -e ".*cgi-bin.*" -x e -d server_root/proxy-serverid/config

all_matching_urls는 정규식에 일치하는 모든 URL을 나열합니다.

reg_exp는 사용되는 정규식입니다.

-x e는 캐시 데이터베이스에서 일치하는 URL의 기간을 만료하기 위한 옵션입니다.

-x r은 캐시 데이터베이스에서 일치하는 URL을 제거하기 위한 옵션입니다.

conf-dir은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

URL 목록의 기간을 만료하거나 제거하려면 명령줄에서 다음을 입력합니다.

url-list는 기간을 만료해야 하는 URL 목록입니다. 이 옵션은 URL 목록을 제공하는 데 사용할 수 있습니다.

-x e는 캐시 데이터베이스에서 일치하는 URL의 기간을 만료하기 위한 옵션입니다.

-x r은 캐시 데이터베이스에서 일치하는 URL을 제거하기 위한 옵션입니다.

reg_exp는 사용되는 정규식입니다.

conf-dir은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

캐시 가비지 수집 관리

캐시 크기 제한으로 인해 필요한 경우 cachegc 유틸리티를 사용하여 만료되었거나 디렉토리에 캐시하기에는 지나치게 오래된 개체의 데이터베이스 캐시를 비울 수 있습니다.


참고	cachegc 유틸리티를 사용할 때 CacheGC가 프록시 인스턴스에서 실행 중이 아닌지 확인하십시오.

cachegc 유틸리티는 다음과 같은 방법으로 사용할 수 있습니다.

cachegc -f leave-fs-full-percent -u gc-high-margin-percent -l gc-low-margin-percent -e extra-margin-percent -d conf-dir

leave-fs-full-percent는 캐시 파티션 크기의 비율을 지정해 그 이하인 경우 가비지 수집을 실행하지 않습니다.

gc-high-margin-percent 는 최대 캐시 크기의 비율을 조정해 비율에 도달하면 가비지 수집을 실행합니다.

gc-low-margin-percent 는 가비지 수집기가 목표로 하는 최대 캐시 크기의 비율을 조정합니다.

extra-margin-percent 는 가비지 수집기가 제거할 캐시 조각을 결정하는 데 사용됩니다.

conf-dir 은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

일괄 업데이트 관리

bu 유틸리티는 두 가지 모드에서 동작하며 캐시를 업데이트합니다. 첫 번째 모드에서는 캐시 데이터베이스를 반복하여 거치면서 캐시에 있는 모든 URL에 대해 각각 HTTP 요청을 보내 업데이트합니다. 두 번째 모드에서는 지정된 URL로 시작하여 이 URL의 모든 링크에 대해 지정한 깊이까지 너비 우선 반복을 수행하고 페이지를 캐시로 가져옵니다. bu는 RFC 호환 로봇입니다.

bu -n hostname -p port -t time-lmt -f contact-address -s sleep-time -o object -r n -d conf-dir

bu -n phoenix -p 80 -t 3600 -f admin@phoenix.com -s 60 -o nova -r n -d server_root/proxy-serverid/config

hostname은 프록시가 실행 중인 컴퓨터의 호스트 이름입니다. 기본값은 localhost입니다.

port는 프록시 서버가 실행 중인 포트입니다. 기본 포트는 8080입니다.

time-lmt는 유틸리티 실행 제한 시간입니다.

contact-address는 bu가 보낸 HTTP 요청을 통해 전송되는 연락처 주소입니다. 기본값은 worm@proxy-name입니다.

sleep-time은 연속되는 두 요청 사이의 정지 시간입니다. 기본값은 5초입니다.

object는 현재 실행 중인 bu.conf에서 지정된 개체입니다.

-r n 옵션은 robot.txt 정책을 준수할 것인지 여부를 결정합니다. 기본값은 y입니다.

conf-dir 은 프록시 인스턴스의 구성 디렉토리입니다. 경로는 server_root/proxy-serverid/config입니다.

ICP(Internet Cache Protocol) 사용

ICP 정보

ICP(Internet Cache Protocol)는 캐시가 서로 통신할 수 있도록 하는 개체 위치 프로토콜입니다. 캐시는 ICP를 사용하여 캐시된 URL의 존재 및 이러한 URL을 가져올 최적의 위치에 대한 쿼리와 응답을 보낼 수 있습니다. 일반적인 ICP 교환에서 캐시는 이웃한 모든 캐시로 특정 URL에 대한 ICP 쿼리를 전송합니다. 쿼리를 받은 캐시는 해당 URL을 포함하고 있는지 여부에 대한 ICP 응답을 전송합니다. 해당 URL이 없으면 "MISS"를, 있으면 "HIT"를 전송합니다.

ICP 이웃을 통한 라우팅

ICP를 사용하면 서로 다른 관리 도메인에 위치한 프록시들 간에 통신을 할 수 있습니다. ICP는 한 관리 도메인에 있는 프록시 캐시가 다른 관리 도메인에 있는 프록시 캐시와 통신할 수 있도록 합니다. 이는 여러 프록시 서버가 통신을 원하는 상황에서 효과적이지만 하나의 마스터 프록시(프록시 배열에 있는 경우)에서 모두 구성할 수는 없습니다. 그림 12-3은 다른 관리 도메인에 있는 프록시 간의 ICP 교환을 보여 줍니다.

ICP를 통해 서로 통신하는 프록시를 이웃(neighbor)이라고 합니다. ICP 이웃은 최대 64개입니다. ICP 이웃에는 상위(parent)와 동급(sibling), 두 가지 유형이 있습니다. 요청된 URL이 다른 이웃에 없으면 상위 프록시만 원격 서버에 액세스할 수 있습니다. ICP 상위 이웃은 없을 수 있으며, 하나 이상일 수도 있습니다. 상위가 아닌 ICP 이웃은 모두 동급으로 간주됩니다. 동급 프록시는 ICP의 기본 경로로 표시되고, ICP가 이 기본 경로를 사용하는 경우에만 원격 서버에서 문서를 가져올 수 있습니다.

폴링 라운드를 사용하여 쿼리를 받는 이웃의 순서를 결정할 수 있습니다. 폴링 라운드는 ICP 쿼리 주기입니다. 각 이웃에 대해 폴링 라운드를 할당해야 합니다. 모든 이웃을 폴링 라운드 1에 포함되도록 구성하면 한 주기에 모든 이웃이 쿼리를 받게 됩니다. 즉, 동시에 쿼리를 받게 됩니다. 일부 이웃을 폴링 라운드 2에 포함되도록 구성하면 폴링 라운드 1의 모든 이웃이 먼저 쿼리를 받고, 이중 "HIT"를 반환한 이웃이 없으면 폴링 라운드 2의 모든 프록시가 쿼리를 받게 됩니다. 최대 폴링 라운드 수는 2입니다.

ICP 상위 이웃이 네트워크 병목 지점이 될 수 있기 때문에 폴링 라운드를 사용하여 로드를 줄일 수 있습니다. 일반적으로 모든 동급 이웃을 폴링 라운드 1로 구성하고 모든 상위 이웃을 폴링 라운드 2로 구성합니다. 이렇게 하면 로컬 프록시가 URL을 요청한 경우 이 요청은 동급 이웃으로 먼저 전송됩니다. 요청한 URL을 동급 이웃에서 찾지 못하면 이 요청은 상위 이웃으로 이동합니다. 상위 이웃에도 URL이 없는 경우 원격 서버에서 가져옵니다.

ICP 이웃의 각 이웃은 실행 중인 ICP 서버가 적어도 하나 이상 있어야 합니다. 실행 중인 ICP 서버가 없는 이웃은 다른 이웃의 ICP 요청에 응답할 수 없습니다. 프록시 서버에서 ICP를 사용하도록 설정하면 ICP 서버가 시작됩니다(이미 실행 중이 아닌 경우).

ICP를 설정하려면 다음을 수행합니다.

ICP 이웃에 상위 이웃을 추가합니다. (이 단계는 ICP 이웃에 상위 이웃이 있도록 하려는 경우에만 필요합니다.) ICP 이웃에 상위 이웃을 추가하는 방법에 대한 자세한 내용은 ICP 이웃에 상위 이웃 추가를 참조하십시오.

ICP 이웃에 동급 이웃을 추가합니다. ICP 이웃에 동급 이웃을 추가하는 방법에 대한 자세한 내용은 ICP 이웃에 동급 프록시 추가를 참조하십시오.

ICP 이웃의 각 이웃을 구성합니다. ICP 이웃 구성에 대한 자세한 내용은 개별 ICP 이웃 구성을 참조하십시오.

ICP를 사용하도록 설정합니다. ICP 사용 설정에 대한 자세한 내용은 ICP 사용을 참조하십시오.

프록시의 ICP 이웃에 동급 또는 상위 이웃이 있는 경우 ICP 이웃을 통한 라우팅을 사용하도록 설정합니다. ICP 이웃을 통한 라우팅을 사용하도록 설정하는 방법에 대한 자세한 내용은 ICP 이웃을 통한 라우팅 사용을 참조하십시오.

ICP 이웃에 상위 이웃 추가

ICP 이웃에 상위 프록시를 추가하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure ICP 링크를 누릅니다. Configure ICP 페이지가 표시됩니다.

페이지의 Parent List 섹션에서 Add 버튼을 누릅니다. ICP Parent 페이지가 표시됩니다.

Machine Address 필드에 ICP 이웃에 추가할 상위 프록시의 호스트 이름 또는 IP 주소를 입력합니다.

ICP Port 필드에 상위 프록시가 ICP 메시지를 청취할 포트 번호를 입력합니다.

Multicast Address 필드에 상위 프록시가 청취할 멀티캐스트 주소를 입력할 수 있습니다. 멀티캐스트 주소는 여러 서버가 청취할 수 있는 IP 주소입니다. 멀티캐스트 주소를 사용하면 Proxy Server에서 해당 멀티캐스트 주소를 청취하는 모든 이웃이 볼 수 있는 네트워크로 쿼리를 전송할 수 있으므로 각 이웃에 별도로 쿼리를 전송할 필요가 없습니다. 멀티캐스트 사용은 선택 사항입니다.



참고	다른 폴링 라운드가 있는 이웃이 동일한 멀티캐스트 주소를 청취하도록 하면 안 됩니다.

TTL 필드에 멀티캐스트 메시지를 전달할 서브넷의 수를 입력합니다. TTL이 1로 설정되어 있으면 멀티캐스트 메시지는 로컬 서브넷에만 전달됩니다. TTL을 2로 설정하면 메시지는 한 단계 이동한 범위 내의 모든 서브넷으로 전달됩니다. 지정된 숫자에 따라 계속 마찬가지 방법이 적용됩니다.



참고	멀티캐스트를 사용하면 관련되지 않은 두 이웃이 서로 ICP 메시지를 주고 받을 수 있습니다. 따라서 ICP 이웃에 속한 프록시가 전송하는 ICP 메시지를 관련되지 않은 이웃이 받지 않도록 하려면 TTL 값을 낮게 설정해야 합니다.

Proxy Port 필드에 상위 프록시 서버용 포트를 입력합니다.

Polling Round 드롭다운 목록에서 상위 프록시를 포함할 폴링 라운드를 선택합니다. 기본 폴링 라운드는 1입니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

ICP 이웃의 상위 프록시 구성 편집

상위 프록시 구성을 편집하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure ICP 링크를 선택합니다. Configure ICP 페이지가 표시됩니다.

편집하려는 상위 프록시 옆에 있는 라디오 버튼을 누릅니다.

Edit 버튼을 누릅니다.

정보를 적절히 수정합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

ICP 이웃에서 상위 프록시 제거

ICP 이웃에서 상위 프록시를 제거하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure ICP 링크를 선택합니다. Configure ICP 페이지가 표시됩니다.

제거하려는 상위 프록시 옆에 있는 라디오 버튼을 누릅니다.

Delete 버튼을 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

ICP 이웃에 동급 프록시 추가

ICP 이웃에 동급 프록시를 추가하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure ICP 링크를 선택합니다. Configure ICP 페이지가 표시됩니다.

페이지의 Sibling List 섹션에서 Add 버튼을 누릅니다. ICP Sibling 페이지가 표시됩니다.

Machine Address 필드에 ICP 이웃에 추가할 동급 프록시의 호스트 이름 또는 IP 주소를 입력합니다.

Port 필드에 동급 프록시가 ICP 메시지를 청취할 포트 번호를 입력합니다.

Multicast Address 필드에 동급 프록시가 청취할 멀티캐스트 주소를 입력합니다. 멀티캐스트 주소는 여러 서버가 청취할 수 있는 IP 주소입니다. 멀티캐스트 주소를 사용하면 Proxy Server에서 해당 멀티캐스트 주소를 청취하는 모든 이웃이 볼 수 있는 네트워크로 쿼리를 전송할 수 있으므로 각 이웃에 별도로 쿼리를 전송할 필요가 없습니다.



참고	다른 폴링 라운드가 있는 이웃이 동일한 멀티캐스트 주소를 청취하도록 하면 안 됩니다.

TTL 필드에 멀티캐스트 메시지를 전달할 서브넷의 수를 입력합니다. TTL이 1로 설정되어 있으면 멀티캐스트 메시지는 로컬 서브넷에만 전달됩니다. TTL을 2로 설정하면 메시지는 한 단계 이동한 범위 내의 모든 서브넷으로 전달됩니다.



참고	멀티캐스트를 사용하면 관련되지 않은 두 이웃이 서로 ICP 메시지를 주고 받을 수 있습니다. 따라서 ICP 이웃에 속한 프록시가 전송하는 ICP 메시지를 관련되지 않은 이웃이 받지 않도록 하려면 TTL 값을 낮게 설정해야 합니다.

Proxy Port 필드에 동급 프록시 서버용 포트를 입력합니다.

Polling Round 드롭다운 목록에서 동급 프록시를 포함할 폴링 라운드를 선택합니다. 기본 폴링 라운드는 1입니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

ICP 이웃의 동급 프록시 구성 편집

동급 프록시 구성을 편집하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure ICP 링크를 선택합니다. Configure ICP 페이지가 표시됩니다.

편집하려는 동급 프록시 옆에 있는 라디오 버튼을 누릅니다.

Edit 버튼을 누릅니다.

정보를 적절히 수정합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

ICP 이웃에서 동급 프록시 제거

ICP 이웃에서 동급 프록시를 제거하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure ICP 링크를 선택합니다. Configure ICP 페이지가 표시됩니다.

제거하려는 동급 프록시 옆에 있는 라디오 버튼을 누릅니다.

Delete 버튼을 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

개별 ICP 이웃 구성

ICP 이웃 관계에 있는 각 이웃 또는 로컬 프록시를 구성해야 합니다.

ICP 이웃에 있는 로컬 프록시 서버를 구성하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure ICP 링크를 선택합니다. Configure ICP 페이지가 표시됩니다.

Binding Address 필드에 이웃 서버가 바인드할 IP 주소를 입력합니다.

Port 필드에 이웃 서버가 ICP를 청취할 포트 번호를 입력합니다.

Multicast Address 필드에 이웃이 청취할 멀티캐스트 주소를 입력합니다. 멀티캐스트 주소는 여러 서버가 청취할 수 있는 IP 주소입니다. 멀티캐스트 주소를 사용하면 Proxy Server에서 해당 멀티캐스트 주소를 청취하는 모든 이웃이 볼 수 있는 네트워크로 쿼리를 전송할 수 있으므로 각 이웃에 별도로 쿼리를 전송할 필요가 없습니다.

멀티캐스트 주소와 바인드 주소가 모두 지정된 이웃은 응답 전송에는 바인드 주소를, 청취에는 멀티캐스트 주소를 사용합니다. 멀티캐스트 주소와 바인드 주소를 모두 지정하지 않으면 데이터 전송에 사용하는 주소는 운영 체제가 결정하게 됩니다.

Default Route 필드에 "HIT" 응답을 한 이웃 프록시가 없을 때 이웃에서 요청을 라우팅할 프록시의 IP 주소 또는 이름을 입력합니다. 이 필드에 "origin"을 입력하거나 아무것도 입력하지 않으면 기본 경로는 원본 서버가 됩니다.



참고	No Hit Behavior 드롭다운 목록에서 "first responding parent"를 선택하면 Default Route 필드에 입력한 경로는 효력을 잃게 됩니다. No Hit Behavior 기본값을 선택하면 프록시는 이 경로만 사용합니다.

두 번째 Port 필드에는 Default Route 필드에 입력한 기본 경로 컴퓨터의 포트 번호를 입력합니다.

On No Hits, Route Through 드롭다운 목록에서 ICP 이웃에 요청된 URL을 캐시에 저장하고 있는 동급 프록시가 없는 경우 이웃의 동작을 선택합니다. 다음 중 선택할 수 있습니다.

first responding parent. 이웃은 처음 "MISS" 응답을 전송한 상위 프록시를 통하여 요청된 URL을 검색합니다.

default route. 이웃은 Default Route 필드에 지정된 컴퓨터를 통하여 요청된 URL을 검색합니다.

Server Count 필드에 ICP 요청을 서비스할 프로세스의 수를 입력합니다.

Timeout 필드에 이웃이 각 시도에서 ICP 응답을 대기하는 최대 시간을 입력합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

ICP 사용

ICP를 사용하도록 설정하려면 다음을 수행합니다.

Server Manager에 액세스하고 Preferences 탭을 누릅니다.

Configure System Preferences 링크를 누릅니다. Configure System Preferences 페이지가 표시됩니다.

ICP에 대한 Yes 라디오 버튼을 선택합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

ICP 이웃을 통한 라우팅 사용

ICP 이웃을 통한 라우팅을 사용하도록 설정하려면 다음을 수행합니다.

Server Manager에 액세스하고 Routing 탭을 누릅니다.

Set Routing Preferences 링크를 누릅니다. Set Routing Preferences 페이지가 표시됩니다.

드롭다운 목록에서 리소스를 선택하거나 Regular Expression 버튼을 누르고 정규식을 입력한 다음 OK를 누릅니다.

Route Through 텍스트 옆에 있는 라디오 버튼을 선택합니다.

ICP 옆에 있는 확인란을 선택합니다.

클라이언트가 다른 이웃을 거치지 않고 문서를 갖고 있는 ICP 이웃에서 직접 문서를 가져오도록 하려면 Redirect 텍스트 옆에 있는 확인란을 선택합니다.

OK를 누릅니다.



주의	현재 리디렉션을 지원하는 클라이언트는 없으므로 이 기능을 사용하지 마십시오.


참고	프록시의 ICP 이웃에 동급 또는 상위 이웃이 있는 경우에만 ICP 이웃을 통한 라우팅을 사용하도록 설정해야 합니다. 프록시가 다른 프록시의 상위 이웃이면서 동급 이웃이나 상위 이웃이 없는 경우에는 해당 프록시에 대해서만 ICP를 사용하도록 설정해야 합니다. ICP 이웃을 통한 라우팅은 사용하도록 설정할 필요가 없습니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

프록시 배열 사용

프록시 배열 정보

분산 캐시를 위한 프록시 배열을 통해 여러 프록시가 하나의 캐시 역할을 할 수 있습니다 즉, 배열 내의 각 프록시는 브라우저 또는 다운스트림 프록시 서버에서 가져올 수 있는 서로 다른 캐시된 URL을 포함하게 됩니다. 프록시 배열은 프록시 서버가 여러 개인 경우 자주 발생하는 캐시 중복 문제를 방지합니다. 프록시 배열은 해시 기반 라우팅을 통해 프록시 배열에서 올바른 캐시로 요청을 라우팅합니다.

프록시 배열은 또한 증분 확장성을 제공합니다. 즉, 프록시 배열에 다른 프록시를 추가해도 각 구성원의 캐시는 무효화되지 않습니다. 각 구성원의 캐시에서 1/n(n: 배열에 있는 프록시의 수)만큼의 URL만 다른 구성원에게 재할당됩니다.

프록시 배열을 통한 라우팅

프록시 배열을 통과하는 각 요청에 대해 해시 함수는 요청된 URL, 프록시 이름, 프록시의 로드 요인을 기반으로 한 점수를 배열 내의 각 프록시에 할당합니다. 요청은 가장 점수가 높은 프록시로 라우팅됩니다.

URL 요청은 클라이언트와 프록시 모두 할 수 있으므로 프록시 배열을 통한 라우팅에는 두 가지 유형이 있습니다.

클라이언트에서 프록시로의 라우팅인 경우 클라이언트는 PAC(Proxy Auto Configuration) 기법을 사용하여 통과할 프록시를 결정합니다. 그러나 클라이언트는 표준 PAC 파일을 사용하는 대신 특수 PAC 파일로 해시 알고리즘을 계산하여 요청된 URL에 대한 적절한 경로를 결정합니다. 그림 12-4는 클라이언트에서 프록시로의 라우팅을 보여 줍니다.

그림 12-4에서 프록시 배열의 각 구성원은 PAT 파일 업데이트에 대해 마스터 프록시를 로드 및 폴링합니다. PAC 파일을 가진 클라이언트는 구성이 변경된 경우에만 파일을 다시 다운로드하면 됩니다. 일반적으로 클라이언트는 재시작 시 PAC 파일을 다운로드합니다.

프록시 서버는 관리 인터페이스를 통해 만들어진 PAT(Proxy Array Membership Table) 형식에서 자동으로 특수 PAC 파일을 생성할 수 있습니다.

프록시에서 프록시로의 라우팅에서 프록시는 클라이언트에서 사용하는 PAC 파일 대신 PAT(Proxy Array Table) 파일을 사용하여 해시 알고리즘을 계산합니다. PAT 파일은 프록시의 컴퓨터 이름, IP 주소, 포트, 로드 요인, 캐시 크기 등의 프록시 배열에 대한 정보를 포함한 ASCII 파일입니다. 서버에서 해시 알고리즘을 계산하는 데 있어 런타임시 해석해야 하는 JavaScript 파일인 PAC 파일보다 PAT 파일을 사용하는 것이 훨씬 더 효율적입니다. 하지만 대부분의 클라이언트는 PAT 파일 형식을 인식하지 못하므로 PAC 파일을 사용해야 합니다. 그림 12-5는 프록시에서 프록시로의 라우팅을 보여 줍니다.

PAT 파일은 프록시 배열의 마스터 프록시에서 생성됩니다. 프록시 관리자는 마스터 프록시 역할을 할 프록시를 결정해야 합니다. 관리자는 마스터 프록시 서버에서 PAT 파일을 변경할 수 있으며, 해당 프록시 배열의 다른 모든 구성원은 이 변경 사항에 대해 직접 또는 자동으로 마스터 프록시를 폴링할 수 있습니다. 각 구성원이 이러한 변경에서 자동으로 PAC 파일을 생성하도록 구성할 수 있습니다.

또한 계층적 라우팅을 위해 여러 프록시 배열을 체인으로 연결할 수 있습니다. 프록시 서버가 업스트림 프록시 배열을 통해 수신 요청을 라우팅하는 경우 업스트림 프록시 배열은 상위 배열로 간주됩니다. 상위 배열은 프록시 서버가 통과하는 프록시 배열입니다. 즉, 클라이언트가 Proxy X에 문서를 요청하고 Proxy X에 해당 문서가 없는 경우 Proxy X는 이 요청을 원격 서버로 직접 보내는 대신 Proxy Array Y로 전송합니다. 따라서 Proxy Array Y는 상위 배열입니다. 그림 12-5에서 Proxy Array 1은 Proxy Array 2의 상위 배열입니다. Proxy Array 2의 구성원은 상위 배열의 PAT 파일에 대한 업데이트를 로드 및 폴링합니다. 일반적으로 상위 배열의 마스터 프록시를 폴링합니다. 다운로드한 PAT 파일을 사용하여 요청된 URL에 대한 해시 알고리즘이 계산되면 Proxy Array 2의 구성원은 Proxy Array1에서 가장 점수가 높은 프록시에서 요청된 URL을 가져옵니다. 그림 12-5에서 Proxy B는 클라이언트에서 요청한 URL에 대해 가장 높은 점수를 가진 프록시입니다.

프록시 배열을 설정하려면 다음을 수행합니다.

마스터 프록시에서 다음 단계를 수행합니다.

프록시 배열을 만듭니다. 구성원 목록을 만드는 방법에 대한 자세한 내용은 프록시 배열 구성원 목록 만들기를 참조하십시오.

PAT 파일에서 PAC 파일을 생성합니다. PAC 파일은 클라이언트에서 프록시로의 라우팅을 사용하는 경우에만 만들면 됩니다. PAT 파일에서 PAC 파일을 만드는 방법에 대한 자세한 내용은 PAT 파일에서 PAC 파일 생성을 참조하십시오.

배열의 마스터 구성원을 구성합니다. 마스터 구성원 구성에 대한 자세한 내용은 프록시 배열 구성원 구성을 참조하십시오.

프록시 배열을 통한 라우팅을 사용하도록 설정합니다. 프록시 배열을 통한 라우팅을 사용하도록 설정하는 방법에 대한 자세한 내용은 프록시 배열을 통한 라우팅 사용을 참조하십시오.

"/pat" URL을 PAT 파일에 매핑하기 위한 PAT 매핑을 만듭니다.

프록시 배열을 사용하도록 설정합니다. 프록시 배열을 사용하도록 설정하는 방법에 대한 자세한 내용은 프록시 배열 사용을 참조하십시오.

마스터 프록시가 아닌 각 프록시에서 다음 단계를 수행합니다.

배열의 마스터가 아닌 구성원을 구성합니다. 마스터가 아닌 구성원 구성에 대한 자세한 내용은 프록시 배열 구성원 구성을 참조하십시오.

프록시 배열을 사용하도록 설정합니다. 프록시 배열을 사용하도록 설정하는 방법에 대한 자세한 내용은 프록시 배열 사용을 참조하십시오.



참고	프록시 배열이 상위 배열을 통해 라우팅하려면 상위 배열을 사용하도록 설정하고 각 구성원을 원하는 URL에 대해 상위 배열을 통해 라우팅하도록 구성해야 합니다. 상위 배열에 대한 자세한 내용은 상위 배열을 통한 라우팅을 참조하십시오.

프록시 배열 구성원 목록 만들기

배열의 마스터 프록시에서만 프록시 배열 구성원 목록을 작성하고 업데이트해야 합니다. 프록시 배열 구성원 목록은 한 번만 만들면 되며 언제든 수정할 수 있습니다. 프록시 배열 구성원 목록을 만들면 PAT 파일이 생성되어 배열의 모든 프록시와 다운스트림 프록시에 배포됩니다.


주의	배열의 마스터 프록시를 통해서만 프록시 배열 구성원 목록을 변경하거나 구성원을 추가해야 합니다. 배열의 다른 구성원은 구성원 목록을 읽기만 할 수 있습니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure Proxy Array 링크를 누릅니다. Configure Proxy Array 페이지가 표시됩니다.

Array 이름 필드에 배열의 이름을 입력합니다.

Reload Configuration Every 필드에 PAT 파일에 대한 폴링 간격을 분 단위로 입력합니다.

Array Enabled 확인란을 누릅니다.

Create 버튼을 누릅니다.



참고	구성원 목록에 구성원을 추가하기 전에 반드시 OK를 누르십시오.



참고	프록시 배열이 생성되면 Create 버튼이 OK 버튼으로 바뀝니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

프록시 배열의 각 구성원에 대해 다음 사항을 입력한 다음 OK를 누르십시오.

Name. 구성원 목록에 추가하려는 Proxy Server의 이름입니다.

IP Address. 구성원 목록에 추가하려는 Proxy Server의 IP 주소입니다.

Port. 구성원이 PAT 파일을 폴링하는 포트입니다.

Load Factor. 구성원에서 라우팅해야 하는 상대적인 로드를 나타내는 정수 값입니다.

Status. 구성원의 상태를 나타냅니다. 값은 on 또는 off입니다. off로 설정된 프록시 배열 구성원의 요청은 다른 구성원을 통하여 다시 라우팅됩니다



참고	다른 구성원을 추가하기 전에 마스터 구성원을 가장 먼저 추가해야 합니다.



참고	프록시 배열 구성원을 추가할 때 각 구성원의 정보를 입력한 다음 반드시 OK를 누르십시오.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

프록시 배열 구성원 목록 정보 편집

프록시 배열 구성원 목록에 있는 구성원의 정보는 언제든 변경할 수 있습니다. 마스터 프록시에서만 프록시 배열 구성원 목록을 편집할 수 있습니다.

프록시 배열 구성원에 대한 구성원 목록 정보를 편집하려면 다음을 수행합니다.


주의	배열의 마스터 프록시를 통해서만 프록시 배열 구성원 목록을 변경하거나 구성원을 추가해야 합니다. 배열의 다른 구성원에서 목록을 수정하는 경우 변경 사항이 적용되지 않습니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure Proxy Array 링크를 누릅니다. Configure Proxy Array 페이지가 표시됩니다.

Member List에서 편집하려는 구성원 옆에 있는 라디오 버튼을 선택합니다.

Edit 버튼을 누릅니다. Configure Proxy Array Member 페이지가 표시됩니다.

적절한 정보를 편집합니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.



참고	변경 사항을 적용하고 프록시 배열 구성원들에게 배포하려면 Configure Proxy Array 페이지에서 Configuration ID를 업데이트한 다음 OK를 눌러야 합니다. 기존 Configuration ID값에 1을 더하여 입력하면 업데이트됩니다.

프록시 배열 구성원 삭제

프록시 배열에서 프록시 배열 구성원을 삭제합니다. 마스터 프록시에서만 프록시 배열 구성원을 삭제할 수 있습니다.

프록시 배열의 구성원을 삭제하려면 다음을 수행합니다.


주의	배열의 마스터 프록시를 통해서만 프록시 배열 구성원 목록을 변경하거나 구성원을 추가해야 합니다. 배열의 다른 구성원에서 목록을 수정하는 경우 변경 사항이 적용되지 않습니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure Proxy Array 링크를 누릅니다. Configure Proxy Array 페이지가 표시됩니다.

Member List에서 삭제하려는 구성원 옆에 있는 라디오 버튼을 선택합니다.

Delete 버튼을 누릅니다.



참고	변경 사항을 적용하고 프록시 배열 구성원들에게 배포하려면 Configure Proxy Array 페이지에서 Configuration ID를 업데이트한 다음 OK를 눌러야 합니다. 기존 Configuration ID값에 1을 더하여 입력하면 업데이트됩니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

프록시 배열 구성원 구성

프록시 배열의 각 구성원은 한 번만 구성하면 되며, 구성원에서 직접 구성해야 합니다. 배열의 구성원에서 다른 구성원을 구성할 수 없습니다. 또한 마스터 프록시를 구성해야 합니다.

프록시 배열의 각 구성원을 구성하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure Proxy Array Member 링크를 누릅니다. Configure Proxy Array Member 페이지가 표시됩니다.

Proxy Array 섹션에서 적절한 라디오 버튼을 선택하여 구성원이 PAT 파일을 폴링할 것인지 여부를 표시합니다. 다음과 같이 선택할 수 있습니다.

Non-master Member. 구성하고 있는 구성원이 마스터 프록시가 아니면 이 옵션을 선택해야 합니다. 마스터 프록시 외의 프록시 배열 구성원이 마스터 프록시에서 PAT 파일을 가져오려면 PAT 파일을 폴링해야 합니다.

Master Member. 마스터 프록시를 구성하는 경우 이 옵션을 선택해야 합니다. 마스터 프록시를 구성하고 있는 경우에는 PAT 파일이 로컬에 있으므로 따라서 폴링할 필요가 없습니다.

Poll Host 필드에 PAT 파일을 폴링하려는 마스터 프록시의 이름을 입력합니다.

Port 필드에 HTTP 요청을 받을 마스터 프록시의 포트를 입력합니다.

URL 필드에 마스터 프록시에 있는 PAT 파일의 URL을 입력합니다. 예를 들어, 마스터 프록시에서 PAT 파일을 /pat URL에 맵핑하는 PAT 매핑을 만든 경우 URL 필드에 /pat를 입력해야 합니다.

Headers File 필드에는 PAT 파일에 대한 HTTP 요청(예: 인증 정보)과 함께 전송되어야 하는 특수 헤더를 갖고 있는 파일의 전체 경로 이름을 입력합니다. 이 필드는 선택 사항입니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

프록시 배열을 통한 라우팅 사용

프록시 배열을 통한 라우팅을 사용하도록 설정하려면 다음을 수행합니다.

Server Manager에 액세스하고 Routing 탭을 누릅니다.

Set Routing Preferences 링크를 누릅니다. Set Routing Preferences 페이지가 표시됩니다.

드롭다운 목록에서 리소스를 선택하거나 Regular Expression 버튼을 누르고 정규식을 입력한 다음 OK를 누릅니다.

Route Through 옵션을 선택합니다.

프록시 배열 및 상위 배열의 확인란을 선택합니다.

프록시 배열을 통한 라우팅을 선택한 상태에서 요청을 다른 URL로 리디렉션하려면 Redirect 확인란을 선택합니다. 리디렉션이란 프록시 배열의 구성원이 서비스할 수 없는 요청을 받은 경우 이 요청에 대해 연결할 프록시를 클라이언트에게 알려주는 것을 의미합니다.

OK를 누릅니다.



참고	프록시 배열을 통한 라우팅은 현재 구성 중인 프록시 서버가 프록시 배열의 구성원인 경우에만 사용하도록 설정할 수 있습니다. 상위 라우팅은 상위 배열이 있는 경우에만 사용하도록 설정할 수 있습니다. 두 라우팅 옵션은 서로 독립적입니다.



주의	현재 리디릭션을 지원하는 클라이언트는 없으므로 이 기능을 사용하지 마십시오.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

프록시 배열 사용

프록시 배열을 사용 설정하려면 다음을 수행합니다.

Server Manager에 액세스하고 Preferences 탭을 누릅니다.

Configure System Preferences 링크를 누릅니다. Configure System Preferences 페이지가 표시됩니다.

사용 설정하려는 배열 유형 또는 배열(일반 프록시 배열 또는 상위 배열)에 대해 Yes 옵션을 누릅니다.

OK를 누릅니다.



참고	프록시 배열을 통해 라우팅하지 않는 경우 프록시 배열 옵션을 사용하지 않도록 설정하기 전에 모든 클라이언트가 특수 PAC 파일을 사용하여 제대로 라우팅하고 있는지 확인하십시오. 프록시 배열 옵션을 사용하지 않도록 설정한 경우 Set Routing Preferences 페이지에서 명시적 프록시나 직접 연결 등의 유효한 다른 라우팅 옵션을 설정해야 합니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

프록시 배열에서 요청 리디렉션

프록시 배열을 통해 라우팅하도록 선택한 경우 요청을 다른 URL로 리디렉션할 것인지 여부를 지정해야 합니다. 리디렉션이란 프록시 배열의 구성원이 서비스할 수 없는 요청을 받은 경우 이 요청에 대해 연결할 프록시를 클라이언트에게 알려주는 것을 의미합니다.

PAT 파일에서 PAC 파일 생성

대부분의 클라이언트는 PAT 파일 형식을 인식하지 못하므로 클라이언트에서 프록시로의 라우팅에서 클라이언트는 PAC(Proxy Auto Configuration) 기법을 사용하여 통과할 프록시에 대한 정보를 받습니다. 클라이언트는 표준 PAC 파일을 사용하는 대신 PAT 파일에서 파생된 특수 PAC 파일을 사용합니다. 이 특수 PAC 파일은 해시 알고리즘을 계산하여 요청된 URL에 대한 적절한 경로를 결정합니다.

PAT 파일에서 직접 또는 자동으로 PAC 파일을 생성할 수 있습니다. 프록시 배열의 특정 구성원에서 PAC 파일을 직접 생성하는 경우 해당 구성원은 현재 PAT 파일에 있는 정보를 기반으로 즉시 PAC 파일을 재생성합니다. PAC 파일을 자동으로 생성하도록 프록시 배열 구성원을 구성하는 경우 구성원은 PAT 파일의 수정된 버전을 감지할 때마다 자동으로 PAC 파일을 재생성합니다.

PAT 파일에서 PAC 파일 직접 생성

PAT 파일에서 PAC 파일 직접 생성하려면 다음을 수행합니다.


주의	현재 리디렉션을 지원하는 클라이언트는 없으므로 이 기능을 사용하지 마십시오.


참고	프록시 서버에서 프록시 배열 기능을 사용하지 않는 경우 Create / Edit Autoconfiguration File 페이지를 사용하여 PAC 파일을 생성해야 합니다. 자세한 내용은 클라이언트 자동 구성 파일 사용을 참조하십시오.


참고	PAC 파일은 마스터 프록시에서만 생성할 수 있습니다.

마스터 프록시의 Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure Proxy Array 링크를 누릅니다. Configure Proxy Array 페이지가 표시됩니다.

Generate PAC 버튼을 누릅니다. PAC Generation 페이지가 표시됩니다.

PAC 파일에서 사용자 지정 로직을 사용하려면 PAC 파일 생성에 포함할 사용자 지정 로직이 포함된 파일의 이름을 Custom logic file 필드에 입력합니다. 이 로직은 FindProxyForURL 함수의 프록시 배열 선택 로직 앞에 삽입됩니다. 이 함수는 보통 프록시 배열을 통과할 필요가 없는 로컬 요청에 사용됩니다.

Configure Proxy Array Member 페이지에서 사용자 지정 로직 파일을 이미 입력한 경우, 이 필드에 자동으로 입력됩니다. 사용자 지정 로직 파일 이름은 편집할 수 있습니다. 이 경우 변경 사항은 Configure Proxy Array Member 페이지로도 전송됩니다.

Default Route 필드에 배열의 프록시를 사용할 수 없는 경우 클라이언트가 이동해야 하는 경로를 입력합니다.

Configure Proxy Array Member 페이지에서 기본 경로를 이미 입력한 경우 이 필드에 자동으로 입력됩니다. 기본 경로는 편집할 수 있습니다. 이 경우 변경 사항은 Configure Proxy Array Member 페이지로도 전송됩니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

PAT 파일에서 PAC 파일 자동 생성

변경 사항이 감지될 때마다 PAT 파일에서 PAC 파일을 자동으로 생성하려면 다음을 수행합니다.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure Proxy Array Member 링크를 누릅니다. Configure Proxy Array Member 페이지가 표시됩니다.

Auto-generate PAC File 확인란을 선택합니다.

PAC 파일에서 사용자 지정 로직을 사용하려면 PAC 파일 생성에 포함할 사용자 지정 로직이 포함된 파일의 이름을 Custom Logic File 필드에 입력합니다. 이 로직은 FindProxyForURL 함수의 프록시 배열 선택 로직 앞에 삽입됩니다.

Configure Proxy Array 페이지에서 사용자 지정 로직 파일을 이미 입력하고 저장한 경우, 이 필드에 자동으로 입력됩니다. 사용자 지정 로직 파일 이름은 편집할 수 있습니다. 이 경우 변경 사항은 Configure Proxy Array 페이지로도 전송됩니다.

Default Route 필드에 배열의 프록시를 사용할 수 없는 경우 클라이언트가 이동해야 하는 경로를 입력합니다.

Configure Proxy Array 페이지에서 기본 경로를 이미 입력하고 저장한 경우, 이 필드에 자동으로 입력됩니다. 기본 경로는 편집할 수 있습니다. 이 경우 변경 사항은 Configure Proxy Array 페이지로도 전송됩니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

상위 배열을 통한 라우팅

프록시 또는 프록시 배열 구성원이 원격 서버로 직접 이동하지 않고 업스트림 상위 배열을 통해 라우팅하도록 구성할 수 있습니다.

프록시 또는 프록시 배열 구성원이 상위 배열을 통해 라우팅하도록 구성하려면 다음을 수행합니다.

상위 배열을 사용하도록 설정합니다. 배열을 사용하도록 설정하는 방법에 대한 자세한 내용은 프록시 배열 사용을 참조하십시오.

상위 배열을 통한 라우팅을 사용하도록 설정합니다. 배열을 통한 라우팅을 사용하도록 설정하는 방법에 대한 자세한 내용은 프록시 배열을 통한 라우팅 사용을 참조하십시오.

Server Manager에 액세스하고 Caching 탭을 누릅니다.

Configure Proxy Array Member 링크를 누릅니다. Configure Proxy Array Member 페이지가 표시됩니다.

페이지의 Parent Array 섹션에 있는 Poll Host 필드에 PAT 파일을 폴링할 상위 배열에 있는 프록시의 호스트 이름을 입력합니다. 보통 해당 상위 배열의 마스터 프록시입니다.

페이지의 Parent Array 부분에 있는 Port 필드에 PAT 파일을 폴링할 상위 배열에 있는 프록시의 포트 번호를 입력합니다.

URL 필드에 마스터 프록시에 있는 PAT 파일의 URL을 입력합니다. 마스터 프록시에서 PAT 매핑을 만든 경우 이 URL 필드에 매핑을 입력해야 합니다.

양식의 Parent Array 섹션에 있는 Headers File 필드에는 PAT 파일에 대한 HTTP 요청(예: 인증 정보)과 함께 전송되어야 하는 특수 헤더를 갖고 있는 파일의 전체 경로 이름을 입력합니다. 이 필드는 선택 사항입니다.

OK를 누릅니다.

Restart Required를 누릅니다. Apply Changes 페이지가 표시됩니다.

Restart Proxy Server 버튼을 눌러 변경 사항을 적용합니다.

상위 배열 정보 확인

프록시 배열이 상위 배열을 통과하여 라우팅하는 경우, 상위 배열의 구성원에 대한 정보가 있어야 합니다. 이 정보는 상위 배열에서 PAT 파일 형식으로 전송됩니다. PAT 파일에 포함된 정보가 View Parent Array Configuration 페이지에 표시됩니다.

이전 목차 색인 다음
Sun Java System Web Proxy Server 4 .0.1 관리 설명서