[HTTP 완벽가이드] 17장 내용 협상과 트랜스 코딩

종종 하나의 URL이 여러 리소스에 대응할 필요가 있는 경우가 있다. 영어 사용자에게는 영어 버전을 프랑스어 사용자에게는 프랑스어 버전을 보내줄 수있다. 클라이언트와 서버가 이런 판단을 할 수 있도록 내용 협상 방법을 제공한다. 

서버는 또한 특정 URL에 대해 어떤 콘텐츠가 클라이언트에게 적절한지 판단 할 수도 있어야 한다. 어떤 경우에는 서버가 커스터마이징된 페이지를 자동으로 생성하기도 한다. 

1. 내용 협상 기법

서버에 있는 페이지 중 어떤 것이 클라이언트에게 맞는지 판단하는 세가지 방법

• 클라이언트에게 선택지 주기
• 서버가 자동으로 판단하기
• 중개자에게 선택하도록 부탁하기

---

2. 클라이언트 주도 협상

서버는 클라이언트에게 선택지를 보내주고 클라이언트가 보고 싶은 것을 선택하는 것 이다. 서버의 입장에선 가장 구현하기 쉽지만, 각 페이지에 두 번의 요청이 필요하기 때문에 속도가 느리다는 단점이 있다. 

 

클라이언트에게 줄 선택지를 표현하는 두가지 방법

• 여러 버전에 대한 링크와 각각에 대한 설명이 담긴 HTML 페이지를 돌려주기
• 300 Multiple Choices 응답 코드로 HTTP/1.1응답을 돌려주기

클라이언트는 응답을 받은후, 링크와 함께 페이지를 보여주거나 사용자가 결정하도록 대화창을 띄울 수 있다. 이 방법은 여러 개의 URL을 요구한다는 단점이 있다. 

'/'로 요청할때 '/english' 와 '/french' 각각을 반환하게되면서 관리의 어려움이 생길 수 있다.

---

3. 서버 주도 협상

서버가 어떤 페이지를 돌려줄 것인지를 결정하게 하는 방법이 있는데, 클라이언트는 반드시 자신의 무엇을 선호하는지에 대한 충분한 정보를 서버에게 주어야 한다.

서버가 클라이언에게 보내줄 응답을 계산하기 위해 사용되는 매커니즘

• 내용 협상 헤더들을 살펴본다. 클라이언트의 Accept 관련 헤더들을 들여다 보고 알맞은 응답을 준비한다.
• 내용 협상 헤더 이외의 헤더를 살펴본. 예를 들어 User-Agent헤더에 기반하여 응답을 보낼 수 있다. 

3.1 내용 협상 헤더

클라이언트는 Accept, Accept-Language, Accept-Charset, Accept-Encoding 등의 헤더를 이용해 자신의 선호 정보를 보낼 수 있다. 내용 협상 헤더는 클라이언트와 서버가 선호 정보를 교환환하고, 문서들의 여러 버전 중 하나를 선택하는 것을 도와 클라이언트의 선호에 가장 잘 맞는 문서를 제공해주기 위한 목적으로 사용된다. 

HTTP는 상태가 없는 프로토콜이기 때문에 클라이언트는 자신의 선호 정보를 반드시 매 요청마다 보내야 한다.

(Accept-Language 헤더를 통해서 보낼 수 있다)

 

3.2 내용 협상 헤더의 품질값

클라이언트가 각 카테고리마다 여러 선택이 가능한 항목을 선호도화 함께 나열할 수 있도록 품질 값을 정의했다.

• Accept-Language: en;q=0.5, fr;q=1.0 ( 프랑스어 문서를 받기를 원하지만, 영어도 가능하다)

q값은 0.0~1.0의 값을 가질 수 있다.

 

3.3 그 외 헤더들에 의해 결정

서버는 User-Agent 같은 헤더로 알맞은 요청을 만들어내려고 시도할 수 있다. 

 

예를 들면 구 서버를 가진 웹브라우저에서 자바스크립트가 지원하지 않는 것을 알고 있을때, JS를 포함하지 않은 페이지를 돌려 줄 수 있다. 이런 사례에서는 q값에 대한 메커니즘이 없다. 즉 서버는 정확한 대응을 찾거나 갖고있는것을 제공해주어야 한다.

