[HTTP] 23. 내용 협상과 트랜스 코딩

예를 들어 우리 사이트의 주 고객이 영어 사용자와 프랑스어 사용자 양측이 존재한다면, 우리는 사용자에 맞게 콘텐츠를 제공해줘야 한다. HTTP는 이런 판단이 가능하게 내용협상이란 방법을 제공한다.

이 방법은 하나의 URL이 여러 가지 리소스 중 적합한 것을 제공하도록 할 수 있다. 여기서는 서로 다른 버전을 배리언트( Variant ) 라고 부른다.

17.1 내용 협상 기법

서버가 클라이언트에게 맞는 리소스인지 판단하는 세 가지 방법이 있다. 다음 단에서 클라이언트 주도 기법과 서버 주도 기법에 대해 자세히 설명하고, 여기에는 투명 하나를 간략히 설명한다.

투명

주로 프락시 캐시와 같이 투명한 중간 장치를 거쳐 대신 협상한다. 속도는 위 두 가지의 중간 쯤 되지만, 투명 협상의 경우 어떻게 하는지에 대한 명세가 없다.

17.2 클라이언트 주도 기법

클라이언트가 요청을 보내면 서버는 선택지를 보내주고, 클라이언트가 선택하도록 한다. 서버 입장에서 구현이 쉽고 클라이언트는 최선을 고를 수 있으나 요청의 횟수가 많아 대기 시간이 길다.

첫 요청에서는 여러 가지 버전에 대한 링크와 각각에 대한 설명이 담긴 HTML 페이지를 주거나, 300 Multiple Choices 응답 코드를 돌려준다.

속도가 느리다는 것 외에도 단점이 있는데, 사용자가 어떤 페이지를 북마크해야 하는지가 모호하다. ( 예를 들어, 영어권 사용자와 프랑스어권 사용자는 같은 페이지의 다른 링크를 북마크해야 하나? )

17.3 서버 주도 기법

서버가 클라이언트의 헤더를 검증해서 어떤 버전을 제공할지 판단한다. 더 빠르지만 서버 측에서 결과를 판단하기 어려운 경우에는 추측성으로 대응한다.

처음부터 클라이언트가 자신에 대한 정보를 헤더에 담아 보내면 서버는 추가적인 질문이나 목록을 보여주지 않고도 빠르게 판단할 수 있다. 서버가 사용하는 메커니즘은 두 가지가 있다.

1. 내용 협상 헤더들을 본다. ( 서버는 클라이언트의 Accept 관련 헤더들을 들여다보고 그에 알맞은 응답 헤더를 준비한다. )
2. 내용 협상 헤더 외의 다른 헤더를 본다. ( 예컨대 서버는 클라이언트의 User-Agent 헤더에 기반하여 응답을 보내줄 수 있다. )

17.3.1 내용 협상 헤더

클라이언트가 서버에게 아래의 Accept 헤더들을 보내면

• Accept : 어떤 미디어 타입으로 보내도 되는지를 알려준다.
• Accept-Language : 어떤 언어로 보내도 되는지를 알려준다.
• Accept-Charset : 어떤 차셋으로 보내도 되는지를 알려준다.
• Accept-Encoding : 어떤 인코딩으로 보내도 되는지를 알려준다.

서버는 클라이언트에게 Content 헤더를 보낸다.

• Content-Type
• Content-Language
• Content-Type
• Content-Encoding

HTTP는 상태가 없는 프로토콜이기 때문에 ( === 서버는 클라이언트가 이전에 보낸 정보를 저장하지 않기 때문에 ) 클라이언트는 자신의 선호 정보를 매 요청마다 보내야 한다.

17.3.2 내용 협상 헤더의 품질값

클라이언트는 품질 값을 통해 서버에게 자신의 선호도를 알려줄 수 있다.

예를 들면, Accept-Language: en;q=0.5 fr;q=0.0 nl;q=1.0 tr;q=0.0 으로 나타내면 된다. 이는 네덜란드어로 된 문서를 가장 선호한다는 의미이다.

