NOTE

클라이언트의 선호도를 q 값을 통하여 하나의 URL이 여러 리소스에 대응할 필요가 있는 경우, 어떤 리소스를 선택할지 결정한다.

키워드#

Content-negotitation, 클라이언트 주도 협상, 서버 주도 협상, 내용 협상 헤더

메모 및 핵심 요점#

• 하나의 URL이 여러 리소스에 대응할 필요가 있는 경우 ⇒ HTTP에서 content-negotiation을 제공
  • 예시: 콘텐츠를 여러 언어로 제공
• 트랜스코딩: 서버가 커스터마이징된 페이지를 자동 생성, HTTP 클라이언트와 서버 사이의 내용 협상에 대한 응답에서 수행됨.
• 내용 협상 기법
  • 종류: 클라이언트 주도 협상(클라이언트에게 선택지를 준다), 서버 주도 협상(서버가 자동으로 판단한다), 투명한 협상(중개자에게 선택하도록 한다)
  • 클라이언트 주도 협상: 클라이언트가 보고 싶은 콘텐츠를 선택
    • 방법 : 서버가 여러 가지 버전에 대한 링크와 설명이 담긴 html 페이지를 돌려주거나, 300 Multiple Choices 응답 코드로 HTTP/1.1 응답을 돌려줌
    • 장점 : 서버 입장에서 가장 구현하기 쉽고, 사용자가 원하는 최선의 사본이 선택됨
    • 단점
      • 각 페이지에 두 번의 요청이 필요함 (한 번 : 서버에서 보여줄 목록에 대한 요청, 두 번: 선택한 사본에 대한 요청)
      • 여러 개의 URL(주 페이지 + 특정 조건별 URL)을 요구
  • 서버 주도 협상 : 서버가 어떤 페이지를 돌려줄 지 결정. 이 경우, 클라이언트는 자신이 무엇을 선호하는지에 대한 정보를 요청 헤더로 서버에 제공해야 함
    • 매커니즘 : 1. 내용 협상 헤더 살펴보기 (Accept 관련 헤더) 2. 내용 협상 헤더 외의 다른 헤더들 살펴보기 (예를 들어 User-agent 헤더)
  • 투명 협상 : 클라이언트 입장에서 협상하는 중개자 프락시를 사용. HTTP/1.1 명세에 해당 매커니즘은 정의되어 있지 않으나, 사용할 경우 일반적으로 vary 헤더를 통해 구현한다.
• 내용 협상 헤더
  • Accept (미디어 타입), Accept-Language (언어), Accept-Charset (차셋), Accept-Encoding (인코딩)
  • 엔터티 헤더와의 차이점 : 엔터티 헤더는 body에 대한 정보를 기술하는 헤더이고,내용 협상 헤더는 콘텐츠 협상에 관련한 내용을 제공해 준다.
  • HTTP의 stateless 한 특성 때문에 (서버는 클라이언트가 이전 요청에서 보낸 선호 정보를 기억하지 않으므로), 클라이언트는 자신의 선호 정보를 반드시 매 요청마다 보내야 한다.)
  • 내용 협상 헤더의 품질 값 : 클라이언트의 선호도를 q 값을 통하여 표시(RFC 2295). (0.0 이 가장 낮은 선호도, 1.0이 가장 높은 선호도), 클라이언트의 선호에 대응하는 문서가 없는 경우, 서버는 문서를 고치거나 트랜스코딩 함.
    • ‘최선’에 가장 가까운 대응을 찾아낼 수 있는 q값 매커니즘이 없을 경우, 서버의 구현에 달려 있음 (서버가 대응을 찾거나, 그냥 가지고 있는걸 제공하거나)
• Vary 헤더 : HTTP 컨텐츠 협상과 캐시 관리를 지원하기 위해 사용되는 헤더. 이 헤더를 통하여, 협상 과정에서 특정 헤더를 기반으로 컨텐츠를 선택하는데 사용 (서버가 문서를 선택하거나 커스텀 콘텐츠를 생성할 때 고려한 클라이언트 요청 헤더 모두를 나열함)
  • Vary 헤더가 존재한다면, 그 vary 헤더가 명시하고 있는 헤더들은 새 요청과 오래된 캐시된 요청에서 그 값이 서로 맞야아 한다.
  • 예시) Vary: Accept-Encoding 헤더는 서버가 응답을 압축하여 전송하는 경우에 사용되며, 클라이언트의 Accept-Encoding 헤더와 일치하는 캐시된 응답만 사용할 수 있다.
• 트랜스코딩
  • 서버가 기존 문서를 클라이언트의 요구에 맞는 문서로 변환하는 방법
  • 종류 : 포맷 변환, 정보 합성, 내용 주입

스터디에서 배운 내용#

• HTTP/2, HTTP/3에서의 컨텐츠 협상
  • Alt-Svc : 서로 다른 프로토콜을 사용하는 리소스에 대한 컨텐츠 협상을 가능하게 함. (서버 → 클라이언트로 전송되고, 서버에서 지원하는 프로토콜 버전 및 endpoint를 포함)
    • 이 헤더는 클라이언트와 서버 간의 직접적인 컨텐츠 협상과는 관련이 없지만, 프로토콜 버전 및 엔드포인트의 변경 사항을 통보하므로, 새로운 프로토콜 버전을 사용할 수 있는지 여부를 결정하는데 사용함.
    • 프록시에서도 Vary헤더 처럼 서로 다른 프로토콜 버전을 사용하는 리소스에 대한 컨텐츠 협상을 가능하게 함.

인용#

다행히도, HTTP는 클라이언트와 서버가 이러한 판단을 할 수 있도록 내용 협상(content-negotiation) 방법을 제공한다. 이 방법을 이용해서 하나의 URL이 여러 가지 리소스 중 적합한 것에 대응되도록 할 수 있다(예: 같은 웹페이지의 프랑스어와 영어 버전). 여기서는 서로 다른 버전을 배리언트(variant)라고 한다. (457p)

이런 추가 커뮤니케이션을 줄이기 위한 한 가지 방법은 서버가 어떤 페이지를 돌려줄 것인지 결정하게 하는 것이다. 그러나 이렇게 하려면 클라이언트는 반드시 자신의 무엇을 선호하는지에 대한 충분한 정보를 서버에게 주어서 서버가 현명한 결정을 할 수 있게 해주어야 한다. 서버는 이 정보를 클라이언트의 요청 헤더에서 얻는다. (459p)

만약 서버의 Vary 헤더가 이렇다면, 거대한 수의 다른 User-Agent와 Cookie 값이 많은 배리언트(variant)를 만들 것이다.

Vary: User,agent, Cookie

캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 한다. 캐시가 검색을 할 때, 먼저 내용 협상 헤더로 적합한 콘텐츠를 맞춰보고, 다음에 요청의 배리언트를 캐시된 배리언트와 맞춰본다. 만약 맞는 것이 없으면, 캐시는 문서를 서버에서 가져온다. (466p)