[http 완벽 가이드] 17장 내용 협상과 트랜스코딩

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

 

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

1. 내용 협상 기법

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

기법	어떻게 동작하는가	장점	단점
클라이언트 주도	클라이언트가 요청을 보내면 서버는 클라이언트에게 선택지를 보내주고 클라이언트가 선택	서버 입장에서 가장 구현하기 쉽다. 클라이언트는 최선의 선택 가능	대기시간 증가, 콘텐츠 얻기 위한 최소 두번의 요청 필요
서버 주도	서버가 클라이언트의 요청 헤더를 검증해, 어떤 버전을 제공할지 결정	클라이언트 주도 협상보다 빠름, q값 메커니즘 제공, vary 헤더 제공	헤더에 맞는것이 없으면 서버는 추측을 해야함
투명	투명한 중간 장치(프락시 웹 캐시)가 서버를 대신하여 협상	웹 서버가 협상을 할 필요 없음, 클라이언트 주도 협상보다 빠름	정확한 명세가 없음

2. 클라이언트 주도 협상

• 서버에게 있어 가장 쉬운 방법은 서버가 클라이언트의 요청을 받았을 때 가능한 페이지의 목록을 응답으로 돌려주어 클라이언트가 보고 싶은 것을 선택하게 하는 것이다.
• 이 방법은 가장 구현하기 쉽고 최선의 사본이 선택될 것이다.
• 단점은 각 페이지에 두 번의 요청이 필요하다는 것이다.
• 한번은 목록을 얻고 두 번째는 선택한 사본을 얻는다.
• 이것은 느리고 지루한 과정이고, 클라이언트에게는 짜증나는 일이 될 것 이다.

3. 서버 주도 협상

• 클라이언트 주도 협상은 전 절에서 이야기한 바와 같이 몇 가지 단점이 있다.
• 이 단점들 대부분은 요청에 대한 응답으로 돌려줄 최적의 페이지를 결정하기 위한 클라이언트와 서버 사이의 커뮤니케이션을 증가시킨다.
• 이런 추가 커뮤니케이션을 줄이기 위한 한 가지 방법은 서버가 어떤 페이지를 돌려줄 것인지 결정하게 하는 것이다.
• 그러나 이렇게 하려면 클라이언트는 반드시 자신의 무엇을 선호하는지에 대한 충분한 정보를 서버에게 주어서 서버가 현명한 결정을 할 수 있게 해 주어야 한다.

내용 협상 헤더

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

Accept 관련 헤더	엔터티 헤더
Accept	Content-Type
Accept-Language	Content-Language
Accept-Charset	Content-Type
Accept-Encoding	Content-Encoding
- HTTP 는 상태가 없는 프로토콜이기 때문에, 클라이언트는 자신의 선호 정보를 반드시 매 요청마다 보내야 한다.
- 다행이도 HTTP는 앞의 스페인 사람과 같은 클라이언트를 위해 그들의 선호에 대한 풍부한 설명을 품질값을 이용해 전달할 수 있는 매커니즘을 제공한다.

3.2 내용 협상 헤더의 품질값

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

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

4. 투명 협상

• 투명 협상은 클라이언트 입장에서 협상하는 중개자 프락시를 둠으로써 클라이언트와 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 서버에서 제거한다.
• 만약 서버가 그들의 캐시에 대한 의사결정 프로세스를 캐시에게 알려주었다면, 캐시는 서버의 입장에서 클라이언트와 협상할 수 있다.
• 캐시는 또한 콘텐츠를 트랜스코딩하기에 훌륭한 장소인데, 캐시 안에 설치되어 있는 범용 트랜스코더는 특정 서버에 국한되지 않고 어떤 서버의 콘텐츠든 트랜스코딩할 수 있기 때문이다.

4.1 캐시와 alternate

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

5. 트랜스 코딩

• 우리는 지금까지 클라이언트와 서버가 협상을 통해 어떤 URL이 가리키는 문서들중에서 클라이언트의 요구에 가장 잘 맞는 것 하나를 선택해 보내줄 수 있는 메커니즘에 대해 꽤 자세히 이야기 했다.
• 이 메커니즘은 클라이언트의 요구에 맞는 문서가 존재해야 동작한다.

5.1 포맷 변환

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

5.2 정보 합성

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

5.3 콘텐츠 주입

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

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

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