내용 협상과 트랜스코딩

이 글은 HTTP 완벽가이드 17장을 참고해 정리한 포스팅입니다.

시작하기에 앞서

• 종종 하나의 URL이 여러 리소스에 대응할 필요가 있는 경우가 있습니다.
  • ex) http://www.ideveloper2.dev 을 요청했을때 서버는 어떤 언어를 제공해줘야 하는가? 영어 or 한국어
• HTTP는 클라이언트와 서버가 어떤 내용을 제공해줘야 하는지에 대한 판단을 할 수 있도록 내용 협상(content-negotiation) 방법을 제공합니다.
  • ex) 같은 페이지에 대한 영어버전 or 한국어버전
  • 여기서 서로 다른 버전을 variant 라고 합니다.
• 서버는 또한 특정 URL에 대해 어떤 콘텐츠가 클라이언트에게 보내주기 가장 적절한지에 대한 다른 판단도 할 수 있어야 합니다.

내용 협상 기법

• 서버에 있는 페이지들 중 어떤 것이 클라이언트에게 맞는지 판단하는 세가지 다른 방법이 있습니다.
  • 클라이언트 주도 협상
  • 서버 주도 협상
  • 투명 협상

클라이언트 주도 협상

• 서버가 클라이언트의 요청을 받았을때 가능한 페이지의 목록을 응답으로 돌려주어 클라이언트가 보고 싶은 것을 선택하게 하는 것입니다.
• 서버입장에서 가장 구현하기 쉽습니다.
• 한번은 목록을 얻고, 두번째는 선택한 사본을 얻는 두번의 요청이 필요합니다.
• 클라이언트에게 줄 선택지를 표현하는 두가지 방법이 있습니다.
  • 여러가지 버전에 대한 링크와 각각에 대한 설명이 담긴 HTML 페이지를 돌려주는 방법
  • 300 Multiple Choices 응답코드로 HTTP/1.1 응답을 돌려주는 방법

추가 정보

• 300 Multiple Choices 에 대한 참고 링크
  • https://evertpot.com/http/300-multiple-choices

서버 주도 협상

• 위에서 말한 클라이언트 주도 협상은 최적의 페이지를 결정하기 위한 클라이언트와 서버 사이의 커뮤니케이션을 증가시킵니다.
• 이러한 추가 커뮤니케이션을 줄이기 위한 한가지 방법은 서버가 어떤 페이지를 돌려줄 것인지 결정하게 하는 것이고, 이 때 클라이언트는 반드시 자신이 무엇을 선호하는지에 대한 충분한 정보를 서버에게 전달해야만 합니다.
• 위에서 말한 이러한 정보는 클라이언트의 요청헤더에서 얻게 되는데, 서버가 클라이언트에게 보내줄 적절한 응답을 계산하기 위해 사용하는 메커니즘은 다음 두가지 입니다.
  • 내용 협상 헤더들을 살펴봅니다. Accept 관련 헤더들을 들여다보고 그에 알맞은 응답헤더를 준비합니다.
  • 내용 협상 이외의 헤더들을 살펴봅니다. 예를 들어, User-Agent에 기반하여 응답을 보내 줄수도 있습니다.

내용 협상 헤더

• 위의 헤더들은 엔터티 헤더들과 비슷합니다. 그러나 서로 분명한 차이가 있는데요.
  • 엔터티 헤더는 선적 화물에 붙이는 라벨과 비슷하며, 메시지를 서버에서 클라이언트로 전송할 때 필요한 메시지 본문의 속성을 가리키게 됩니다.
  • 내용 협상 헤더 들은 클라이언트와 서버가 선호 정보를 서로 교환하고 문서들의 여러 버전 중 하나를 선택하는 것을 도와, 클라이언트의 선호에 가장 잘 맞는 문서를 제공해 주기위한 목적으로 사용됩니다.

내용 협상 헤더의 품질값

• 사용자에게 보내줄 내용이 모호할때는 선호에 대한 품질값 (q값) 을 이용해 전달할 수 있는 메커니즘을 제공하게 됩니다.
  • q값은 0.0 부터 1.0까지의 값을 가지게 됩니다.
  • 아래 예 값은 경우는 nl(네덜란드어)로 되어있는 문서를 받기를 원하고 있으나, 영어로 된 문서라도 받아 들일것임을 의미하고 있습니다.
