16. 내용협상과 트랜스코딩(1) - 내용협상
글로벌한 기업이 제공하는 웹사이트를 들어가 보면 다양한 언어를 제공해 전 세계적인 사용자들을 만족시키고 있습니다. 사용자들이 관여하지 않는 내부에서는 서버가 컨텐츠를 어떤 방법으로 사용자들에게 전달할지 역시 적절한 선택을 하게 되죠.
이렇게 HTTP가 클라이언트와 서버가 적절한 컨텐츠 종류(Variant)를 선택하게끔 내용 협상(Content-Negotiation) 방법을 제공합니다!
내용 협상 기법
서버에 있는 페이지들 중 어떤 것이 클라이언트에게 맞는지 판단하는 세 가지 다른 방법이 있습니다.
첫 번째로 클라이언트에게 선택지를 주는 방법(클라이언트 주도 협상). 두번째로 서버가 자동으로 판단하는 방법(서버 주도 협상). 마지막으로 중개자에게 선택하도록 부탁하는 방법(투명한 협상)입니다.
| 기법 | 동작 원리 | 장점 | 단점 |
| 클라이언트 주도 협상 |
1. 클라이언트가 요청 전송 (1차 요청) 2. 서버가 클라이언트에게 선택지를 전송 3. 클라이언트가 선택. (2차 요청) |
- 서버 입장에서 구현 난이도가 제일 낮음 - 클라이언트는 최선의 선택이 가능함. |
- 두번의 요청이 있기 때문에 대기 시간이 증가한다. - 충분한 선택지가 있어야 한다. |
| 서버 주도 협상 |
1. 서버가 클라이언트의 요청헤더 검증. 2. 서버는 어떤 버전을 제공할지 결정 |
- 클라이언트 주도 협상보다 빠름. | 헤더에 맞는 것이 없어 결정이 쉽지 않으면 서버는 추측을 해야 함. |
| 투명 협상 |
프록시 캐시와 같은 투명한 중간 장치가 서버를 대신해서 협상을 진행. |
- 웹 서버가 협상을 할 필요가 없음. - 클라이언트 주도 협상보다 빠름. |
투명 협상을 어떻게 하라는 정확한 명세가 없음. |
자세히 알아봅시다!
클라이언트 주도 협상
모든 일처리 중 가장 쉬운 처리 방법은 상대방에게 떠넘기는 것입니다. (추천하지는 않습니다.)
클라이언트 주도 협상은 이를 메인 메커니즘으로 동작합니다! 바로 서버가 클라이언트에게 선택을 떠넘기는 것이죠.
덕분에 서버 입장에서는 가장 구현하기 쉬운 방법이 됩니다.
주요 과정은 이렇습니다.
STEP 1. 클라이언트의 요청이 들어온다.
STEP 2. 서버는 클라이언트에게 요청에 대한 응답 가능한 페이지의 목록을 전송한다. (선택지 전송)
1) 링크와 각각 설명이 담긴 HTML을 전송
- 여기서 단점이 하나 나오는데, 바로 서버가 여러 개의 URL(주 페이지 1 + 다른 페이지)을 준비해야 한다는
것입니다.
ex : 주 페이지(tistory.com), 한국어(tistory.com/kr) 영어(tistory.com/en) 등...
2) HTTP/1.1 300 Multiple Choices 응답 코드 전송
STEP 3. 클라이언트는 목록에서 원하는 것을 선택한다.
STEP 4. 서버는 해당 컨텐츠를 전송한다.
이 협상 과정의 또 다른 단점은 다른 협상과정에서 필요 없는 과정이 두 개나 늘었다는 것입니다. (STEP2, STEP 3)
덕분에 대기 시간이 조금 더 길어지게 됩니다.
서버 주도 협상
이러한 클라이언트 주도 협상의 단점을 해결하기 위해서 서버가 제공하는 컨텐츠 버전을 결정하게 하는 것입니다.
서버 주도 협상을 이용하기 위해서는 선행되는 조건이 필요합니다. 바로 클라이언트가 자신의 선호 버전을 서버에게 제공하는 것이죠 (인코딩의 'Acept-Encoding', 국제화의 'Accept-Charset'와 같은 골자입니다.)
이러한 정보들은 모두 요청 메시지의 헤더들에게서 얻을 수 있습니다. 다시 한번 복습해보죠
| 요청 메시지에 담긴 헤더 | 설명 | 응답 엔티티 헤더 |
| Accept | 선호하는 미디어 타입을 제공 | Content-Type |
| Accept-Language | 선호하는 언어 제공 | Content-Language |
| Accept-Charset | 선호하는 차셋 제공 | Content-Type |
| Accept-Encoding | 선호하는 인코딩 알고리즘 제공 | Content-Encoding |
서버들은 이렇게 얻은 정보들을 통해 알맞은 컨텐츠들을 제공합니다.
만약 제공받은 헤더의 정보 중 어느 것도 해당되지 않는다면 서버는 어떻게 해야 할까요?
첫 번째로는, 클라이언트 주도 협상 방식과 같이 클라이언트에게 선택을 넘기는 것입니다. 그러면 확실히 클라이언트가 차선의 타입을 선택하게 되겠죠.
두 번째로는, 서버가 어떻게든 추측을 통해 콘텐츠를 제공하는 것입니다. 첫 번째 방법보다는 정확성이 떨어질 것입니다.
이러한 문제들을 방지하기 위해서 클라이언트는 최대한 많은 정보들을 서버에게 제공해야 합니다.
어느 것도 해당되지 않는 경우를 상정해 선호도를 나타내는 품질 값(quality value)을 이용해 전달할 수 있다고 했었습니
다.(국제화 편 참고)
Accept-Language: kr;q=1.0, en;q=0.8, jp;q=0.3사실 이러한 선호도를 제공한다 하더라도 최선을 선택하는 q값 메커니즘은 존재하지 않기 때문에, 서버는 자신이 어떤 것을 기준으로 제공하는지에 대한 명확한 정보를 추가로 제공해야 합니다. 이러한 정보들은 응답 메시지의 'Vary' 헤더에 담아 다운스트림 서버들에게 제공하게 됩니다.
투명 협상
클라이언트 입장에서 협상하는 중개자 프록시를 두어 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 제거하는 방법입니다.
프록시는 클라이언트가 무엇을 선호하는지 알고 있으며(Accept 헤더), 클라이언트의 입장에서 협상을 수행할 수 있는 능력이 있어야 하고 어떤 요청 헤더를 검사해야 하는지에 대한 정보(Vary 헤더)를 서버에게 얻어야 합니다.
캐시 안에 설치된 트랜스코더는 특정 서버에 국한되지 않고 어떤 서버의 컨텐츠든 트랜스 코딩할 수 있기 때문에 트랜스 코딩하기에도 유리합니다.
1. 캐시와 얼터네이트
캐시는 결국 서버의 대체제이기 때문에, 서버가 응답을 돌려줄 때 사용했던 판단 로직의 상당 부분을 그대로 사용해 캐시 된 컨텐츠를 클라이언트에게 빠르게 넘겨주어야 합니다.
난감한 상황을 한번 가정해봅시다.
최초로 영어권 사용자가 tistory 홈페이지를 요청했다고 합시다. 적절한 Accept 헤더와 판단 로직으로 tistory.com/en URL 컨텐츠를 제공하게 됩니다. 프록시는 그대로 캐시를 하게 되고요.
다음에는 한글 사용자가 tistory 홈페이지를 요청했다고 합시다. 캐시는 이전에 영어권 사용자가 제공한 Accept 헤더와 굉장히 유사했고 이를 판단 로직에 돌린 결과 tistory.com/en 이 적합하다 판단해 제공을 하게 됩니다.
하지만 서버에는 더 적합한tistory.com/kr 이 존재합니다!
이런 상황을 방지하기 위해 캐시는 반드시 요청을 자신이 응답을 하는 것이 아닌 서버에게 전달해 다른 응답을 전달할 수 있어야 합니다.
또한 그 응답 역시 캐싱을 해두어야 합니다. 이렇게 같은 URL에 대한 다른 버전의 문서들을 배리언트(Variant)나 얼터네이트(alternate)라고 합니다. 따라서 캐시의 내용 협상은 이러한 variant 중에서 클라이언트의 요청에 가장 적합한 것을 선택하는 과정이라 설명할 수 있습니다.
2. Vary 헤더
Vary 헤더는 캐시 된 응답을 향후 추가 요청들에서 원 서버로 요청하기 전 사용할 수 있는지의 여부를 결정하는 헤더입니다. 그렇기 때문에 서버는 반드시 캐시에게 Vary 헤더를 제공해 나중에 있을 요청들에 대한 적절한 응답 컨텐츠를 만들 수 있도록 해야 합니다.
문서가 User-Agent 헤더에 의존해 컨텐츠 버전을 고른다면 서버는 이러한 Vary 헤더를 제공할 것입니다.
Vary: User-Agent
마지막으로 내용 협상에서의 캐시의 동작 과정을 정리해봅시다!
STEP 1. 새 요청이 도착했을 때, 캐시는 내용 협상 헤더(Accept) 들을 이용해 적합한 컨텐츠를 찾는다.
- 추가적으로 요청 헤더 저장
STEP 2. 캐시 된 응답 안에 서버가 보낸 Vary 헤더가 들어가 있는지 확인 후. 내용 협상 헤더와 비교
- 일치 : 그대로 캐시 된 컨텐츠 제공
- 불일치 : 원 서버에게 컨텐츠 요청 후 사용자에게 제공 (+컨텐츠와 Vary헤더 캐싱)
다음 장에서는 클라이언트의 요구에 맞는 문서를 아예 가지고 있지 않은 경우에 사용되는 트랜스코딩에 대해 배워봅시다!