HTTP 완벽 가이드 17장. 내용 협상과 트랜스코딩

들어가기

하나의 URL이 여러 리소스에 대응할 필요가 있는 경우가 있다.
HTTP는 클라이언트와 서버가 이러한 판단을 할 수 있도록 내용 협상(content-negotiation) 방법을 제공한다.
이 방법을 이용해 하나의 URL이 여러 가지 리소스 중 적합한 것에 대응될 수 있도록 한다.

17.1. 내용 협상 기법

클라이언트 주도
- 동작: 클라이언트가 요청을 보내면, 서버는 클라이언트에게 선택지를 보내주고, 클라이언트가 선택한다.
- 장점: 서버입장에서 가장 구현하기 쉽다. 클라이언트는 최선의 선택을 할 수 있다.
- 단점: 대기시간이 증가한다. 올바른 콘텐츠를 얻으려면 최소 두번의 요청이 필요하다.
서버 주도
- 동작: 서버가 클라이언트의 요청 헤더를 검증해서 어떤 버전을 제공할 지 결정한다.
- 장점: 클라이언트 주도 협상보다 빠르다.
  - HTTP는 서버가 가장 적절한 것을 선택할 수 있도록 q값 매커니즘을 제공
  - 서버가 다운스트림 장치에게 요청이 어떻게 평가되는지 말해줄 수 있도록 Vary 헤더를 제공한다.
- 단점: 만약 결정이 뻔하지 않으면(헤더에 맞는 것이 없다면) 서버는 추측을 해야 한다.
투명
- 동작: 투명한 중간 장치(주로 프락시 캐시)가 서버를 대신하여 협상
- 장점: 웹 서버가 협상을 할 필요가 없으며 클라이언트 주도 협상보다 빠르다.
- 단점: 투명 협상을 어떻게 하는지에 대한 정형화된 명세가 없다.

17.2 클라이언트 주도 협상

서버가 클라이언트의 요청을 받았을 때 가능한 페이지 목록을 응답으로 돌려주어 클라이언트가 보고 싶은 것을 선택하게 하는 것이다.
단점으로 각 페이지의 두번의 요청이 필요하여 시간이 오래 걸린다.
방법
- 여러가지 버전에 대한 링크와 각각에 대한 설명이 담긴 HTML 페이지를 돌려준다.
- 300 Multiple Choices 응답코드로 HTTP/1.1 응답을 돌려준다.
추가적인 단점으로 여러 개의 URL을 요구한다는 점이다.

17.3 서버 주도 협상

서버가 어떤 페이지를 돌려줄 것인지 결정하게 하는 방법
결정에 필요한 정보를 요청 헤더에 담아서 보내주어야 한다.
응답 계산을 위한 메커니즘
- 내용 협상 헤더들을 살펴본다. 서버는 클라이언트의 Accept 관련 헤더들을 들여보고 그에 맞는 응답 헤더를 준비한다.
- 내용 협상 헤더 외의 다른 헤더들을 살펴본다. 예를 들어, 서버는 클라이언트의 User-Agent 헤더에 기반하여 응답을 보내줄 수 있다.
내용 협상 헤더
- Accept 관려 헤더 |헤더|설명|응답(엔터티 헤더)| |—|—|—| |Accept|서버가 어떤 미디어 타입으로 보내도 되는지 알려준다.|Content-Type| |Accept-Language|서버가 어떤 언어로 보내도 되는지 알려준다.|Content-Language| |Accept-Charset|서버가 어떤 차셋으로 보내도 되는지 알려준다.|Content-Charset| |Accept-Encoding|서버가 어떤 인코딩으로 보내도 되는지 알려준다.|Content-Encoding|
내용 협상 헤더의 품질값
- 품질값(q)을 이용해 선호에 대한 설명을 넣어줄 수 있다.
- q값은 0.0 ~ 1.0까지의 값을 가질 수 있다.
```
Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0
```
그 외의 헤더들에 의해 결정
- 서버는 User-Agent와 같은 클라이언트의 다른 요청 헤더들을 이용해 알맞은 요청을 만들어 내려고 시도할 수 있다.
  - 오래된 웹브라우저에서 Javascript가 지원하지 않는다면 다른 페이지를 돌려줄 수도 있다.
- 캐시는 반드시 캐시된 문서의 올바른 ‘최선의’ 버전을 제공하기 때문에 Vary 헤더를 정의한다.
  - Vary 헤더는 캐시에게 서버가 내줄 응답의 최선의 버전을 결정하기 위해 어떤 요청 헤더를 참고하고 있는지 말해준다.
