[17장] 내용 협상과 트랜스코딩

[eunbc]

No description provided.

[annahxxl]

내용 협상 기법

• 서버에 있는 페이지들 중 어떤 것이 클라이언트에게 맞는지 판단하는 세 가지 다른 방법이 있다
  • 클라이언트에게 선택지를 주거나 - 클라이언트 주도 협상
  • 서버가 자동으로 판단하는 방법 - 서버 주도 협상
  • 혹은 중개자에게 선택하도록 부탁하는 방법 - 투명한 협상

클라이언트 주도 협상

• 서버에게 있어 가장 쉬운 방법
• 단점은 각 페이지에 두 번의 요청이 필요
  1. 목록 얻기
  2. 선택한 사본 얻기

서버 주도 협상

• 클라이언트는 반드시 자신의 무엇을 선호하는지에 대한 충분한 정보를 서버에게 주어서 서버가 현명한 결정을 할 수 있게 해 주어야 한다

내용 협상 헤더

• 클라이언트는 아래의 HTTP 헤더들을 이용해서 자신의 선호 정보를 보낼 수 있다

  헤더	설명
  Accept	서버가 어떤 미디어 타입으로 보내도 되는지
  Accept-Language	서버가 어떤 언어로 보내도 되는지
  Accept-Charset	서버가 어떤 차셋으로 보내도 되는지
  Accept-Encoding	서버가 어떤 인코딩으로 보내도 되는지

내용 협상 헤더의 품질값

• 선호도
• q값은 0.0부터 1.0까지의 값을 가질 수 있다

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

그 외의 헤더들에 의해 결정

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

투명 협상

• 클라이언트 입장에서 협상하는 중개자 프락시를 둠으로써 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 서버에서 제거한다
• 서버는 클라이언트의 요청에 가장 잘 맞는 것이 무엇인지 판별하려면 어떤 요청 헤더를 검사해야 하는지 프락시에게 반드시 말해줄 수 있어야 한다
• 서버는 Vary 헤더를 포함시켜 보냄으로써 중개자에게 내용 협상을 위해 어떤 헤더를 사용하고 있는지 알려줄 수 있다

캐시와 얼터네이트

• 캐시는 클라이언트에게 올바르게 응답을 돌려주기 위해, 서버가 응답을 돌려줄 때 사용했던 로직을 상당부분 사용한다
• 캐시는 반드시 모든 요청을 서버에게 전달하고 모든 응답을 저장해야 한다
• 캐시는 같은 URL에 대해 두 개의 다른 문서를 갖게 되는데, 이 다른 버전은 베리언트(variant)나 얼터네이트(alternate)로 불린다

Vary 헤더

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

트랜스코딩

• 서버가 클라이언트의 요구에 맞는 문서를 갖고 있지 않다면, 서버는 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환할 수 있는데, 이 옵션을 트랜스코딩이라고 부른다
• 트랜스코딩에는 포맷 변환, 정보 합성, 내용 주입의 세 종류가 있다

포맷 변환

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

  ex) 모바일 단말기가 데스크톱 클라이언트 접근 시 HTML을 WML로 변환

정보 합성

• 문서에서 정보의 요점을 추출하는 것을 정보 합성이라고 하는데, 이는 트랜스 코딩 과정에서 유용할 수 있다

  ex) 각 절의 제목에 기반한 문서의 개요 생성이나 페이지에서 광고 및 로고 제거

콘텐츠 주입

• 오히려 양을 늘리는 또 다른 종류의 변환인 내용 주입 트랜스코딩이라는 것도 있다

  ex) 자동 광고 생성과 사용자 추적 시스템

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

• 정적으로 미리 생성해놓는 건 현실적인 기법이 못 된다
• 각 페이지의 모든 버저을 저장하기 위해 더 많은 공간 필요, 올바른 것을 골라서 제공해주는 웺 서버 프로그래밍의 어려움 등등의 이유로..

