이 장에서는 언어가 다른 사용자(영어와 프랑스어)가 한 페이지에 접근했을 때, 어떤 페이지를 내려주어야 할 것인지와 관련한 내용 협상과 트랜스코딩에 대한 이야기를 다룬다.
내용 협상 기법
서버에 있는 페이지들 중 어떤 것이 클라이언트에게 맞는지 판단하는 3가지 방법
- 클라이언트에게 선택지를 주는것 → 클라이언트 주도 협상
- 서버가 자동으로 판단하는 방법 → 서버 주도 협상
- 중개자에게(프락시) 선택하도록 부탁하는 방법 → 투명 협상
클라이언트 주도 협상
이 방법은 클라이언트가 요청을 보냈을 때, 서버가 클라이언트에게 선택지를 보내주고, 클라이언트가 선택하게 하는 방법이다.
😎 장점
서버 입장에서 가장 구현하기 쉽고 최선의 사본을 선택할 수 있음
❗️단점
두 번의 요청(목록과 선택된 사본)이 필요하다.
즉 증가된 대기시간과 페이지당 여러 번의 요청이 필요하며, 여러 개의 URI을 요구한다.
서버 주도 협상
서버가 클라이언트의 요청 헤더를 검증해서 어떤 버전을 제공할지 결정한다.
이를 위해 다음과 같은 정보를 살펴본다.
- 내용 협상 헤더(Accept 관련 헤더)
- 내용 협상 헤더 외의 다른 헤더(ex: User-Agent)
😎 장점
클라이언트 주도 협상보다 빠르다.
❗️단점
어떤 버전을 제공할지 판단하기 위한 헤더의 정보가 부족하다면, 서버는 추측을 해야한다.
내용 협상 헤더
| 헤더 | 설명 |
|---|---|
| Accept | 서버가 어떤 미디어 타입으로 보내도 되는지 알려준다. |
| Accept-Language | 서버가 어떤 언어로 보내도 되는지 알려준다. |
| Accept-Charset | 서버가 어떤 차셋으로 보내도 되는지 알려준다. |
| Accept-Encoding | 서버가 어떤 인코딩으로 보내도 되는지 알려준다. |
15장에서 본 엔터티 헤더와 비슷한데, 엔터티 헤더는 선적 화물에 붙이는 라벨과 비슷하다.
엔터티 헤더는 메시지를 서버에서 클라이언트로 전송할 때 필요한 메시지 본문의 속성을 가리킨다.
따라서 서버는 클라이언트의 Accept 관련 헤더들을 적절한 엔터티 헤더들과 짝을 지어준다.
| Accept 관련 헤더들 | 엔터티 헤더 |
|---|---|
| Accept | Content-Type |
| Accept-Language | Content-Langugage |
| Accept-Charset | Content-Type |
| Accept-Encoding | Content-Encoding |
내용 협상 헤더의 품질값
클라이언트가 각 선호의 카테고리마다 여러 선택 가능한 항목을 선호도와 함께 나열할 수 있도록 품질값을 정의하였다.
Accept-Language: en;q=0.5, fr:q=0.0, nl;q=1.0, tr;q=0.0이를 통해 선호하는 문서를 판별하여 보내주고, 그러한 문서를 가지고 있지 않다면 서버는 클라이언트의 선호에 맞추기 위해 문서를 고치거나 트랜스코딩할 수 있다.
그 외의 헤더들에 의해 결정
서버는 또한 User-Agent와 같은 클라이언트의 다른 요청 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있다.
그리고 캐시에서는 Vary 헤더를 통해 서버가 내줄 응답의 최선의 버전을 결정하기 위해 어떤 요청 헤더를 참고하고 있는지 말해준다.
투명 협상
클라이언트 입장에서 협상하는 중개자 프락시를 둠으로써 투명한 중간 장치(주로 프락시 캐시)가 서버를 대신하여 협상을 한다.
이를 위해 Vary헤더를 통해 서버는 클라이언트의 요청중 어떤 헤더를 검사해야 하는지 프락시에게 말해준다.
서버는 응답에 Vary 헤더를 포함시켜 보냄으로써 중개자에게 내용 협상을 위해 어떤 헤더를 사용하고 있는지 알려줄 수 있다.
😎 장점
웹 서버가 협상을 할 필요가 없다. 클라이언트 주도 협상보다 빠르다.
❗️단점
투명 협상을 어떻게 하는지에 대한 정형화된 명세가 없다.
캐시와 얼터네이트(alternate)
다음과 같은 상황을 보자.
프랑스어 사용자 -----------> 캐시 ----------> 웹서버
프랑스어 사용자 <---- 프랑스어 캐시 문서 <------ 웹서버다음과 같은 상황에선 캐시된 문서를 바로 주기만 하면된다.
스페인어 사용자 -----------> 캐시 ----------> 웹서버
스페인어 사용자 <--X- 프랑스어 캐시 문서 <------ 웹서버
(스페인어 문서 캐시 필요)
그러나 위와 같은 경우 프랑스어 캐시 문서를 주면 잘못된 동작이 되고, 스페인어 문서를 웹 서버에서 가져와 보내고, 캐시에 저장해야한다.
이런 경우, 캐시에는 2가지 문서가 존재하게 되는데 이 다른 버전은 배리언트나 얼터네이트로 불린다.
Vary 헤더
Vary 헤더는 서버가 문서를 선택하거나 커스텀 콘텐츠를 생성할 때 고려한 클라이언트 요청 헤더 모두를 나열한다.
Vary 헤더 예시
Vary: User-Agent, CookieVary 헤더 사용 예시
→ 어떤 사용자는 최신의 브라우저를 사용하고 있다면 미디어가 많은 버전의 콘텐츠를 보내고 빈약한 모바일 브라우저를 사용하고 있다면 단순한 텍스트 콘텐츠를 보냄
책의 그림 17-2 참고!
트랜스 코딩
서버가 클라이언트의 요구에 맞는 문서를 아예 가지고 있지 않을때, 서버는 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환하는 것을 트랜스 코딩이라고 한다.
가상의 트랜스코딩 예시
| 전 | 후 |
|---|---|
| HTML 문서 | WML 문서 |
| 고해상도 이미지 | 저해상도 이미지 |
| 64K색 이미지 | 흑백 이미지 |
| 프레임을 포함한 복잡한 페이지 | 프레임이나 이미지가 없는 단순한 텍스트 페이지 |
| 자바 애플릿이 있는 HTML 페이지 | 자바 애플릿이 없는 페이지 |
| 광고가 있는 페이지 | 광고가 없는 페이지 |
포맷 변환
데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것이다.
내용 변환 or 트랜스코딩: 콘텐츠를 특정 접근 자잋에서 볼 수 있도록 하기 위함
콘텐츠 인코딩 or 전송 인코딩: 콘텐츠의 더 효율적인 혹은 안전한 전송을 위함
정보 합성
문서에서 정보의 요점을 추출하는 것을 정보 합성이라고 한다.
콘텐츠 주입
위의 2가지 트랜스코딩은 일반적으로 웹 문서의 양을 줄이지만, 오히려 양을 늘리는 종류의 변환은 내용 주입 트랜스코딩이라는 것도 있다.
페이지에 동적으로 콘텐츠를 추가함
ex) 자동 광고 생성과 사용자 추적 시스템
트랜스 코딩 vs. 정적으로 미리 생성해 놓기
정적으로 미리 생성해 둔다면 작은 변화로 인한 수정과 저장하기 위한 많은 공간, 페이지 관리 측면이 어려워진다.
따라서 트랜스 코딩으로 그때마다 변환시키는 것이 더 쉬운 해결책이다.
다음 단계
내용 협상에 대한 이야기는 아래 2가지 이유로 Accept나 Content 관련 헤더들에서 끝나지 않는다.
- HTTP의 내용 협상은 성능 제약을 초래한다.
여러 베리언트를 탐색하는 비용이 클 수 있다.
- HTTP는 내용 협상이 필요한 유일한 프로콜이 아니다.
미디어 스트리밍과 팩스는 이러한 내용 협상이 필요한 두 가지 다른 예다.