아파치 내용 협상
- 내용 협상은 웹 사이트 콘텐츠의 제공자에게 달려있다.
- 만약 색인 페이지를 여러 버전으로 제공하기 위해서는 각각의 버전에 해당하는 파일을 아파치 서버의 적절한 디렉터리에 모두 넣어주어야 한다.
- 그런 다음 둘 중의 한가지 방법으로 내용 협상을 동작시킬 수 있다.
  - 웹 사이트 디렉터리에서 배리언트(variant)를 갖는 웹사이트의 각 URI를 위한 type-map 파일을 만든다.
    - 그 type-map 파일은 모든 배리언트와 그들 각각에 대응하는 내용 협상 헤더들을 나열한다.
  - 아파치카 그 디렉터리에 대해 자동으로 type-map 파일을 생성하도록 하는 MultiViews 지시어를 켠다.
- type-map 파일 사용
  - 핸들러 추가
    - type-map 파일이 어떻게 생겼는지 알 필요가 있기 때문에 서버 설정 파일에 파일 접미사를 명시한 핸들러 추가
    - .var로 끝나는 파일이 type-map 파일임을 명시한다.
      AddHandler type-map .var
  - type-map 파일을 생성한다
    URI: joes-hardware.html URI: joes-hardware.en.html Content-type: text/html Content-language: en
- MultiViews 사용
  - access.conf 파일의 적절한 절(, , )에 Options 지시어를 이용해 웹 사이트를 포함한 디렉터리에 MultiViews를 반드시 킨다.

17.4 투명 협상

클라이언트 입장에서 협상하는 중개자 프락시를 둠으로써 클라이언트와 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 서버에서 제거한다.
투명한 내용 협상을 지원하기 위해, 서버는 클라이언트의 요청에 가장 잘 맞는 것이 무엇인지 판별하려면 어떤 요청 헤더를 검사해야 하는지 프락시에게 말해줄 수 있어야 한다.
캐시와 얼터네이트(alternate)
- 캐시는 올바른 응답을 돌려주기 위해 서버가 응답을 돌려줄 때 사용했던 의사결정 로직의 상당 부분을 그대로 사용한다.
- Accept 헤더들을 사용한다.
- 첫번째 요청(프랑스어) -> 캐시는 서버로 그대로 전달하고 응답을 저장한다.
- 두번째 요청(스페인어) -> 프랑스어를 응답하면 잘못된 응답이므로, 다시 서버에게 그대로 전달하고 그 URL에 대한 이번의 응답과 지난번의 응답을 모두 저장해야 한다.
  - 서버와 마찬가지로 캐시에도 프랑스어, 스페인어 두개의 다른 문서를 갖게 된다.
  - 이 다른 버전은 배리언트(variant), 얼터네이트(alternate)라고 불린다.
Vary 헤더
- HTTP Vary 응답 헤더는 서버가 문서를 선택하거나 커스텀 콘텐츠를 생성할 때 고려한 클라이언트 요청 헤더 모두를 나열한다.
- Vary 헤더가 존재한다면, 그 Vary 헤더가 명시하고 있는 헤더들은 새 요청과 오래된 캐시된 요청에서 그 값이 서로 맞아야 한다.
- 예제
```
Vary: User-Agent, Accept-Language
```
  - 만약 서버의 Vary 헤더가 위와 같다면, 거대한 수의 다른 User-Agent와 Cookie 값이 많은 Variant를 만들어 낼 것이다.
  - 캐시는 각 Variant마다 알맞은 문서 버전을 저장해야 한다. 검색할 때, 없으면 캐시는 문서를 서버에서 가져온다.

17.5 트랜스코딩

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

전	후
HTML 문서	WML 문서
고해상도 이미지	저해상도 이미지
64k 색 이미지	흑백 이미지
프레임을 포함한 복잡한 페이지	프레임이나 이미지가 없는 단순한 텍스트 페이지
자바 애플릿이 있는 HTML 페이지	자바 애플릿이 없는 페이지
광고가 있는 페이지	광고가 없는 페이지

포맷 변환
- 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환
- HTML 문서 -> WML 문서
정보 합성
- 문서에서 정보의 요점을 추출하는 것을 정보 합성이라고 한다.
콘텐츠 주입
- 양을 늘리는 변환으로 자동 광고 생성, 사용자 추적 시스템이 있다.
트랜스 코딩 vs 정적으로 미리 생성해놓기

** 참고 서적: HTTP 완벽 가이드