가상호스트는 보통 원본(Domain 또는 IP목록)과 1:1로 구성되는 것이 기본이다.
하지만 상황에 따라 대표 가상호스트를 여러 하위 가상호스트로 분기하거나,
반대로 독립적인 여러 가상호스트를 하나의 서비스로 포장해야 하는 경우도 발생한다.
각 기능에 따라 클라이언트 통계 / Access 로그 의 정책이 다를 수 있음을 유의해야 한다.
실서비스에서는 다양한 방식으로 HTTP 요청을 라우팅하는 경우가 발생한다.
각 모듈이 동작하는 시점을 명확히 이해해야 안정적인 운영이 가능하다.
먼저 간단한 HTTP 요청부터 시작하자.
http://foo.com/
이 요청은 아래 그림과 같은 흐름으로 처리된다.
HTTP트랜잭션 은 HTTP 요청을 어플리케이션이 처리하는 단위이다.
따라서 가상호스트에 진입하면서 시작되고, 떠나면서 종료된다.
참고
흔히 HTTP 트랜잭션의 시작을 HTTP Layer로 생각하는데 이는 잘못된 이해이다.
HTTP Layer의 책임은 HTTP 프로토콜 구현(Parsing & Reponse)에 한정된다.
파싱된 HTTP 요청이 가상호스트 [foo.com] 로 분기되어야 비로소 HTTP트랜잭션 이 시작되는 것이다.
URL 전처리 는 HTTPLayer 와 가상호스트 [foo.com] 사이에 위치한다.
URL 전처리 를 이용하면 [foo.com] 의 요청을 [bar.com] 으로 분기시킬 수 있다.
URL 전처리 는 HTTP트랜잭션 에 영향을 주지 않는다.
[bar.com] 으로 요청이 진입할 때 HTTP트랜잭션 이 시작된다.
[foo.com] 에는 아무런 액션도 발생하지 않는다.
Facade 가상호스트 는 통계와 로그를 분리하기 위해 사용한다.
[foo.com] 이 [bar.com] 의 facade라면 다음과 같이 동작한다.
그림에서 알 수 있듯이 HTTP트랜잭션 이 2개의 가상호스트에서 발생한다.
이렇게 중첩된 경우 상위 HTTP트랜잭션 이 모든 책임을 위임받는다.
따라서 손쉽게 통계와 로그의 분리가 가능하다.
만약 URL Rewriter에 의해 접근하려는 Host이름이 변경되었다면 클라이언트 HTTP요청의 Host헤더가 변경된 것으로 간주한다.
URL 전처리는 가상호스트 설정(vhosts.xml)에 설정한다.
대부분의 설정이 가상호스트에 종속되지만, URL전처리의 경우 클라이언트가 요청한 Host의 이름을 변경할 수 있으므로 가상호스트와 같은 레벨로 설정한다.
URL전처리를 설정한다.
AccessLog(기본:Replace) 속성은 Access로그에 기록될 URL을 설정한다.
Replace 인 경우 변환 후 URL(/logo.jpg)을, Pattern 인 경우 변환 전
URL(/baseball/logo.jpg)을 Access로그에 기록한다.
<Pattern> 매칭시킬 패턴을 설정한다.
한개의 패턴은 ( ) 괄호를 사용하여 표현된다.
<Replace> 변환형식을 설정한다.
일치된 패턴에 대해서는 #1, #2와 같이 사용할 수 있다. #0는 요청 URL전체를 의미한다.
패턴은 최대 9개(#9)까지 지정할 수 있다.
위와 같이 구성하면 foo.com 과 bar.com 은 같은 URL에 대해서는 캐싱 객체를 공유한다.
다시 말해 foo.com 에 의해 캐싱된 객체는 bar.com 으로 접근해도 재캐싱하지 않고 TCP_HIT 로 서비스 된다.
bar.com 에 의해 먼저 캐싱된 객체도 동일하게 동작한다.
share 모드에는 가상호스트 이름이 캐싱키로 붙는다.
따라서 아래와 같이 선언만 하는 것으로는 아무 것도 공유되지 않는다.
클라이언트 요청이 다른 가상호스트로 위임되더라도 클라이언트 통계 와 Access 로그 는 클라이언트가 접근한 가상호스트에 기록된다.
참고
링크 관계에 있는 가상호스트 설정이 다를 경우 의도치 않게 동작할 수 있음을 주의한다.
가상호스트 링크가 A(단순 캐싱) -> B(이미지 압축)로 맺어져 있다면,
A에서 처리된 이미지는 압축되지 않지만 B에서 처리된 이미지는 압축된다.
예를 들어 nas.com의 콘텐츠를 cloud.com으로 이전 중일 경우, cloud.com에 없는(=404 Not Found) 콘텐츠에 대해서만 nas.com으로 요청을 보낼 수 있다.
아래의 경우 요청이 nas.com에 의해 처리되더라도 클라이언트 통계 와 Access 로그 는 cloud.com에 기록된다.
Access 로그 의 vhostlink 필드를 통해 클라이언트 요청이 어느 가상호스트에서 처리되었는지 알 수 있다.
“-” 는 요청이 링크되지 않았음을 의미하며 “nas.com” 은 해당 요청이 링크되어 nas.com에서 처리되었음을 의미한다.
#Fields: date time s-ip cs-method cs-uri-stem ...(중략)... vhostlink2016.11.2416:52:24220.134.10.5GET/web/h.gif...(중략)...-2016.11.2416:52:26220.134.10.5GET/favicon.ico...(중략)...nas.com
링크가 여러 번 발생했다면 “+”를 구분자로 링크된 모든 가상호스트가 명시된다.
이 경우 가장 마지막에 위치한 가상호스트가 최종 요청을 처리한 가상호스트이다.
#Fields: date time s-ip cs-method cs-uri-stem ...(중략)... vhostlink2016.11.2416:52:24220.134.10.5GET/test.jpg...(중략)...bar.com+helloworld.com+example.com
다음의 경우 링크는 즉시 중단된다.
대상 가상호스트가 존재하지 않는 경우 (foo.com -> ?)
자기 자신을 대상 가상호스트로 지정한 경우 (foo.com -> foo.com)
재귀링크(Recursive Link)가 발생한 경우 (foo.com -> bar.com -> foo.com)