17. 내용 협상과 트랜스코딩

• 사용자가 이해하는 언어로 이루어진 홈페이지를 주기 위해 HTTP는 클라와 서버가 이를 판단할 수 있도록 내용 협상을 제공함.

• 이 방법을 이용해 하나의 URL이 여러 가지 리소스 중 적합한 것에 대응되도록 함.

• 각 언어 별로 이루어진 버전을 variant라고 부름.

내용 협상 기법

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

• 클라이언트 주도 협상
• 여러 가지 버전에 대한 링크와 각각에 대한 설명이 담긴 HTML 페이지를 돌려주거나, 300 Multiple Choices 응답 코드로 HTTP/1.1 응답을 돌려주는 것임.
• 첫번째 메서드의 결과로, 클라이언트 브라우저는 이러한 응답을 받아 링크와 함께 페이지를 보여주거나 혹은 사용자가 결정을 하도록 하기 위해 대화창을 띄울 것임.
• 이 경우, 결정은 브라우저 사용자에 의해 수동으로 클라이언트 쪽에서 행해지기 때문에 증가된 대기시간과 페이지당 여러 번이 필요하다는 단점이 있음.

• 서버 주도 협상
• 클라 주도 협상의 단점을 보완할 수 있으나 클라는 반드시 자신의 무엇을 선호하는지에 대한 충분한 정보를 서버에게 주어서 서버가 현명한 결정을 할 수 있게 해 주어야 함.
• HTTP 서버가 클라에게 보내줄 적절한 응답을 계산하기 위해 사용하는 메커니즘은 다음의 2가지임.
• 내용 협상 헤더들을 살펴봄. 서버는 클라의 Accept 관련 헤더들을 보고 그에 맞는 응답 헤더를 준비함.



• 어떤 두 클라이언트가 자신이 이해할 수 없는 언어를 지정한 Accept-Language 헤더 정보를 보낸다면, 서버는 www.joes-hardware.com 의 어떤 사본을 각 클라이언트에게 돌려줘야 할 지 판단할 수 있을 것임.
• HTTP 프로토콜은 클라이언트가 각 선호의 카테고리마다 여러 선택 가능한 항목을 선호도와 함께 나열할 수 있도록 품질값을 정의함. ex) Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0
• 내용 협상 헤더 외의 다른 헤더들을 살펴봄. 예를 들어, 서버는 클라의 User-Agent 헤더에 기반하여 응답을 보내줌.
• 서버는 또한 User-Agent와 같은 클라이언트의 다른 요청 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있음. ex) 캐시, 아파치

• 투명 협상
• 투명 협상은 클라이언트 입장에서 협상하는 중개자 프락시를 둠으로써 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 서버에서 제거함.
• 캐시 프락시는 단일한 URL을 통해 접근할 수 있는 문서의 여러 다른 사본을 저장할 수 있음. 만약 서버가 그들의 캐시에 대한 의사결정 프로세스를 캐시에게 알려 주었다면, 캐시는 서버의 입장에서 클라이언트와 협상할 수 있음.
• 캐시는 올바른 응답을 클라이언트에게 돌려주기 위해 내용 협상 헤더를 사용함.
• 서버가 특정 요청 헤더에 따라 다르게 응답한다면, 캐시된 응답을 돌려보내기 전에 캐시는 반드시 일반적인 내용 협상 헤더들 뿐 아니라 이들 요청 헤더들도 맞춰보아야 함.
• 캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 함. 캐시가 검색을 할 때, 먼저 내용 협상 헤더로 적절한 콘텐츠를 맞춰보고, 다음에 요청의 배리언트를 캐시된 배리언트와 맞춰봄.

트랜스코딩

• 트랜스코딩에는 포맷 변환, 정보 합성, 내용 주입의 세 종류가 있음.
• 포맷 변환
• 데이터를 클라이언트가 다른 환경에서도 볼수 있도록 포맷 변환 시켜주는 것.
• 전송 인코딩과는 다름. 트랜스코딩의 포맷 변환은 콘텐츠를 특정 접근 장치에서 볼 수 있도록 하기 위한 것이고, 전송 인코딩은 콘텐츠의 더 효율적인, 안전한 전송을 위한 것임.
• 정보 합성
• 문서에서 정보의 요점을 추출함.
• 보통 포털 사이트의 웹페이지 디렉터리와 같은 자동화된 웹페이지 분류 시스템에 의해 종종 사용됨.
• 콘텐츠 주입
• 위 2개의 트랜스코딩은 웹 문서의 양을 줄이지만, 내용 주입은 오히려 양을 늘림.
• 지나가는 HTML 페이지에 자동으로 광고 삽입이나 특정 사용자를 대상으로 하는 광고를 그때 그때 효과적으로 삽입하기 위해 동적으로 이루어짐.

• 트랜스코딩 vs 정적으로 미리 생성해 놓기
• 트랜스코딩의 대안은 웹서버에 여러가지 사본을 만드는 것임.
• 근데 이 방식은 페이지에 대한 어떠한 작은 변화도 여러 페이지의 수정을 요구하고각 페이지의 모든 버전을 저장하기 위해 많은 공간이 필요함.
• 광고 삽입과 같은 몇몇 트랜스 코딩은 정적인 방법으로는 수행할 수 없는데, 이는 페이지를 요청한 사용자에게 달려 있기 때문.
• 그러나 이는 콘텐츠 제공루트 페이지를 필요할 때마다 변환하는 것은 정적으로 미리 생성해 놓는 것보다 쉬운 해결책이지만 콘텐츠 제공에 있어 대기시간 증가로인한 비용을 초래할 수 있음.
• 그래서 변환은 더 싼 프락시나 캐시에 있는 외부 에이전트에 의해 수행될 경우가 많음.

다음 단계

• 내용 협상은 성능 제약과 유일한 프로토콜이 아니라는 점에서 해결되지 않은 점이 많음.
• 성능 제약.
• 간소화할 수 없을까?
• 유일한 프로토콜이 아님.
• 미디어 스트리밍, 팩스 등의 경우에 고민이 필요함.
• 일반적인 내용 협상 프로토콜이 TCP/IP 응용 프로토콜 위에서 만들어질 수 있을까?