[byulcode]

내용 협상과 트랜스코딩

내용 협상

: 서버에 있는 페이지들 중 어떤 것이 클라이언트에게 맞는지 판단하는 방법. 이 방법을 이용해 하나의 URL이 여러 가지 리소스 중 적합한 것에 대응되도록 할 수 있다.

트랜스코딩

: 클라이언트와 서버 사이의 내용 협상에 대한 응답에서 수행된다.

내용 협상 기법

1. 클라이언트 주도 : 클라이언트가 요청을 보내면, 서버는 클라이언트에게 선택지를 보내주고 클라이언트가 선택
2. 서버 주도 : 서버가 클라이언트의 요청 헤더를 검증해서 어떤 버전을 제공할지 결정
3. 투명 : 투명한 중간 장치(주로 프락시캐시)가 서버를 대신하여 협상

클라이언트 주도 협상

• 선택지를 표현하는데엔 두 가지 방법이 있다.
  1. 여러 가지 버전에 대한 링크와 각각에 대한 설명이 담긴 HTML 페이지를 돌려주는 방법
  2. 300 Multiple Choices 응답 코드로 HTTP/1.1 응답을 돌려주는 방법
• 클라이언트는 위 같은 응답을 받아 링크와 함께 페이지를 보여주거나 혹은 사용자가 결정을 하도록 하기 위해 대화창을 띄울 것이다 ⇒ 결정을 클라이언트 측에서 함
• 대기 시간 증가, 각 페이지에 두 번의 요청이 필요하다는 단점이 있다.

서버 주도 협상

HTTP 서버가 클라이언트에게 보내줄 적절한 응답을 계산하기 위해 사용하는 메커니즘은 다음 두 가지다.

• 내용 협상 헤더들을 살펴본다.
• 내용 협상 헤더 외의 다른 헤더들을 살펴본다.

내용 협상 헤더

• 클라이언트는 자신의 선호 정보를 HTTP 헤더를 통해 보낼 수 있으며, 반드시 매 요청마다 보내야 한다.
  • Accept
  • Accept-Language
  • Accept-Charset
  • Accept-Encoding

내용 협상 헤더의 품질 값

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

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

q값은 0.0부터 1.0까지 가질 수 있다. 위의 헤더는 클라이언트가 네덜란드어로 된 문서를 받기를 원하고 있으나 영어로 된 문서라도 받아들일것을 의미하고 있다.

그 외의 헤더들에 의해 결정

서버는 또한 User-Agent와 같은 클라이언트의 다른 요청 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있다. 캐시는 반드시 캐시된 문서의 올바른 최신버전을 제공해주려 하기 때문에 HTTP 프로토콜은 서버가 응답에 넣어 보낼 수 있는 Vary 헤더를 정의한다.

다양한 형식의 응답을 생성, 관리해야 하므로 서버의 부하를 높일 수 있고, 캐싱의 어려움이 있음.

투명 협상

• 클라이언트 입장에서 협상하는 중개자 프락시 를 둔다.
• 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 서버에서 제거한다.
• 서버는 응답에 Vary 헤더를 포함시켜 프락시에게 내용 협상을 위해 어떤 헤더를 사용하는지 알린다.

캐시와 얼터네이트(alternate)

• 캐시는 클라이언트에게 올바르게 응답을 돌려주기 위해, 서버가 응답을 돌려줄 때 사용했던 로직을 상당부분 사용한다.
• 캐시는 반드시 모든 요청을 서버에게 전달하고 모든 응답을 저장해야 한다.
• 캐시는 같은 URL에 대해 두 개의 다른 문서를 갖게 된다.
• 이 다른 번전은 배리언트(variant)나 얼터네이트(alternate)라고 불린다.

Vary 헤더

