HTTP - 내용 협상과 트랜스 코딩

내용 협상이 무엇이냐

예를 들어 우리 사이트의 주 고객이 영어 사용자와 프랑스어 사용자 양측이 존재한다면, 우리는 사용자에 맞게 콘텐츠를 제공해줘야 한다.

HTTP는 이런 판단이 가능하게 내용협상이란 방법을 제공한다.

이 방법은 하나의 URL이 여러 가지 리소스 중 적합한 것을 제공하도록 할 수 있다. 여기서는 서로 다른 버전을 배리언트( Variant ) 라고 부른다

서버가 클라이언트의 요청을 받았을 때 가능한 페이지의 목록을 응답으로 돌려주어

클라이언트가 보고 싶은 것을 선택하게 하는 방법입니다.

장점: 서버 입장에서 구현하기 가장 쉬운 방법으로, 최선의 사본이 선택됩니다.

단점: 각 페이지에 두 번의 요청(목록 요청, 선택한 사본 요청)이 필요해 시간이 오래 걸립니다.

→ 클라이언트의 입장에서 화를 유발할 수 있습니다.

클라이언트 주도 협상에는 위와 같이 커뮤니케이션 관련 단점이 존재했습니다.

서버 주도 협상은 서버가 어떤 페이지를 돌려줄 것인지 결정해서 이러한 단점을 보완하고자 했습니다. 대신, 서버가 선택할 수 있게끔 클라이언트는 무엇을 선호하는지에 대한 정보를 서버에게 제공하는데, 아래의 두 가지 메커니즘을 사용합니다.

내용 협상 헤더: 내용 협상 헤더들을 살펴보고, 서버는 클라이언트의 Accept 관련 헤더들을 확인 후 알맞은 응답 헤더를 준비
내용 협상 헤더 외의 다른 헤더를 살펴보고, (예- User-Agent 헤더 기반) 응답을 준비

투명 협상은 중간에 프락시를 두면서 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 서버에서 제거한다.

프락시는 클라이언트의 기대를 파악하고, 클라이언트와 협상할 수 있는 능력이 있다고 간주되는데, 서버는 프락시에게 Vary 헤더를 통해 어떤 조건을 확인해야 하는지를 알려줄 수 있다.

캐시 프락시가 만일 서버의 의사결정 프로세스를 알게 된다면, 캐시는 서버의 입장에서 협상을 진행할 수도 있다.

캐시는 클라이언트에게 올바른 응답을 주기 위해 서버가 응답을 돌려줄 때 사용했던 의사결정 로직의 상당부분을 그대로 사용해야 한다.

캐시는 똑같은 리소스에 대하여 다른 버전을 동시에 가질 수 있도록, 이번의 응답과 저번의 응답을 모두 저장한다.

제공된 문서가 의존하고 있는 헤더를 포함하여 돌려준다.

캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 한다. 캐시가 검색을 할 때 먼저 내용 협상 헤더로 적합한 콘텐츠를 맞춰보고, 요청의 배리언트를 캐시된 배리언트와 맞춰본다.

맞는 것이 없다면 서버에서 가져온다.

http Vary 응답 헤더는
서버가 문서를 선택하거나, 커스텀 콘텐츠를 생성할 때 고려한
클라 요청 헤더 모두를 나열한다.
새 요청이 도착했을 때, 캐시는 내용 협상 헤더들을 이용해 가장 잘 맞는 것을 찾는다.
캐시는 반드시 캐시된 응답 안에 서버가 보낸 Vary 헤더가 들어있는지 확인하고,
Vary 헤더가 명시하고 있는 헤더들은
새 요청과 오래된 캐시된 요청에서 그 값이 서로 맞아야만 한다.
서버는 클라의 요청 헤더에 따라 그들의 응답이 달라질 수 있기 때문에
투명 협상을 구현하기 위해 캐시는 반드시
캐시된 variant와 함께
클라 요청 헤더와
그에 알맞은 서버 응답헤더 양쪽 모두를 저장해야한다.