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

17.1 내용 협상 기법

• 클라이언트 주도 (Client-Driven): 클라이언트가 요청을 보내면 서버는 선택지를 보내주고 클라이언트가 선택합니다.
• 서버 주도 (Server-Driven): 서버가 클라이언트 요청 헤더를 검증하여 어떤 버전을 제공할지 결정합니다.
• 투명 (Transparent): 투명한 중간 장치(주로 프락시 캐시)가 서버를 대신하여 협상합니다.

17.2 클라이언트 주도 협상

가능한 페이지의 목록을 서버 응답으로 돌려주어 클라이언트가 보고 싶은 것을 선택하게 하는 방식입니다.

• 장점: 구현이 간단하고 클라이언트가 명시적으로 선택할 수 있습니다.
• 단점: 각 페이지에 두 번의 요청이 필요하므로 성능 저하가 발생할 수 있습니다.
• 구현 방법:
  • 서버는 클라이언트에게 선택지를 표현하기 위해 각 링크와 설명이 담긴 HTML 페이지를 응답으로 돌려줍니다.
  • 또는 300 (Multiple Choices) 응답 코드를 사용하여 선택 가능한 리소스 목록을 클라이언트에게 제공합니다.

예시: 웹 사이트에서 영어와 한국어 버전을 제공하는 경우, 사용자가 처음 접속했을 때 언어 선택 페이지를 보여주고 원하는 언어를 선택하도록 하는 방식입니다.

 

17.3 서버 주도 협상

 

클라이언트 주도 협상의 경우, 최적의 페이지를 결정하기 위한 클라이언트와 서버 사이의 커뮤니케이션을 증가시킵니다. 서버는 클라이언트 요청 헤더에서 충분한 정보를 얻어 클라이언트에게 보내줄 적절한 응답을 계산합니다.

내용 협상 헤더를 살펴보고 서버는 그에 알맞는 응답 헤더를 준비합니다. 내용 협상 헤더 외에 User-Agent 헤더에 기반하여 응답을 보내줄 수 있습니다.

 

17.3.1 내용 협상 헤더

클라이언트는 HTTP 헤더를 이용해서 자신의 선호 정보를 보낼 수 있습니다.

