17. Content Negotiation and Transcoding

• 내용협상(content-negotiation)을 이용해서 하나의 URL이 여러 리소스 중 적합한 것에 대응되도록 한다.

• 예: 같은 웹페이지의 프랑스어와 영어 버전. (서로 다른 버전을 variant라고 부른다.)

• 트랜스코딩은 HTTP 클라이언트와 서버 사이의 내용협상에 대한 응답에서 수행된다.

1) 내용 협상 기법

01

서버에 있는 페이지들 중 어떤 것이 클라이언트에게 맞는지 판단하기 위한 3가지 다른 방법

• 클라이언트 주도 협상: 클라이언트에 선택지를 주기

• 서버 주도 협상: 서버가 자동으로 판단하기

• 투명한 협상: 중개자에게 선택하도록 부탁하기

2) 클라이언트 주도 협상

02

• 기술적으로 서버에게는 클라이언트에게 줄 선택지를 표현하는 2가지 방법이 있다.

  • 여러가지 버전에 대한 링크와, 각각에 대한 설명이 담긴 HTML 페이지를 돌려주기.

  • 300 Multiple Choices 응답코드로 HTTP/1.1 응답을 돌려주기.

• 첫번째 요청(메서드)에 대한 결과로 클라이언트(브라우저)는 이러한 응답을 받아 링크와 함께 페이지를 보여주거나, 사용자가 결정하도록 하기위한 대화창을 띄운다. 결정은 브라우저 사용자에 의해 수동으로 클라이언트 쪽에서 행해진다.

• 단점

  • 표에 적은 단점들 이외에도 여러개의 URL을 요청한다는 단점이 있다.

  • 예를 들어 https://github.com/minhee0327 을 요청하면,

    • https://github.com/minhee0327/korea

    • https://github.com/minhee0327/english

    • 위와 같이 여러 링크를 담은 페이지를 반환하게 된다.

  • 그럼 어떤 링크를 주 페이지(메인 링크)라고 생각할 수 있을까? (공유하거나, 북마크하거나..등등 경우에)

3) 서버 주도 협상

03

• 클라이언트 주도 협상은 응답으로 돌려줄 최적의 페이지를 결정하기 위해 커뮤니케이션을 증가시킨다.

• 이런 추가 커뮤니케이션을 줄이기위한 한가지 방법은, 서버가 어떤 페이지를 돌려줄지 결정하는 것이다.

• 대신, 클라이언트는 반드시 선호하는 정보를 충분히 주어 서버가 현명한 결정을 하도록 해야한다.

• 서버는 이 정보를 클라이언트의 요청 헤더에서 얻는다.

• HTTP 서버가 클라이언트에 보내줄 적절한 응답을 계산하기위해 사용하는 매커니즘

  ① 내용 협상 헤더:

  • 서버는 클라이언트의 Accept 관련 헤더를 보고 그에 알맞은 응답헤더를 준비한다.

  • 엔터티 헤더와 비슷하나, 엔터티헤더는 메시지 본문의 속성을 가리키고,

    내용 협상 헤더들은 클라이언트와 서버가 선호 정보를 서로 교환하고 문서들의 여러 버전 중 하나를 선택하는 것을 도와서 클라이언트 선호에 맞게 문서를 제공하기 위한 목적으로 사용된다.

  • 서버는 클라이언트의 Accept 관련 헤더들을 적절한 엔터티 헤더들과 짝을 지어준다.

    • 예: [ Accept-Language | Content-Language ]

    ② 내용 협상 헤더의 품질값

  • HTTP 프로토콜은 클라이언트가 각 선호의 카테고리마다 여러 선택 가능한 항목을 선호도와 함께 나열할 수 있도록 품질값(quality value, q) 을 정의하였다.

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

    • 클라이언트가 여러 선택가능한 항목을 선호도와 함께 나열하도록 품질값을 정의하고있다.

    • q(0.0: 가장 낮은 선호도, 1.0 이 가장 높은 선호도)

    • 때때로 서버가 클라이언트의 선호에 대응하는 문서를 하나도 갖지 않고 있다면 선호에 맞추기 위해 문서를 고치거나 트랜스코딩을 할 수 있다.

    ② 내용 협상 외 다른 헤더에 의한 결정

  • 예: 서버는 클라이언트의 User-Agent 헤더에 기반하여 응답을 보낼 수도 있다.

  • 최선에 가장 가까운 대응을 찾아낼 수 있는 q값 매커니즘은 없다.

  • 서버는 정확한 대응을 찾아내거나, 그냥 갖고 있는 것을 제공해주어야 한다.

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

    • Vary 헤더는 캐시에게 서버가 내줄 응답의 최선의 버전을 결정하기 위해어떤 요청 헤더를 참고하고 있는지 말해준다.

4) 투명협상

04

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

• HTTP/1.1 명세에는 투명협상에 대한 어떤 메커니즘도 정의하지 않았지만 대신 Vary 헤더를 정의했다. 서버는 응답에 Vary 헤더를 포함시켜 보냄으로써 중개자에게 내용협상을 위해 어떤 헤더를 사용하고 있는지 알려줄 수 있다.

• 캐시 프락시는 단일한 URL을 통해 접근할 수 있는 문서의 여러 다른 사본을 저장할 수 있다.

  • 만약 서버가 캐시에 대한 의사결정 프로세스를 캐시에 알려주었다면

  • 캐시는 서버의 입장에서 클라이언트와 협상을 할 수 있다.

