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

17.1 내용 협상 기법

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

• 클라이언트 주도 협상
• 서버 주도 협상
• 투명 협상

 

17.2 클라이언트 주도 협상

클라이언트가 요청을 보냄 > 서버가 가능한 페이지의 목록을 응답으로 돌려줌 > 클라이언트가 선택하는 방식

서버 입장에서 가장 구현하기 쉽지만 각 페이지에 두 번의 요청이 필요해서 대기시간이 늘어나게 된다. 서버가 클라이언트에게 선택지를 주는 방식은 두 가지가 있다.

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

서버 응답을 받은 후에는 링크와 함께 페이지를 보여주거나 사용자가 결정을 할 수 있도록 창을 띄울 수도 있다.

클라이언트 주도 협상은 긴 대기시간 뿐만 아니라 여러 개의 URL을 요구한다는 단점을 가지고 있다. '/' 경로의 주 페이지 뿐만 아니라 '/english', '/french'의 주소를 각각 요구하기 때문에, 특정 언어에서 다른 언어로의 공유를 할 때나 관리의 관점에서 어려움이 발생할 수 있다.

 

17.3 서버 주도 협상

클라이언트의 요청 헤더 > 서버가 어떤 페이지를 돌려줄 것인지를 결정하여 전달하는 방식

• 내용 협상 헤더들을 살펴보고 클라이언트의 Accept 관련 헤더들을 통해 그에 맞는 응답 헤더를 준비한다.
• 내용 협상 외의 헤더들을 살펴본다. 예를 들어, User-Agent 헤더에 기반하여 응답을 보낸다.

내용 협상 헤더

Accept, Accpet-Language, ... 등 Accept로 시작하는 헤더들이 있다. 엔터티 헤더들과 비슷한 형태를 띄지만, 엔터티 헤더는 메시지를 서버에서 클라이언트로 전송할 때 필요한 메시지 본문 속성을 가리킨다면, 내용 협상 헤더들은 클라이언트와 서버가 선호 정보를 서로 교환하고 문서의 여러 버전 중 하나를 선택하는 것을 도와 클라이언트의 선호에 가장 맞는 문서를 제공하기 위한 목적으로 사용된다.

HTTP는 Stateless 프로토콜이기 때문에 클라이언트는 선호 정보를 매 요청마다 보내야 한다. 클라이언트가 선호 언어를 Accept-Languge에 담아 보낸다면, 서버는 어떤 사본을 클라이언트에게 전달해야 하는지를 판단하여 커뮤니케이션 대기시간을 줄일 수 있다.

 

하지만 만약 가지고 있는 버전과 다른 언어를 선호하는 사람이 있다고 가정하면, 가지고 있는 버전 중 어떤 것을 더 선호하는 지에 대한 정보가 필요할 것이다. 이를 위해 품질값(q)를 통해 선호도를 나타낼 수 있다. 품질값은 0.0이 가장 낮은 선호도, 1.0이 가장 높은 선호도를 의미한다.

# 네덜란드어(nl)로 된 문서를 받기 원하지만 영어(en)로 된 문서라도 받아들일 것임
# 프랑스어(fr)와 터키어(tr) 버전을 원하지 않음
Accpet-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0

만약 선호에 대응하는 문서를 하나도 갖고 있지 않을 경우에는 클라이언트의 선호에 맞추기 위해 문서를 고치거나 트랜스코딩을 할 수 있다.

그 외의 헤더

User-Agent와 같은 클라이언트의 다른 요청 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있다. 하지만 q값 메커니즘은 없기 때문에 서버는 정확한 대응을 찾아내거나 갖고 있는 것을 제공해주어야 한다. Vary 헤더는 서버가 내줄 응답의 최선의 버전을 결정하기 위해 어떤 요청 헤더를 참고하고 있는지 말해준다.

 

17.4 투명 협상

중개자 프락시를 통해 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 제거하는 방식

서버는 클라이언트의 요청에 가장 잘 맞는 것이 무엇인지 판별하기 위해 어떤 요청 헤더를 검사해야 하는지 프락시에게 말해줘야 한다. 서버는 응답에 Vary 헤더를 포함하여 중개자에게 어떤 헤더를 통해 내용 협상을 하는지 알려줄 수 있다.

캐시 프락시는 단일한 URL을 통해 접근할 수 있는 문서의 여러 사본을 저장할 수 있기 때문에 서버가 캐시에 대한 의사결정 프로세스를 알려주었다면 서버의 입장에서 클라이언트와 협상이 가능하다.

캐시와 얼터네이트

콘텐츠를 캐시하는 것은 재사용을 예상하기 때문이다. 올바른 캐시 응답을 돌려주기 위해 서버가 응답을 돌려줄 때 사용했던 의사결정 로직의 상당 부분을 그대로 사용해야 한다. 캐시는 캐시 응답을 보낼 때 최적의 통신을 위해 사용되는 헤더들과 같은 헤더를 사용해야 한다. 때문에 같은 URL에 대해 여러 버전의 문서를 갖게 되는데 이를 배리언트 혹은 얼터네이트라고 부른다.

Vary 헤더

서버의 판단이 Accept 등의 헤더 이외에 다른 헤더에 기초한다면 Vary 응답 헤더를 통해 서버가 문서를 선택하거나 커스텀 콘텐츠를 생성할 때 고려한 클라이언트 요청 헤더를 모두 나열해야 한다. 그리고 캐시는 캐시된 응답 안에 서버가 보낸 Vary 헤더가 들어있는지 확인하고 값을 비교해야 한다. 그리고 각 배리언트마다 알맞은 문서 버전을 저장하고 다음 요청의 배리언트를 캐시된 배리언트와 비교하여 응답을 한다.

 

17.5 트랜스코딩

서버가 클라이언트의 요구에 맞는 문서를 아예 갖고 있지 않다면 서버는 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환하는 트랜스코딩을 진행할 수 있다.

• 포맷 변환 : 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것. 포맷 변환은 내용 협상 헤더에 의해 주도된다.
• 정보 합성 : 문서에서 정보의 요점을 추출하는 것
• 내용 주입 : 포맷 변환과 정보 합성은 일반적으로 웹 문서의 양을 줄이지만 주입 트랜스코딩은 문서의 양을 오히려 늘리기도 한다. 자동 광고 생성과 사용자 추적 시스템이 있다.

트랜스코딩의 대안은 웹 서버에서 웹페이지의 여러 가지 사본을 만드는 것이다. 예를 들어 HTML/WML, 고해상도 이미지/저해상도 이미지, 멀티미디어 콘텐츠 유/무가 있다. 하지만 모든 버전을 저장하기 위해 더 많은 공간이 필요하게 되고 이것들을 관리하고 올바른 것을 골라 제공하는 웹 서버를 만들기 어렵다. 때문에 루트 페이지를 그때그때 변환하는 것이 더 쉬운 해결책이며, 대신 이것은 대기시간을 증가시킬 수 있기 때문에 제삼자에게 수행하게 하여 웹 서버의 부담을 덜 수 있다.