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

동일한 URL에 대해 클라이언트의 선호 언어, 브라우저 종류 등에 따라 적절한 컨텐츠를 반환하게 하는 방법 클라이언트 주도 협상, 서버 주도 협상, 투명 협상 등의 방법이 있다. 클라이언트와 서버는 이를 판단하기 위해 내용 협상 헤더와 기타 헤더를 사용한다. 또한, 캐시나 변환기 등을 두어 서버 대신 협상을 하도록 하고, 서버의 부하를 줄이기도 한다.

클라이언트 주도 협상

• 클라이언트가 요청 -> 서버는 제공할 수 있는 리소스 목록을 제공 -> 클라이언트가 리소스 선택 -> 서버는 선택된 리소스를 반환
• 장점: 구현하기 쉽다. 클라이언트가 자신이 원하는 리소스를 직접 선택한다.
• 단점: 요청이 두 번 필요. 리소스별로 URL을 요구한다.

서버 주도 협상

• 클라이언트가 자신의 내용 협상 헤더에 선호 정보를 담아 요청 -> 서버는 클라이언트 요청 헤더의 내용으로 최선의 리소스를 추측하여 리소스 제공
• HTTP는 상태가 없는 프로토콜이기 때문에, 클라이언트는 자신의 선호 정보를 반드시 매 요청마다 보내야 한다.
• 장점: 요청이 한 번으로 줄었다.
• 단점: 클라이언트가 지목한 리소스가 없다면, 서버는 나름대로 추측해야 한다.

내용 협상 헤더

• 품질값(q)도 지원한다.

그 외의 헤더

• User-Agent: 자바스크립트를 지원하지 않는 브라우저 -> 자바스크립트 삭제한 HTML
• Vary

아파치의 내용 협상

• 콘텐츠 제공자는 각각의 버전에 해당하는 파일을 아파치 서버으 적절하 디렉터리에 모두 넣는다.
• 둘 중 한 가지 방법으로 내용 협상을 한다.
  • type-map 파일을 직접 만든다.
  • type-map 파일을 자동으로 만들어주는 MultiView 지시어를 켠다.

투명 협상

• 중간에 프락시를 두어 클라이언트와 서버 간의 내용 협상을 대신하게 한다.
• 클라이언트와 서버 간의 통신을 줄여준다.
• 캐시 프락시 사용을 위해서는 기존과 동일한 요청인 지 항상 판단행 하며
  • 기존과 동일한 요청이 온 경우, 캐시된 리소스를 반환한다.
  • 기존과 다른 요청이 온 경우, 서버가 직접 리소스를 판단하여 반환한다.
  • 이 때, 캐시 프락시는 반환된 응답을 저장하고, 다음 동일한 요청이 있을 경우 재사용한다.
• Vary 헤더를 통해 기존과 동일한 요청인 지 판단하는 데
  • Vary 헤더에 나열된 요청 헤더의 종류와 그 값 별로 서버의 리소스를 캐시한다.

트랜스코딩

• 서버가 클라이언트의 요구에 맞는 리소스를 갖고 있지 않다면
  • 서버는 에러 응답을 내보내거나
  • 서버는 리소스를 변환하여 클라이언트에게 제공한다. <– 트랜스코딩
• 포맷 변환(HTML -> WML, 고해상도 이미지 -> 저해상도 이미지), 정보 합성(제목에 기반한 개요 생성, 광고 및 로고 제거), 콘텐츠 주입(자동광고생성, 사용자 추적) 등의 방법이 있다.
• 트랜스코딩 대신 페이지를 미리 정적으로 생성해놓는 방법도 있다.
  • 변화에 유연하지 않고, 각 버전을 저장하기 위해 더 많은 메모리를 필요로 하여 관리 비용이 많이 든다.
• 트랜스코딩은 동적으로 변환하지만, 이로 인한 응답 대기 시간 증가라는 문제가 생길 수 있다.
  • 하지만, 이는 제3자(프락시)에게 수행하게 하여 이런 부담을 줄 일 수 있다.