• 또한 캐시는 콘텐츠를 트랜스 코딩하기 위한 훌륭한 장소인데, 캐시 안에 설치된 범용 트랜스코더는 특정 서버에 국한되지 않고 어떤 서버의 콘텐츠든 트랜스 코딩할 수 있기 때문.

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

  • 콘텐츠를 캐시하는 것은 그 콘텐츠가 나중에 재사용 될것이라 예상하기 때문이다.

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

  • 캐시는 클라이언트의 요청을 서버로 그대로 전달하고, 응답을 저장한다.

  • 두번째 요청시 응답은 캐시가 URL에 대응하는 문서를 찾아서 돌려줄 것인데,이때 다른 언어의 문서를 원한다면 캐시는 이번 응답과 새로운 응답 문서 2가지를 저장해야한다.

  • 이 다른 버전은 베리언트(variant :변형)나 얼터네이트 (alternate :교대)라고 불리고, 내용 협상은 베리언트 중에서 클라이언트 요청에 가장 잘 맞는 것을 선택하는 과정으로 이해될 수 있다.

    ② Vary

  • HTTP Vary 응답 헤더는 서버가 문서를 선택하거나, 커스텀 콘텐츠를 생성할 때 고려한 클라이언트 요청 헤더 모두를 나열한다.

    • 예를 들어, 제공된 문서가 User-Agent 헤더에 의존한다면 Vary 헤더에는 반드시 User-Agent 를 포함해야한다.

  • 새 요청이 도착했을 때, 캐시는 내용 협상 헤더들을 이용해 가장 잘 맞는 것을 찾는다.

    • 그러나 캐시는 문서를 클라이언트에 제공해 줄 수 있게 되기 전에

      캐시는 반드시 캐시된 응답안에 서버가 보낸 Vary 헤더가 들어있는지 확인해야한다.

    • 만약 Vary 헤더가 존재한다면 Vary 헤더가 명시하고 있는 헤더들은 새 요청과, 오래된 캐시요청에서 그 값이 서로 맞아야한다.

    • 왜냐하면 서버는 클라이언트의 요청헤더에 따라 그들의 응답이 달라질 수 있기 때문에, 캐사는 반드시 캐시된 배리언트와함께 클라이언트 요청헤더와 그에 알맞은 서버 응답 헤더 양쪽 모두 저장해야한다.

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

5) 트랜스코딩

• 서버가 클라이언트의 요구에 맞는 문서를 아에 갖고 있지 않은 경우에는 어떻게 할까?

  • 서버는 에러로 응답해야하겠지만

  • 이론적으로 서버는 기존 문서를 클라이언트가 사용할 수 있는 것으로 변환할 수 있다.

    이 옵션을 트랜스 코딩이라고 부른다.

  • 예: 고해상도 이미지 ⇒ 저해상도 이미지, ...

• 트랜스 코딩에는 포맷변환, 정보 합성, 콘텐츠(내용) 주입 3종류가 있다.

  ① 포맷 변환

  • 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것.

  • 예를 들어 접속속도가 느리고 고해상도 이미지에 별로 관심이 없는 클라이언트에게는,

    이미지가 많은 많은 페이지를 쉽게 보도록 칼라에서 흑백으로, 고해상도에서 저해상도로 줄여줄수있다.

  • 포맷 변환은 내용 협상 헤더에 의해 주도된다. (Accept-)

  • 내용변환 혹은 트랜스코딩: 접근 장치에서 볼 수 있도록 하기 위한 것

  • 콘텐츠 인코딩 혹은 전송 인코딩: 콘텐츠의 더 효율적인 혹은 안전한 전송을 위한 것

    ② 정보 합성(information synthesis)

  • 문서에서 정보의 요점을 추출하는 것.

  • 예: 각 절의 제목에 기반한 문서의 개요생성, 페이지에서 광고 및 로고 제거 등

  • 본문의 키워드에 기반하여 페이지를 분류하는 기술은 문서의 핵심을 요약할 때도 유용하다.

  • 포털 사이트의 웹페이지 디렉터리와 같은 자동화된 웹페이지 분류시스템에 의해 종종 사용된다.

    ③ 콘텐츠 주입

  • 위 2가지 트랜스코딩은 일반적으로 문서의 양을 줄이지만, 콘텐츠 주입은 문서의 양을 늘리는 변환이다.

  • 예: 자동 광고 생성, 사용자 추적 시스템.

  • 지나가는 모든 html 페이지에 자동으로 광고를 삽입하는 트렌스코더는 어떻게든 특정 사용자를 대상으로 광고를 그때 그 때 효과적으로 삽입하기 위해 동적으로 이루어진다.

  • 사용자 추적 시스템 또한 어떻게 페이지가 보여지고 클라이언트가 웹을 돌아다니는지에 대한 통게를 수집하기 위해 페이지에 동적으로 콘텐츠를 추가할 수 있도록 만들어져있다.

    ④ 트랜스 코딩 vs. 정적으로 미리 생성하기

  • 트랜스 코딩의 대안은 웹서버에서 웹페이지의 여러가지 사본을 만드는 것이다.

  • 여러가지 이유로 그다지 현식적인 기법이 못된다.

    • 페이지에 대한 어떠한 작은 변화도 여러 페이지의 수정을 요구하게 되고

    • 각 페이지의 모든 버전을 저장하기 위해 더 많은 공간이 필요하게 되며

    • 페이지들을 관리하고, 그것들 중 올바른 것을 골라서 제공해주는 웹서버를 프로그래밍하기 어려워진다.

  • 루트 페이지를 그때그때 필요할 때마다 변환하는 것은 정적으로 미리 생성하는 것보다 쉬운 해결책이다.

  • 다만, 콘텐츠 제공에 대기시간의 증가로 비용을 초래할 수도 있다. 이들 계산 중 몇몇은 제3자에게 수행하도록 해서 웹서버의 부담을 줄일 수도 있다. 변한은 더 싼 프락시나 캐시에 있는 외부 에이전트에 의해 수행될 수 있다.