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

[ruthetum]

내용 협상

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

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

1. 클라이언트 주도 협상

• 클라이언트가 요청 시 여러 가지 버전에 대한 링크와 각각에 대한 설명이 담긴 HTML 페이지를 돌려주거나, 300 Multiple Choices 응답 반환

• 서버 입장에서 가장 구현하기 쉽고, 클라이언트는 원하는 버전을 선택하기 때문에 최선의 선택을 할 수 있음

• 하지만 클라이언트에서 선택을 해야하기 때문에 요청 횟수와 대기시간 증가

2. 서버 주도 협상

• 서버가 클라이언트의 요청 헤더를 검증해서 어떤 버전을 제공할지 결정

• 당연히 클라이언트 주도 협상보다 빠름

• 서버가 가장 적절한 것을 선택할 수 있도록 q값 메커니즘을 제공하고, 서버가 클라이언트에게 요청이 어떻게 평가되는지 말해줄 수 있도록 하기 위해 Vary 헤더를 제공

• 하지만 식별하기 위한 값이 헤더에 존재하지 않는 경우 서버가 추측해서 제공

내용 협상 헤더

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

서버는 클라이언트 Accept 관련 헤더들을 적절한 엔터티 헤더들과 매핑

• Accept <-> Content-Type
• Accept-Language <-> Content-Language
• Accept-Charset <-> Content-Type
• Accept-Encoding <-> Content-Encoding

내용 협상 헤더의 품질값

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

• q값은 0.0 ~ 1.0 까지의 값
• 0.0은 가장 낮은 선호도, 1.0은 가장 높은 선호도
• 예시의 값은 네덜란드어(nl)를 가장 선호, 그 다음에는 영어도 선호, 프랑스/터키어는 선호하지 않음

그 외의 헤더들에 의해 결정

• User-Agent와 같은 클라이언트의 다른 요청 헤더들을 이용해 알맞은 요청을 만들고, 서버가 응답에 넣어 보낼 수 있는 Vary 헤더를 정의
  • 서버가 오래된 버전의 웹 브라우저에서 자바스크립트 버전을 지원하지 않는 경우, 그들에게 자바스크립트가 포함되지 않은 페이지를 돌려줄 수 있음

3. 투명 협상

• 투명 협상은 클라이언트 입장에서 협상하는 중개자 프락시를 통해 클라이언트와의 메시지 교환을 최소화

  • 프락시가 서버를 대신해서 협상

• 당연히 클라이언트 주도 협상보다 빠르고, 웹 서버가 직접 협상을 할 필요가 없음

• 하지만 투명 협상에 대한 정형화된 명세가 없음

• 서버는 응답에 Vary 헤더를 포함시켜 보내고, 프락시는 내용 협상을 위해 어떤 헤더를 사용하고 있는지 알려줄 수 있음

참고.

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

캐시와 얼터네이트

• 캐시는 같은 URL에 대해 두 개의 다른 문서를 갖게 됨

• 이 다른 버전은 배리언트(variant)나 얼터네이트(alternate)로 불림

• 내용 협상은 배리언트 중에서 클라이언트의 요청에 가장 잘 맞는 것을 선택하는 과정

Vary 헤더

• Vary 응답 헤더는 서버가 문서를 선택할 때 클라이언트 요청 헤더 모두(일반적인 내용 협상 헤더 외에 추가)를 나열

• 예를 들어 제공된 문서가 User-Agent 헤더에 의존하는 경우 Vary 헤더는 반드시 User-Agent를 포함해야 함

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

• 투명 협상을 구현하기 위해 캐시는 반드시 캐시된 배리언트와 함께 클라이언트 요청 헤더와 그에 알맞은 서버 응답

트랜스 코딩

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

1. 포맷 변환
2. 정보 합성
3. 콘텐츠 주입

1. 포맷 변환

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

• 예를 들어 HTML을 WML으로 변환하거나, 접속 속도가 느리면서 고해상도 이미지에 관심이 없는 경우 이미지의 크기나 해상도를 줄여줄 수 있음

• 내용 협상 헤더에 의해 진행 (User-Agent에 의해 진행될 수도 있음)

내용 변환, 트랜스코딩 vs 콘텐츠 인코딩, 전송 인코딩

• 내용 변환, 트랜스코딩 : 콘텐츠를 특정 접근 장치에서 볼 수 있도록 하기 위함
• 콘텐츠 인코딩, 전송 인코딩 : 콘텐츠의 더 효율적인 혹은 안전한 전송을 위함

2. 정보 합성

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

• 예를 들어 각 절의 제목에 기반한 문서의 개요 생성이나 페이지에서 광고 및 로고 제거를 하는 경우

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

3. 콘텐츠 주입

• 앞선 두 종류의 트랜스 코딩(포맷 변환, 정보 합성)은 일반적으로 웹 문서의 양을 줄이는 것이 목적

• 콘텐츠 주입은 오히려 양을 늘리는 변환 방법으로, 예를 들어 자동 광고 생성, 사용자 추적 시스템에 활용

• 특정 사용자를 대상으로 하는 광고를 그때그때 효과적으로 삽입하기 위해 동적으로 이루어짐

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

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

• 예를 들어 하나는 고화질/저화질 이미지, HTML/WML 등등 미리 모두 생성

• 하지만 여러 가지 이유로 그다지 현실적인 기법은 아님

  • 페이지가 수정될 때보다 여러 페이지를 수정
  • 리소스를 저장하기 우해 더 많은 공간이 필요
  • 타켓 광고 삽입은 정적인 방법으로 수행될 수 없음