• HTTP Vary 응답 헤더는 클라이언트 요청 헤더 모두를 나열한다.
• 캐시가 문서를 클라이언트에게 제공해 주기 전에, 캐시는 반드시 캐시된 응답 안에 서버가 보낸 Vary 헤더가 있는지 확인한다.
• Vary 헤더가 존재한다면, Vary 헤더가 명시하고 있는 헤더들은 새 요청과 오래되고 캐시된 요청의 값이 맞아야 한다.

트랜스코딩

: 서버가 클라이언트의 요구에 맞는 문서를 가지고 있지 않을 때 서버가 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환하는 옵션

포맷 변환

• 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것이다.
• 포맷 변환은 내용 협상 헤더에 의해 주도된다.
• 콘텐츠를 특정 접근 장치에서 볼 수 있도록 하는 것이다.

정보 합성(information synthesis)

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

콘텐츠 주입

• 웹 문서의 양을 늘리는 종류의 변환. (ex. 자동 광고 생성, 사용자 추적 시스템)
• 특정 사용자를 대상으로 자동으로 광고를 삽입한다.
• 어떻게 페이지가 보여지고 사용자가 웹을 서핑하는 거에 따라 동적으로 콘텐츠를 삽입한다.

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

• 트랜스코딩의 대안으로는 웹 서버에서 웹페이지의 여러 사본을 만드는 것
  • 페이지의 작은 변화에 따라 페이지의 수정이 필요하다.
  • 모든 버전을 저장하기 위해 더 많은 공간이 필요하다.
  • 페이지를 관리하고 올바른 페이지를 노출 시키도록 웹 서버를 프로그래밍하기 어려워진다.
• 광고 삽입과 같은 트랜스코딩은 요청한 사용자에게 달려있기 때문에 정적인 방법으로는 수행될 수 없다.

⇒ 루트 페이지를 필요할 때마다 변환하는 것이 좋다.

[park0jae]

내용 협상 기법

HTTP 내용 협상은 클라이언트와 서버 간 어떤 표현을 사용할 지 협의하는 메커니즘

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

클라이언트 주도 협상

• 여러 가지 버전에 대한 링크와 각각에 대한 설명이 담긴 HTML 페이지를 돌려주거나, 300 Multiple Choices 응답 코드로 HTTP/1.1 응답을 돌려주는 것이다.
• 클라이언트가 어떤 표현을 선호하는지 서버에게 알리고, 서버는 그에 따라 응답을 제공하는 방식임

[ 과정 ]

1. 클라이언트 요청 : 클라이언트는 요청 헤더에 ‘Accept’ 헤더를 사용해 선호하는 미디어 타입(ex. JSON, XML) 및 다양한 특성을 서버에게 알림