캐시는 캐시된 문서의 올바른 버전을 제공해야하기 때문에, HTTP프로토콜은 서버가 응답에 넣어 보낼 수 있는 Vary 헤더를 정의한다.

 

3.4 아파치의 내용 협상

아파지 웹 서버가 내용 협상을 지원하는 방법

• 웹 사이트 디렉터리에서, 배리언트(variant)를 갖는 웹 사이트의 각 URI를 위한 type-map파일을 만든다. 그 type-map파일은 모든 배리언트와 그들 각각에 대응하는 내용 협상 헤더들을 나열한다.
• 아파치가 그 디렉터리에 대해 자동으로 type-map 파일을 생성하도록 하는 MultiViews 지시어를 켠다

 

3.5 서버 측 확장

 서버에서 내용 협상을 구현하는 또 다른 방법에는 마이크로소프트의 엑티브 서버 페이지와 같이 서버 쪽에서 확장을 하는 방법이 있다.

---

4. 투명 협상

투명 협상을 클라이언트 입장에서 협상하는 중개자 프락시를 두어서 클라이언트와의 메시지 교환을 최소화 하고, 서버 주도 협상으로 인한 부하를 제거 하는 방법이다. 여기서 프락시는 기대가 무엇인지 알고 클라이언트입장에서 협상을 수행할 수 있는 능력이 있는 것으로 가정된다.

투명한 내용 협상을 위해서는 서버는 어떤 요청 헤더를 검사해야 하는지 프락시에게 반드시 말해주어야 한다. HTTP/1.1 명세는 투명 협상에 대한 어떤 메커니즘도 정의하지 않았지만, Vary헤더를 정의했다. ( Vary 헤더를 포함시켜 중개자에게 협상을 위해 어떤 헤더를 사용하고 있는지 알려줄 수 있기 때문이다.)

 

캐시 프락시는 단일 URl을 통해 접근 가능한 문서의 여러 사본은 저장할 수 있다. 서버가 캐시에 대한 의사결정 프로세스를 캐시 프락시에게 전달했다면, 캐시는 서버 입장에서 클라이언트와 협상 가능하다. 또한 캐시 안에 설치된 범용 트랜스코더는 특정 서버에 국한되지 않고 어떤 서버의 콘텐츠든 트랜스코딩할 수 있다는 장점이 있다.

 

 

---

5. 트랜스코딩

서버가 클라이언트의 요구에 맞는 문서를 아얘 가지고 있지 않을때, 서버가 기존 문서를 클라이언트가 이해가능한 무언가로 변환할 수 있는데 이 옵션을 트랜스코딩이라고 한다.

 

트랜스 코딩의 종류 

5.1 포맷 변환

데이터를 클라이언트가 볼 수 있도록 한 포멧에서 다른 포멧으로 변환하는 것을 포멧 변환 트랜스코딩이라고 한다.

 

예를 들면 오래된 모바일 단말기가 테스크톱 클라이언트에서 보여져야 할 때, HTML을 WML로 변환 해야할 것이다.

다른 예로는 속도가 느리고 고해상 이미지가 필요없는 클라이언트에서는 속도개선을 위해 이미지를 흑백으로 전환하고 사이즈를 축소해 속도 개선을 꾀할 것이다.

5.2 정보 합성 information synthesis

문서에서 정보의 요점을 추출하는 것을 정보 합성 트랜스코딩이라고 한다.

 

예를 들면 각 절의 제목에 기반한 문서의 개요 생성, 페이지에서 광고 및 로고 제거 등이 있다. 

5.3 내용 주입

위 두가지 트랜스코딩은 웹 문서의 양을 줄이지만, 양을 늘리는 것을 내용 주입 트랜스코딩이라고 한다.

 

예를들면 HTML 페이지에 자동으로 광고를 삽입하는 광고 삽입 트랜스코더, 이런 종류의 트랜스코딩은 현재 관련이 있거나 특정 사용자를 대상으로 하기. ㅐ문에 동적으로 이루어 진다.

 

5.4 트랜스코딩 VS 정적으로 미리 생성

트랜스코딩의 대안은 여러가지 사본을 만드는 것이다. 하지만 이런 방식은 여러 이유로 현실적인 대안이 되지는 못한다.

 

예를 들면 하나는 HTML, 하나는 WML, 하나는 고해상도, 하나는 저해상도,... 이런식으로