• 또한, 서버는 클라이언트의 선호에 대응하는 문서를 하나도 갖고 있지 않을 수도 있는데요, 이경우 서버는 클라이언트의 선호에 맞추기 위해 문서를 고치거나 트랜스코딩 할수 있습니다.

Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0

그외의 헤더들에 의해 결정

• 서버는 또한 User-Agent와 같은 클라이언트의 다른 요청 헤더들을 이용해 알맞은 요청을 만들어 내려고 시도 할 수 있습니다.

투명 협상

• 투명협상은 클라이언트 입장에서 협상하는 중개자 프락시를 둠으로써 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 서버에서 제거합니다.
• HTTP/1.1 명세는 투명 협상에 대한 어떤 메커니즘도 정의하지 않았지만, 대신 vary 헤더를 정의했습니다. 서버는 응답에 vary 헤더를 포함시켜 보냄으로써 중개자에게 내용 협상을 위해 어떤 헤더를 사용하고 있는지 알려 줄 수 있습니다.

캐시와 alternate

• 캐시는 올바른 응답을 클라이언트에게 돌려주기 위해 내용 협상 헤더를 사용하게 됩니다.
• 아래 예제에서 볼 수 있듯, 캐시는 잘못된 응답을 보내줄수 있기 때문에 모든 응답들에 대해 서버에게 그대로 전달하고 그 URL에 대한 이번 응답과 지난번의 응답 모두를 저장해야만 합니다.
  • 아래에서 같은 URL에 대해 두개의 다른 문서를 갖게 되는데, 다른 버전은 variant나 alternate로 불리게 됩니다.

Vary 헤더

• HTTP Vary 응답헤더는 서버가 문서를 선택하거나 커스텀 콘텐츠를 생성할때 고려하 클라이언트 요청헤더 모두를 나열합니다.
  • ex) 제공된 문서가 User-Agent 헤더에 의존한다면, Vary헤더는 반드시 User-Agent를 포합해야 합니다.
• 캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야합니다. 캐시가 검색을 할 때, 먼저 내용협상헤더로 적합한 콘텐츠를 맞춰보고, 다음에 요청의 배리언트를 캐시된 베리언트와 맞춰봅니다. 만약 맞는 것이 없으면, 캐시는 문서를 서버에서 가져오게 됩니다.
• 서버가 특정 요청 헤더에 따라 다르게 응답한다면, 캐시된 응답을 돌려보내기 전에 캐시는 반드시 일반적인 내용 협상 헤더들 뿐 아니라 이들 요청 헤더들도 맞춰보아야 합니다.

트랜스코딩

• 서버가 클라이언트의 요구에 맞는 문서를 아예 갖고 있지 않다면 서버는 기존의 문서를 클라이언트가 사용할수 있는 무언가로 변환할수도 있는데, 이를 트랜스코딩 이라 부르게 됩니다.
• 트랜스코딩에는 아래와 같은 세가지 종류가 있습니다.
  • 포맷 변환
  • 정보 합성
  • 내용 주입

포맷 변환

• 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것입니다.
• 포맷 변환은 내용협상 헤더에 의해 주도됩니다.
• 예
  • HTML문서를 WML 문서로 변환
  • 고해상도 이미지를 저해상도 이미지로 변환

정보 합성

• 문서에서 정보의 요점을 추출하는 것을 정보 합성이라고 합니다.
• 예
  • 각 절의 제목에 기반한 문서의 개요 생성이나 페이지에서 광고 및 로고 제거

콘텐츠 주입

• 양을 늘리는 또 다른 종류의 변환인 내용 주입 트랜스코딩이라는 것도 있습니다.
• 예
  • 자동 광고 생성
  • 사용자 추적 시스템

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

• 트랜스코딩의 대안은 웹서버에 여러 가지 사본을 만드는 것입니다.
  • 그러나 이 방식은 페이지에 대한 어떠한 작은 변화도 여러 페이지의 수정을 요하게 되고, 각 페이지의 모든 버전을 저장하기 위해 많은 공간이 필요하게 됩니다.
  • 광고 삽입과 같은 몇몇 트랜스 코딩은 정적인 방법으로는 수행할수 없는데, 이는 페이지를 요청한 사용자에게 달려 있기 때문입니다.