• Accept: 클라이언트가 처리할 수 있는 미디어 타입(MIME 타입)을 나타냅니다. 예를 들어, text/html, application/json, image/* 등이 있습니다.
• Accept-Language: 클라이언트가 선호하는 자연어(언어)를 나타냅니다. 예를 들어, ko-KR, en-US, fr 등이 있습니다.
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩을 나타냅니다. 예를 들어, utf-8, iso-8859-1 등이 있습니다.
• Accept-Encoding: 클라이언트가 선호하는 콘텐츠 인코딩(압축 방식)을 나타냅니다. 예를 들어, gzip, deflate, br 등이 있습니다.

 

Accept 헤더들은 엔터티 헤더(Content-Type, Content-Encoding)와는 다릅니다. 메시지 본문의 속성을 가리키는 것이 아니라 서버와 선호 정보를 교환하고 문서들의 여러 버전 중 하나를 선택하는 것을 도와 잘 맞는 문서를 제공해 주기 위한 목적으로 사용됩니다. HTTP는 상태가 없는 프로토콜이므로 클라이언트는 자신의 선호 정보를 매 요청마다 보내야 합니다.

 

17.3.2 내용 협상 헤더의 품질값

q값, 0부터 1.0까지의 값을 추가하여 옵션에 대한 선호도를 추가할 수 있습니다.

 

예시:

• Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
  • 한국어(ko-KR)를 가장 선호하며, 그 다음은 한국어(ko), 미국 영어(en-US), 일반 영어(en) 순으로 선호합니다.

 

17.3.3 그 외의 헤더들에 의한 결정

서버가 최선에 가까운 대응을 찾아낼 수 있는 메커니즘은 따로 없고 서버의 구현에 달려있습니다.

17.3.4 아파치의 내용 협상

아파치 웹 서버가 내용 협상을 지원하는 방법은 다음과 같습니다.

• type-map 파일을 만들어서 variant를 갖는 웹 사이트의 각 URI를 담습니다.
• 아파치 서버는 서버 설정 파일에 type-map 파일들을 위한 핸들러를 추가합니다.

17.3.5 서버 측 확장

서버에서 자체적으로 내용 협상 로직을 구현하여 클라이언트의 다양한 요청에 유연하게 대응할 수 있습니다.

17.4 투명 협상

 

클라이언트 입장에서 협상하는 중개자 프락시를 둠으로써 서버 주도 협상으로 인한 부하를 제거하는 방법입니다. 서버는 응답에 Vary 헤더를 포함시켜 중개자에게 내용 협상을 위해 어떤 헤더를 사용하고 있는지 알려줄 수 있습니다. 캐시 프락시는 문서의 여러 다른 사본을 저장할 수 있어 서버의 입장에서 클라이언트와 협상할 수 있습니다. 캐시 안에 설치된 범용 트랜스코더는 어떤 서버의 콘텐츠든 트랜스코딩할 수 있게 합니다.

17.4.1 캐시와 얼터네이트

캐시는 서버가 응답을 돌려줄 때 사용했던 의사결정 로직의 상당 부분을 그대로 사용해야 합니다. 같은 URL이더라도 프랑스어 요청자가 요청한 경우에는 프랑스어 문서를, 스페인어 요청자가 요청한 경우에는 스페인어 문서를 내려주어야 합니다. 서버와 마찬가지로 캐시는 같은 URL에 대해 두 개의 다른 문서를 갖게 되고, 이 다른 버전은 variant나 alternate로 불립니다.

 

17.4.2 Vary 헤더

서버가 User-Agent나 Accept 이외의 다른 헤더에 기초하여 페이지를 응답한다면 콘텐츠 생성 시 고려한 클라이언트 요청 헤더 모두를 Vary 헤더에 포함해야 합니다. 캐시가 내용 협상 헤더들을 이용해 잘 맞는 것을 찾아줄 때 Vary 헤더가 명시하고 있는 값이 맞아떨어지지 않는다면 문서를 서버에서 가져오도록 해야 합니다.

 

예시:

• Vary: Accept-Language, User-Agent
  • 이 응답은 Accept-Language와 User-Agent 헤더를 기반으로 내용 협상이 이루어졌음을 나타냅니다. 캐시는 이 두 헤더의 값이 일치하는 요청에 대해서만 캐시된 응답을 제공해야 합니다.

캐시 안에 설치된 범용 트랜스코더는 어떤 서버의 콘텐츠든 트랜스코딩할 수 있게 합니다.

 

17.5 트랜스코딩

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

 

17.5.1 포맷 변환

데이터를 클라이언트가 볼 수 있도록 다른 포맷으로 변환하는 것입니다. 접속 속도가 느린 클라이언트에게는 고해상도 이미지를 흑백으로 변환하거나 해상도를 줄여줍니다. 콘텐츠 인코딩/전송 인코딩은 콘텐츠를 접근 장치에서 볼 수 있도록 하기 위함이라면, 내용 변환/트랜스코딩은 더 효율적이고 안전한 전송을 위한 것입니다.

 

17.5.2 정보 합성

문서에서 정보의 요점을 추출하는 것입니다. 각 절의 제목에 기반한 문서의 개요 생성 또는 광고 및 로고 제거 웹페이지 디렉터리와 같은 자동화된 웹페이지 분류 시스템에 의해 종종 사용됩니다.

 

17.5.3 콘텐츠 주입

오히려 콘텐츠의 양을 늘리는 내용 주입 트랜스코딩 자동 광고 생성과 사용자 추적 시스템에 쓰이며 광고를 그때그때 효과적으로 삽입하기 위함입니다.

 

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

페이지를 미리 여러 버전으로 사본을 만들어주는 방법 vs 그때 그때 변환해서 사용자에게 제공하는 것

콘텐츠 제공에 있어 대기시간 증가로 인해 비용을 초래할 수 있습니다. 이를 보완하기 위해서 트랜스코딩을 제 삼자에게 수행하게 하여 웹 서버의 부담을 덜 수 있습니다.