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

URL 하나로 여러 리소스를 보여줘야하는 상황이 있다.

예를 들어 내 웹사이트를 영어권 고객과 한국권 고객 모두를 보유하고 있을 경우, 웹 사이트에 접속시 각 언어별로 보여줘야한다.

이 역할을 HTTP의 '내용협상' 기능이 담당하고 있다.

또한 서버는 특정 URL에 담길 콘텐츠에 대해서도 커스터마이징이 가능하다.

예를 들어 휴대용 단말기에 맞게끔 프론트를 변환한다든지 등이 해당한다.

이를 '트랜스코딩'이라고 한다.

​

오늘은 내용 협상과 어떻게 웹 어플리케이션이 내용 협상을 수행하는지, 그리고 그 과정에서 '트랜스코딩'을 어떻게 진행하는지 살펴볼 것이다.

---

내용 협상

내용 협상은 세 가지 방법을 제공한다. 클라이언트에게 선택지를 주거나, 서버가 자동으로 판단하거나, 혹은 중개자가 선택한다.

각각 클라이언트 주도 협상, 서버 주도 협상, 투명한 협상 이라고 불린다.

​

클라이언트 주도 협상은 서버가 가장 구현하기 쉽다는 장점이 있지만, 대기 시간이 증가할 수 있다는 단점이 있다.

각 페이지에 대해 두 번의 요청이 오가야하는데, 첫 번째로 선택 가능한 목록을 부여받고, 두 번째는 선택한 것에 대한 사본을 받아야한다.

​

서버 주도 협상은 클라이언트 주도 현상보다 빠르나, 서버가 적절한 선택지를 고를 수 있는 판단력이 있어야한다.

이렇게 서버가 주도적으로 선택지를 고르기 위해서는 클라이언트가 어떤 페이지를 선호하는지에 대한 정보가 필요하다.

이 정보는 클라이언트의 요청 헤더에 담겨 있는데, 서버는 내용 협상 헤더들을 살펴보아 그에 맞는 응답 헤더를 준비한다.

내용 협상 헤더들로는 아래와 같이 있다.

- Accept : 서버가 어떤 미디어 타입으로 보내도 되는지

- Accept-language : 서버가 어떤 언어로 보내도 되는지

- Accept-Charset : 서버가 어떤 charset으로 보내도 되는지

- Accept-Encoding : 서버가 어떤 인코딩으로 보내도 되는지

서버는 이 헤더에 대한 응답을 위 순서대로 각각 Content-type, Content-Language, Content-type, Content-Encoding으로 매핑한다.

클라이언트는 HTTP의 특성상(stateless, 상태가 없음) 매 요청마다 선호 정보를 보내야만 한다.

하지만 이 기법의 단점은, 위 상황에서 language로 서버가 지원하는 언어 외에 다른 선호 언어를 보내게 될 경우,

서버가 기량껏 알아서 언어를 선택해서 보내야한다. (ex. 스페인어 요청이 들어왔을 때, 영어를 보내줄 것인지 한국어를 보내줄 것인지)

이 선택을 위해서 내용 협상 헤더에는 품질값(q)이 함께 포함되어 있다.

ex) Accept-Language : en;q=0.5, fr;q=0/0, nl;q=1.0, tr;q=0.0

​

아파치 웹 서버에서 내용 협상을 제공하는 방법에 대해 간략히 다루어 보자면,

웹 콘텐츠 제공자가 색인 페이지를 여러 버전으로 제공해주고자 한다면, 각 버전에 해당하는 파일을 디렉토리 안에 넣어두어야한다.

이 디렉토리 내에 배리언트(variant)를 갖는 웹사이트의 각 URI를 위한 type-map을 생성한다.

우선 서버 설정 파일에 AddHandler type-map .var 와 같이 .var확장자를 지닌 파일들이 type-map임을 명시해주는 라인을 추가한다.

그 뒤 type-map파일은 아래와 같은 형태로 구성한다.

-----------------------

URI : joes-hardware.html

​

URI : joes-hardware.en.html

Content-type : text/html

Content-Language : en

...

-----------------------

이 파일을 통해 아파치 서버는 클라이언트에게 적절한 파일을 보내게 된다.

​

​

투명한 협상은 서버가 협상할 필요가 없다는 장점이 있지만, 어떻게 진행한다는 것에 대한 정형화된 규칙이 없다.

클라이언트와 서버간 메시지 교환을 최소화하기 위해 제기된 방법이다.

서버는 프락시가 클라이언트의 요청이 가장 잘맞는 것이 무엇인지 판별할 수 있도록 어떤 요청 헤더 검사를 해야하는지 알려주어야한다.

이 때 프락시는 문서의 여러 사본들을 저장해두었다면, 서버를 대신하여 클라이언트와 협상을 진행할 수 있다.

---

트랜스코딩

만약 서버가 클라이언트가 요구에 맞는 문서를 아예 지니고 있지 않는다면, 그에 맞게 변환해야할 수도 있다.

이를 트랜스코딩이라 부르는데, 그 예로는 아래와 같이 있다.

- HTML문서 > WML문서, 고해상도 이미지 > 저해상도 이미지, 64K색 이미지 > 흑백 이미지 등

​

클라이언트가 모바일 환경이고, 고해상도 이미지를 볼 필요가 없을 경우 포맷 변환이 필요할 수도 있다.

포맷을 변환해야할 경우 내용 협상 헤더에 의해 주도된다.

이 때 콘텐츠 인코딩이나 전송 인코딩과는 다른 개념임을 주의하자.

전자는 콘텐츠를 접근 장치에서 볼 수 있도록 작업하는 것이고, 트랜스 코딩은 효율적인 전송을 위한 것이다.

​

정보 합성과 같은 작업이 진행되기도 한다.

정보 합성이란 각 절의 제목만 추려서 개요 문서를 생성하거나, 페이지에서의 광고 및 로고 제거 등이 있다.

​

또한 콘텐츠 주입을 하는 건도 있다. 예를 들어 웹사이트 내 적절하게 광고를 비치하는 것이다.

혹은 사용자 추적 시스템이나 웹사이트 유입에 대한 통계도 페이지에서 동적으로 콘텐츠 추가가 가능하도록 도와준다.

​

---

참고도서

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980

 

HTTP 완벽 가이드

​

​