GET /resource HTTP/1.1
Host: example.com
Accept: application/json, text/html;q=0.9, */*;q=0.8

1. 서버 응답 : 서버는 클라이언트의 요청을 확인하고, 해당 요청에 가장 적합한 표현을 선택해 응답하며 ‘Content-Type’ 헤더를 사용해 선택된 미디어 타입을 클라이언트에게 알림

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: xxx

[ 장점 ]

• 구현하기 쉬움
• 클라이언트가 선호하는 표현을 선택할 수 있기 때문에 사용자 경험을 최적화하고 선호에 따라 적합한 콘텐츠 제공이 가능
• 클라이언트가 필요로 하는 정보만 요청하고, 수신하기 때문에 불필요한 데이터 전송을 방지

[ 단점 ]

• 각 페이지에 두 번의 요청이 필요함
  • 클라이언트가 초기 페이지 요청에 이어 추가로 한 번의 요청을 보내서 선호하는 표현을 얻는다.
  • 초기 페이지 요청 + 이어지는 내용 협상을 통한 추가 요청 ( 목록 획득 후 → 사본 획득 )
• 대기시간이 증가하며, 페이지당 여러 번의 요청이 필요
  • 네트워크 트래픽을 유발할 수 있어 대기시간 증가
  • 클라이언트가 선호하는 표현을 얻기 위해 서버에 다시 요청해야 하므로 추가적인 라운드트립(요청 → 응답의 사이클 시간)이 발생할 수 있음

서버 주도 협상

• 클라이언트가 서버가 결정하도록 요청 헤더에 정보를 삽입하는 협상 방식
• 이전의 클라이언트 주도 협상은 클라이언트와 서버 사이의 커뮤니케이션을 증가시켰다.
• 이런 추가 커뮤니케이션을 줄이기 위한 방법으로 서버가 어떤 페이지를 돌려줄 것인지 결정하게 하는 것
• 이를 위해 클라이언트는 무엇을 선호하는지에 대한 충분한 정보를 서버에게 제공하고 서버는 이를 클라이언트의 요청 헤더를 통해 얻는다.

[ 내용 협상 헤더 ]

• HTTP 헤더들을 이용해 자신의 선호 정보를 나타냄
  • Accept : 서버가 어떤 미디어 타입으로 보내도 되는지 알려줌
  • Accept-Language : 서버가 어떤 언어로 보내도 되는지 알려줌
  • Accept-Charset : 서버가 어떤 차셋으로 보내도 되는지 알려줌
  • Accept-Encoding : 서버가 어떤 인코딩으로 보내도 되는지 알려줌
• HTTP는 상태가 없는 프로토콜이기 때문에 클라이언트는 자신의 선호 정보를 매 요청마다 보내야 한다.

[ 내용 협상 헤더의 품질값 ]

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

• 네덜란드어(nl)로 된 문서를 받기를 가장 원하며, 영어(en)로 된 문서라도 받아들일 것임을 의미함
• 그러나 어떠한 경우에도 프랑스어(fr) 버전은 지원하지 않음을 의미함

[ 그 외의 헤더들에 의해 결정 ]

• 서버는 User-Agent와 같은 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있다.
• 서버가 웹브라우저에서 자바스크립트를 지원하지 않는다는 것을 알고 있다면, 자바스크립트를 포함하지 않은 페이지를 돌려줄 수 있다.

투명협상

• 클라이언트 입장에서 협상하는 중개자 프락시를 둔다.
• 클라이언트와 메시지 교환을 최소화하며, 서버 주도 협상으로 인한 부하를 서버에서 제거
• 이를 도와주는 것이 Vary 헤더로, 서버는 응답에 Vary 헤더를 포함시켜 중개자에게 내용 협상을 위해 어떤 헤더를 사용하고 있는지 알려준다
• 쉽게 말해서는 Vary 헤더에 따라 콘텐츠의 내용이 어떻게 전달되는지 결정되는 것이다

[ 캐시와 얼터네이트 ]

• 캐시는 클라이언트에게 올바르게 응답을 돌려주기 위해 서버가 응답을 돌려줄 때 사용했던 로직 상당부분을 사용
• 캐시는 반드시 모든 요청을 서버에게 전달하고 모든 응답을 저장해야함. (배리언트 중 클라이언트 요청에 가장 적합한 것을 선택하는 과정을 위해)
• 캐시는 같은 URL에 대해 두 개의 다른 문서를 갖게 된다.
• 이 다른 버전은 배리언트(Variant)나 얼터네이트(alternate)라고 불린다.

[ Vary 헤더 ]

• Vary 헤더는 특정 조건에 따라 캐시된 응답이 어떤 조건에 의해 발생했는지 나타냄 (이를 통해 캐시된 응답을 적절히 클라이언트에게 제공 가능)
• HTTP Vary 응답 헤더는 클라이언트 요청 헤더 모두를 나열
• 캐시가 문서를 클라이언트에게 제공해주기 전, 캐시는 반드시 캐시된 응답안에 서버가 보낸 Vary 헤더가 있는지 확인
• Vary 헤더가 존재하면, Vary 헤더가 명시하고 있는 헤더들은 새 요청과 오래되고 캐시된 요청의 값이 맞아야 함

ex)

클라이언트가 한국어로 된 콘텐츠와 영어로 된 콘텐츠에 대한 요청을 보냈다고 가정, 서버는 이에 대해 각각의 언어로 콘텐츠를 생성하고 응답하는데 이때, ‘Vary’ 헤더를 사용하여 언어에 따라 다른 캐시를 생성하고 관리함

GET /content HTTP/1.1
Host: example.com
Accept-Language: en

서버의 응답

HTTP/1.1 200 OK
Content-Type: text/html
Vary: Accept-Language

<!-- 캐시된 영어로 된 콘텐츠 내용 -->

→ 여기서 Vary: Accept-Language’는 이 응답이 언어에 따라 다르게 캐시된 것임을 나타낸다. 만약 다른 클라이언트가 한국어로 된 콘텐츠를 요청하면 서버는 요청에 따라 다른 버전의 캐시를 사용하여 응답을 생성한다.

트랜스코딩

서버가 클라이언트의 요구에 맞는 문서를 가지고 있지 않으면, 서버는 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환할 수 있다.
이 옵션을 트랜스코딩이라고 함

[ 포맷 변환 ]

• 데이터를 클라이언트가 볼 수 있게 한 포맷에서 다른 포맷으로 변환하는 것
• 포맷 변환은 내용 협상 헤더에 의해 주도
• 콘텐츠를 특정 접근 장치에서 볼 수 있도록 하는 것
• ex) PDF 형식의 문서만 존재할 때, 클라이언트는 이를 지원하지 않고 텍스트 형식을 원한다면 서버는 PDF → 텍스트로 변환하여 전달함

[ 정보 합성 ]

• 각 절의 제목에 기반한 문서의 개요 생성이나 페이지에서 광고 및 로고 제거와 같은 예가 있음
• 웹페이지 디렉토리와 같은 자동화된 웹페이지 분류 시스템에 의해 종종 사용

[ 콘텐츠 주입 ]

• 자동 광고 생성, 사용자 추적 시스템과 같은 예가 있음
• 특정 사용자를 대상으로 자동으로 광고 삽입
• 어떻게 페이지가 보여지고 사용자가 웹을 서핑하는 것에 따라 동적으로 콘텐츠 삽입

[ 트랜스코딩 vs 정적으로 미리 생성 ]

1. 트랜스코딩의 대안으로 웹 서버에서 웹페이지의 여러 사본을 만드는 것
   • 트랜스 코딩 : 서버가 클라이언트의 요구에 맞게 동적으로 콘텐츠 변환
   • 대안으로 웹 서버에서 여러 사본 생성 : 미리 웹페이지의 여러 버전을 만들어 두고, 클라이언트가 요청할 때 적절한 버전을 제공하는 방식
2. 트랜스 코딩의 단점과 대안의 문제
   • 트랜스 코딩의 단점
     • 작은 변화에 따라 페이지 수정 필요, 모든 버전 저장을 위한 더 많은 공간 필요
   • 대안의 문제
     • 미리 여러 사본을 만들어 두면 공간이 많이 필요하고, 작은 수정이 필요할 때마다 많은 수의 페이지를 관리해야 함
3. 트랜스 코딩이 필요한 경우
   • 광고 삽입과 같은 트랜스코딩은 요청한 사용자에게 달려있기 때문에 정적인 방법으로 수행이 불가
4. 루트 페이지를 필요할 때마다 변환하는 것이 좋다.
   • 루트 페이지를 요청할 때마다 트랜스코딩하여 사용자에게 맞는 형태로 제공하는 것이 효과적이다.

→ 종합하자면, 트랜스코딩은 동적이고 실시간으로 사용자에게 맞는 콘텐츠를 생성하는 반면, 정적으로 미리 생성된 방식은 여러 버전을 만들어두고 적절한 것을 선택하여 제공하는 방식이다.

[eunbc]

내용 협상 기법

• 클라이언트가 ‘http://example.com/’ 을 요청했을 때 서버는 어떤 버전을 제공해주어야 하는가?
• 영어 사용자에게는 영어 버전을 보내주고 프랑스어 사용자에게는 프랑스어 버전을 보내줄 것이다
• 클라이언트와 서버가 이러한 판단을 할 수 있도록 내용 협상을 한다

클라이언트 주도 협상

• 클라이언트가 요청을 보내면, 서버는 가능한 페이지의 목록을 응답으로 돌려주어 클라이언트가 보고 싶은 것을 선택하게 한다
  • 가능한 페이지의 목록 : 여러 버전에 대한 링크가 담긴 html 페이지을 돌려주거나, 300 Multiple Choices로 응답
• 장점 : 서버 입장에서 가장 구현하기 쉽고, 클라이언트는 최선의 선택을 할 수 있다
• 단점 : 올바른 콘텐츠를 얻으려면 최소 두번의 요청이 필요하다, 대기 시간 증가

서버 주도 협상

• 서버가 클라이언트의 요청 헤더를 검증해서 어떤 버전을 제공할지 결정한다
• 클라이언트는 Accept, Accept-Language, Accept-Charset, Accept-Encoding 헤더들을 이용해서 자신의 선호 정보를 보내고, 서버는 이에 따라 문서를 제공한다
• HTTP는 상태가 없는 프로토콜이기 때문에 클라이언트는 자신의 선호 정보를 반드시 매 요청마다 보낸다
• 클라이언트가 여러 선택 가능한 항목을 선호도와 함께 나열할 수 있도록 품질값을 정의한다
  • Accept-Language : en;q=0.5, fr=q=0.0, nl;q=1.0
• User-Agent 와 같은 다른 요청 헤더들을 이용해 알맞은 응답을 만들어내기도 함
  • 예 : 오래된 버전의 웹 브라우저가 자바스크립트를 지원하지 않는다면 자바스크립트를 포함하지 않은 페이지를 돌려줌

투명 협상

• 투명 협상은 클라이언트 입장에서 협상하는 중개자 프락시를 둠으로써 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 제거한다.
• 정형화된 명세는 없다
• 서버는 응답에 Vary 헤더를 포함시켜 보냄으로써 중개자에게 내용협상을 위해 어떤 헤더를 사용하고 있는지 알려줄 수 있다
  • Vary 응답 헤더는 서버가 문서를 선택하거나 커스텀 콘텐츠를 생성할 때 고려한 클라이언트 요청 헤더 모두를 나열한다
  • 캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 한다. 맞는 것이 없으면, 캐시는 문서를 서버에서 가져온다
• 캐시 프락시는 단일한 URL 을 통해 접근할 수 있는 문서의 여러 다른 사본을 저장하는데, 내용 협상을 통해 클라이언트 요청에 가장 잘 맞는 것을 선택한다

트랜스코딩

• 서버가 클라이언트의 요구에 맞는 문서를 아예 갖고 있지 않다면 어떻게 되는가?
• 서버는 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환할 수 있다. 이 옵션을 트랜스코딩이라 함
  • 포맷 변환 : 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환. (ex. html을 wml문서로 변환, 이미지를 칼라에서 흑백으로, 고해상도에서 저해상도로 변환하고 축소)
  • 정보 합성 : 정보의 요청을 추출하는 것 (ex. 문서의 개요 생성, 광고 및 로고 제거)
  • 콘텐츠 주입 : 양을 늘리는 변환 (ex. 자동 광고 생성, 사용자 추적 시스템)
• 트랜스 코딩 vs 정적으로 미리 생성해놓기
  • 정적으로 미리 생성하기 위해서는 작은 변화도 여러 페이지의 수정을 요구하고, 각 버전을 저장하기 위해 더 많은 공간을 필요로한다
  • 광고 삽입같은건 정적인 방법으로 수행될 수 없다
  • 루트 페이지를 필요할 때마다 변환하는 것은 정적으로 미리 생성하는 것보다 쉬운 해결책이나 대기시간을 늘린다

다음 단계

• HTTP 의 내용 협상은 성능 제약을 초래한다. 적절한 콘텐츠를 위해 탐색 또는 추측하는 비용이 클 수 있다
• HTTP는 내용협상이 필요한 유일한 프로토콜이 아니다. TCP/IP 위에서 내용협상 프로토콜이 만들어질 수 있을까?

[kimday0326]

하나의 URL이 여러 리소스에 대응할 필요가 있는 경우, 요청에 따라 어떤 데이터를 보내줄 지 판단하는 것을 내용 협상이라 한다.

내용 협상 기법

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

1. 클라이언트 주도
2. 서버 주도
3. 투명

클라이언트 주도 협상

클라이언트가 요청을 보내면, 서버는 클라이언트에게 선택지를 보내주고, 클라이언트가 선택

• 장점
  • 서버 입장에서 가장 구현하기 쉽다.
  • 클라이언트는 최선의 선택을 할 수 있다.
• 단점
  • 각 페이지에 두 번의 요청이 필요하다. (목록, 사본)
  • 여러 개의 URL이 필요하다.

서버 주도 협상

서버가 클라이언트 요청의 헤더를 보고 적절한 응답을 계산해서 보내준다.

내용 협상 헤더를 보는 방식

클라이언트가 자신의 선호 정보를 매 요청마다 보내야한다.

Accept 관련 헤더	엔터티 헤더
Accept	Content-Type
Accept-Language	Content-Language
Accept-Charset	Content-Type
Accept-Encoding	Content-Encoding

이는 커뮤니케이션 대기 시간을 줄여주지만, 선호 정보가 풍푸하지 않으면 서버는 추측을 해야한다.

[내용 협상 헤더의 품질값]
다행히도 HTTP는 선호에 대한 설명을 품질값(q값)을 통해 전달할 수 있는 메커니즘을 제공한다.
Accept-Language: en;q=0.5, fr;q=0.0 nl;q=1.0, tr;q=0.0
q값은 0.0부터 1.0까지의 값을 가지며 높을수록 선호한다는 의미이다.

그 외의 헤더를 보는 방식

• User-Agent 와 같은 헤더를 이용하는 방법도 있다.
• HTTP 프로토콜은 서버가 응답에 넣어 보낼 수 있는 Vary 헤더를 정의한다.

아파치의 내용 협상

아파치 웹 서버가 내용 협상을 지원하는 방법

• 웹 사이트 디렉터리에서, 배리언트(variant)를 갖는 웹 사이트의 각 URI를 위한 type-map 파일을 만든다.
  -> type-map 파일은 모든 배리언트와 그들 각각에 대응하는 내용 협상 헤더들을 나열한다. (look-up table?)
• 아파치가 그 디렉터리에 대해 자동으로 type-map 파일을 생성하도록 하는 MultiViews 지시어를 켠다.

투명 협상

클라이언트 입장에서 협상하는 중개자를 프락시로 두는 방식
클라이언트 주도 협상에 비해 부하가 줄지만, 정형화된 명세가 없다.

캐시와 얼터네이트(alternate)

• 캐시는 같은 URL에 대해 여러 개의 다른 문서를 갖게 된다.
• 이는 배리언트(variant)나 얼터네이트(alternate)로 불린다.
  따라서, 내용 협상은 배리언트 중에서 클라이언트의 요청에 가장 잘 맞는 것을 선택하는 과정이다.

Vary 헤더

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

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

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

• 투명 협상을 구현하기 위해 캐시는 반드시 캐시된 배리언트와 함께 클라이언트 요청 헤더와 그에 알맞은 서버 응답헤더 양쪽 모두를 저장해야 한다.

Vary: User-Agent, Cookie

서버의 Vary 헤더가 이렇다면, 거대한 수의 다른 User-Agent와 Cookie 값이 많은 배리언트를 만들어 낼 것이다.

트랜스 코딩

서버가 클라이언트의 요구에 맞는 문서를 하나도 갖고 있지 않다면, 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환하는 옵션

포맷 변환

• 포맷변환은 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것이다.
• 내용 협상 헤더에 의해 주도된다.(User-Agent 헤더에 의해서 주도될 수도 있지만)
• 내용 변환, 트랜스코딩은 콘텐츠를 특정 접근 장치에서 볼 수 있도록 하기 위한 것
• 콘텐츠 인코딩, 전송 인코딩은 콘텐츠의 더 효율적인 혹은 안전한 전송을 위한 것

정보 합성

• 문서에서 정보의 요점을 추출하는 것을 정보 합성(information synthesis)라고 한다. (미리 보기?)
• 이 기술은 포털 사이트의 웹페이지 디렉터리와 같은 자동화된 웹페이지 분류 시스템에 의해 종종 사용된다.

콘텐츠 주입

내용 주입 트랜스코딩(content-injection transcoding)은 앞의 두 종류의 트랜스 코딩과 달리 웹 문서의 양을 늘린다. (자동 광고 생성과 사용자 추적 시스템)

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

• 트랜스코딩의 대안은 웹 서버에서 웹페이지의 여러 가지 사본을 만드는 것이다.
• 하나는 고화질 이미지로 하나는 저화질 이미지로, 하나는 HTML로 하나는 WML로 ... -> 정적으로 미리 생성해놓기
• 그러나, 이것은 여러 가지 이유로 그다지 현실적인 기법은 아니다.

[KarmaPol]

내용 협상

하나의 URL이 여러 리소스 중 적합한 것에 대응

내용 협상 기법

클라이언트 주도 협상

서버가 클라이언트 요청을 받았을 때 가능한 페이지의 목록을 응답
-> 클라이언트가 보고 싶은 것을 선택

• 구현하기 쉬움
• 두번의 요청 필요
• 리소스 별로 여러개의 url 필요

서버 주도 협상

클라이언트가 자신이 무엇을 선호하는지 충분한 정보를 서버에게 전달
-> 서버는 클라이언트의 요청 헤더로 정보 파악해 최적의 리소스 응답

클라이언트 내용 협상 헤더

• Accept - 미디어 타입
• Accept-Language - 언어
• Accept-Charset - charset
• Accept-Encoding - 인코딩

투명 협상

중개자 프락시를 둠으로써
클라이언트와의 메시지 교환을 최소화 및 서버 주도 협상으로 인한 부하 최소화

Vary 응답 헤더를 포함시켜 내용협상을 위해 어떤 헤더를 사용하고 있는지 포함
Vary: User-Agent, Cookie

캐시와 얼터네이트

캐시는 서버가 응답을 돌려줄 때 사용했던 의사결정 로직을 상당 부분 사용해야한다

캐시된 리소스에 Vary 응답 헤더를 포함하여
새로운 클라이언트 요청의 헤더값과 비교한다
-> 맞는것이 없다면 배리언트를 새로 가져온다

트랜스코딩

서버가 클라이언트의 요구에 맞는 문서를 갖고 있지 않을 경우, 변환할 수 있다

포맷 변환

• 오래된 모바일 단말기가 데스크톱을 위한 문서에 접근하면 HTML을 WML로 변환한다
• 포맷 변환은 내용 협상 헤더에 의해 주도된다

정보 합성

문서에서 정보의 요점을 추출
ex) 각 절의 제목에 기반한 문서 개요 생성

콘텐츠 주입

사용자에 맞춰 콘텐츠를 주입
ex) 자동 광고 생성, 사용자 추적 시스템

vs 정적으로 미리 생성

사본을 미리 생성하는 것은 현실적이지 않다

• 페이지의 수정 까다로움
• 동적 컨텐츠 삽입 불가