• 아래 이미지는 postman으로 구글에 네덜란드 어에 대한 선호를 보낸 사진. 로그인이 네덜란드 어로 나와 있는 것을 볼 수 있다. ( 블로그에는 생략 )

17.3.3 그 외 헤더들에 의해 결정

서버는 Accept 헤더가 아니더라도 클라이언트의 다른 요청 헤더들을 이용해 알맞은 요청을 만들려고 시도할 수도 있다.

캐시는 올바른 '최선의' 버전을 제공하기 위해 HTTP 프로토콜에 서버가 응답을 넣어 보낼 수 있는 Vary 헤더를 정의한다. Vary 헤더는 어떤 헤더를 참고하였는지를 말해준다.

17.3.4 아파치의 내용협상 ( 생략 )

17.3.5 서버측 확장 ( 생략 )

17.4 투명 협상

투명 협상은 중개자 프락시를 둠으로써 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 서버에서 제거한다.

프락시는 클라이언트의 기대를 파악하고, 클라이언트와 협상할 수 있는 능력이 있다고 간주되는데, 서버는 프락시에게 Vary 헤더를 통해 어떤 조건을 확인해야 하는지를 알려줄 수 있다.

캐시 프락시가 만일 서버의 의사결정 프로세스를 알게 된다면, 캐시는 서버의 입장에서 협상을 진행할 수도 있다.

17.4.1 캐시와 얼터네이트 ( alternate )

캐시는 클라이언트에게 올바른 응답을 주기 위해 서버가 응답을 돌려줄 때 사용했던 의사결정 로직의 상당부분을 그대로 사용해야 한다.

캐시는 똑같은 리소스에 대하여 다른 버전을 동시에 가질 수 있도록, 이번의 응답과 저번의 응답을 모두 저장한다.

17.4.2 Vary 헤더

제공된 문서가 의존하고 있는 헤더를 포함하여 돌려준다.

캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 한다. 캐시가 검색을 할 때 먼저 내용 협상 헤더로 적합한 콘텐츠를 맞춰보고, 요청의 배리언트를 캐시된 배리언트와 맞춰본다.

맞는 것이 없다면 서버에서 가져온다.

17.5 트랜스코딩

클라이언트의 요청에 맞게 서버가 문서를 제공한다는 것은, 일단 서버가 그 문서를 가지고 있다는 전제 하에 이루어진다. 만약 조건에 맞는 문서가 없다면 어떻게 해야 할까?

서버는 에러를 응답해야겠지만, 이론적으로는 기존의 문서를 클라이언트가 이해할 수 있는 것으로 변환하여 제공할 수 있고, 이를 트랜스코딩이라고 한다.

트랜스코딩의 종류는 세 종류가 있다.

17.5.1 포맷 변환

포맷변환은 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 바꿔주는 것으로, User-Agent 헤더에 의해서 주도되곤 한다.

이는 효율적이고 안전한 전송을 목적으로 하는 것이 아닌, 클라이언트가 해당 기기에서도 문서를 볼 수 있게 해주는 것을 목적으로 한다.

17.5.2 정보 합성

문서에서 요점을 추출하는 것을 정보 합성이라고 하는데, 이는 트랜스 과정에서 유용하다. 간단한 예로 개요 생성이나 광고 및 로고 제거 등을 들 수 있다.

17.5.3 콘텐츠 주입

오히려 웹 문서의 양을 늘리는 트랜스 코딩으로 보통은 광고를 동적으로 삽입하여 콘텐츠를 추가하는 트랜스 코딩이다.

17.5.4 트랜스코딩 vs. 정적으로 미리 생성해놓기

미리 여러 가지 사본을 만들어두는 것은 대안이 되지 못한다. 매우 많은 공간이 필요할 뿐더러 그 페이지들을 관리하고 올바르게 제공해주는 서버를 만들기는 무척이나 어렵다.

또한 광고의 경우, 사용자에 따라 달라지기 때문에 미리 만드는 것이 불가능하다.

그러나 트랜스코딩 역시 대기 시간 증가로 인한 비용을 초래할 수 있다. 따라서 이러한 계산을 위해 프락시나 캐시에 있는 외부 에이전트에 의해 수행되기도 한다.