01_DevTIL ✍HTTP

내용협상과 트랜스코딩

내용협상과 트랜스코딩

Accept header, http, transcoding, variant, vary
목차
  • http는 클라와 서버가 서로 내용을 협상할 수 있도록 방법을 제공한다. content-negotiation
  • 하나의 url이 여러가지 리소스 중 적합한 것에 대응되도록 할 수 있다.
    • 여기서는 서로 다른 버전을 varient라고 부른다.
  • 서버는 특정 url에 대해 어떤 콘텐츠가 클라에게 보내주기 가장 적절한지에 대한 판단도 할 수 있어야 한다.
  • 트랜스코딩은 http 클라와 서버 사이의 내용 협상에 대한 응답에서 수행된다.

내용 협상 기법

  • 서버에 있는 페이지들 중
    어떤 것이 클라에게 맞는지 판단하는
    3가지 방법
  1. 클라에게 선택지를 주거나 = 클라이언트 주도 협상
    • HOW: 클라가 요청을 보내면, 서버는 클라에게 선택지를 보내주고, 클라가 선택한다.
    • 장점: 서버 입장에서 가장 구현하기 쉽다. 클라는 최선의 선택을 할 수 있다.
    • 단점: 대기시간이 증가한다. 즉, 올바른 콘텐츠를 얻으려면 최소 두번의 요청이 필요하다.
  2. 서버가 자동으로 판단하는 방법 = 서버 주도 협상
    • HOW: 서버가 클라의 요청 헤더를 검증해서 어떤 버전을 제공할지 결정한다.
    • 장점: 클라 주도 협상보다 빠르다.
      • HTTP는 서버가 가장 적절한 것을 선택할 수 있도록 q값 메커니즘을 제공하고,
        서버가 다운스트림 장치에게 요청이 어떻게 평가되는지 말해줄 수 있도록 하기 위해 Vary 헤더를 제공한다.
    • 단점: 만약 결정이 뻔하지 않으면 (헤더에 맞는 것이 없으면), 서버는 추측을 해야만 한다.
  3. 중개자에게 선택하도록 부탁하는 방법 = 투명한 협상
    • HOW: 투명한 중간장치(주로 프락시 캐시)가 서버를 대신하여 협상을 한다.
    • 장점: 웹서버가 협상을 할 필요가 없다. 클라 주도 협상보다 빠르다.
    • 단점: 투명 협상을 어떻게 하는지에 대한 정형화된 명세가 없다.

1. 클라 주도 협상

  • 서버에게 있어 가장 쉬운 방법은
    • 서버가 클라의 요청을 받았을 때,
      가능한 페이지의 목록을 응답으로 돌려주어
      클라가 보고 싶은 것을 선택하게 하는 것이다.
    • 서버 입장에서 구현하기 쉽고,
      최선의 사본이 선택될 것이다.

단점

  1. (기술측면) 각 페이지에 두 번의 요청이 필요하다는 것.
    • 한번은 목록을 얻고
    • 두번째는 선택한 사본을 얻는다.
    • 선택지를 표현하는 2가지 방법
      1. 여러가지 버전에 대한 링크와 설명이 담긴 html
      2. 300 Multiple Choices 응답코드로 응답을 돌려주는 것. (상태코드 글 참고)
  2. (ux측면) 여러개의 url을 요구한다는 점

2. 서버 주도 협상

  • 불필요한 커뮤니케이션 비용을 줄이는 방향으로
    서버가 어떤 페이지를 돌려줄 것인지 결정하게 하는 것.
    • 클라는 반드시 자신이 무엇을 선호하는지에 대한 충분한 정보를 서버에게 주어서,
      서버가 현명한 결정을 할 수 있게 해 주어야 한다.
  • http 서버가 클라에게 보내줄 적절한 응답을 계산하기 위해 사용하는 메커니즘은 2가지
    1. 내용 협상 헤더들을 살펴본다.
      • 서버는 클라의 Accept 관련 헤더들을 들여다보고, 그에 알맞은 응답 헤더를 준비한다.
    2. 내용 협상 헤더 외의 다른 헤더들을 살펴본다.
      • 예_서버는 클라의 User-Agent 헤더에 기반하여 응답을 보내줄 수도 있다.

2.1 내용협상 헤더

  • Accept : 서버가 어떤 미디어 타입으로 보내도 되는지 알려준다.
  • Accept-Language : 서버가 어떤 언어로 보내도 되는지 알려준다.
  • Accept-Charset : 서버가 어떤 차셋으로 보내도 되는지 알려준다.
  • Accept-Encoding : 서버가 어떤 인코딩으로 보내도 되는지 알려준다.

내용 협상 헤더들은

  1. 클라와 서버가 선호 정보를 서로 교환하고,
  2. 문서들의 여러 버전 중 하나를 선택하는 것을 도와,
  3. 클라의 선호에 가장 잘 맞는 문서를 제공해 주기 위한 목적으로 사용된다.
  • 만약에 클라중 하나가 일본어를 선호한다면
    한국어을 돌려줘야할까
    영어를 돌려줘야할까.
    • 한국어를 좀 더 선호한다면,
      선호한다는 의사 정보를 추가하여 전달할 수 있으면 좋겠다고 생각할 것이다.
  • HTTP는 풍부한 설명을 품질값을 이용해 전달할 수 있는 메커니즘을 제공한다.
    • quality value, 줄여서 q값

2.2 내용 협상 헤더의 품질값

  • HTTP 프로토콜은 클라가 각 선호의 카테고리마다, 여러 선택 가능한 항목을
    선호도와 함께 나열할 수 있도록 품질값을 정의하였다.

    1
    Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0

  • q는 0.0부터 1.0까지의 값을 가질 수 있다.

  • 위 상황은 네덜란드어(nl)로 된 문서를 받기 원하고 잇으나
    영어(en)로 된 문서라도 받아들일 것임을 의미한다.

때때로 서버는 클라의 선호에 대응하는 문서를 하나도 갖고있지 않을 수 도 있다.
이 경우, 서버는 클라의 선호에 맞추기 위해
문서를 고치거나 트랜스코딩 할 수 있다.

2.3 그 외의 헤더들에 의해 결정

  • 서버는 또한 User-Agent와 같은 클라의 다른 요청 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있다.
  • 최선에 가장 가까운 대응을 찾아낼 수 있는 q값 매커니즘은 없다.
  • 서버는 정확한 대응을 찾아내거나,
    그냥 갖고 있는 것을 제공해주어야 한다.
  • 캐시는 반드시 캐시된 문서의 올바른 ‘최선의’ 버전을 제공해주려 해야 하기 때문에,
    HTTP 프르토콜은 서버가 응답에 넣어 보낼 수 있는 Vary 헤더를 정의한다.
    • Vary 헤더는 캐시에게 서버가 내줄 응답의 최선의 버전을 결정하기 위해
      어떤 요청 헤더를 참고하고 있는지 말해준다.

3. 투명 협상

  • 클라 입장에서 협상하는 중개자 프락시를 둠으로써,
    클라와의 메세지 교환을 최소화하는 동시에
    서버 주도 협상으로 인한 부하를 서버에서 제거한다.
  • 투명한 내용 협상을 지원하기 위해, http에서 정의한 Vary 헤더를 사용한다.
    • 서버는 어떤 요청 헤더를 검사해야 하는지 프락시에게 Vary 헤더를 통해 말해준다.

3.1 캐시와 얼터네이트 alternate

  • 캐시는 클라의 요청을 서버로 그대로 전달하고, 응답을 저장한다.
  • 두번째 요청시 응답은 캐시가 URL에 대응하는 문서를 찾아서 돌려줄 것인데,
    이때 다른 언어의 문서를 원한다면,
    캐시는 이번응답과 새로운 응답문서 2가지를 저장해야한다.
  • 이 다른 버전은 베리언트나 얼터네이트라고 불리다.
    variant (:변형)
    alternate (:교대로)

3.2 Vary 헤더

  • http Vary 응답 헤더는
    서버가 문서를 선택하거나, 커스텀 콘텐츠를 생성할 때 고려한
    클라 요청 헤더 모두를 나열한다.
  • 새 요청이 도착했을 때, 캐시는 내용 협상 헤더들을 이용해 가장 잘 맞는 것을 찾는다.
    • 캐시는 반드시 캐시된 응답 안에 서버가 보낸 Vary 헤더가 들어있는지 확인하고,
      Vary 헤더가 명시하고 있는 헤더들은
      새 요청과 오래된 캐시된 요청에서 그 값이 서로 맞아야만 한다.
      • 서버는 클라의 요청 헤더에 따라 그들의 응답이 달라질 수 있기 때문에
        투명 협상을 구현하기 위해 캐시는 반드시
        캐시된 variant와 함께
        클라 요청 헤더와
        그에 알맞은 서버 응답헤더 양쪽 모두를 저장해야한다.
1
Vary: User-Agent, Cookie
  • 서버의 Vary 헤더가 이렇다면, 거대한 수의 다른 User-Agent와 Cookie이 많은 배리언트 variant를 만들어낼 것이다.
  • 캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 한다.
  • 캐시가 검색을 할 때,
    1. 먼저 내용 협상 헤더로 적합한 콘텐츠를 맞춰보고
    2. 다음에 요청의 배리언트를 캐시된 배리언트와 맞춰본다.
    3. 만약 맞는 것이 없으면, 캐시는 문서를 서버에서 가져온다.
      맞는 것이 있다면, 해당 콘텐츠를 보내준다.

트랜스 코딩

  • 서버가 클라의 요구에 맞는 문서를 아예 갖고 있지 않다면?
    이론적으로는 서버는 기존의 문서를 클라가 사용할 수 있는 무언가로 변환할 수도 있다.
    -> 이 옵션을 트랜스코딩이라고 부른다.
  1. HTML 문서 👉 WML 문서
  2. 고해상도 이미지 👉 저해상도 이미지
  3. 64K색 이미지 👉 흑백 이미지
  4. 프레임을 포함한 복잡한 페이지 👉 프레임이나 이미지가 없는 단순한 텍스트 페이지
  5. 자바 애플릿이 있는 HTML 페이지 👉 자바 애플릿이 없는 페이지
  6. 광고가 있는 페이지 👉 광고가 없는 페이지
  1. 포맷 변환
    • 포맷변환은 데이터를 클라가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것이다.
  2. 정보 합성
    • 문서에서 정보의 요점을 추출하는 것을 정보 합성이라고 한다. information synthesis
    • 각 절의 제목에 기반한 문서의 개요 생성이나,
      페이지에서 광고 및 로고 제거를 들 수 있다.
      • 본문의 키워드에 기반하여 페이지를 분류하는
        더 복잡한 기술은 문서의 핵심을 요약할 때도 역시 유용하다.
    • 이 기술을 포털사이트의 웹페이지 디렉터리와 같은
      자동화된 웹페이지 분류 시스템에 의해 종종 사용된다.
  3. 콘텐츠 주입
    • 포맷 변환과 정보 합성은 문서의 양을 줄이지만
      주입 트랜스코딩은 오히려 양을 늘린다.
    • 내용 주입 트랜스 코딩의 예로 자동 광고 생성과 사용자 추적 시스템이 있다.
    • 동적으로 문서에 추가된다.
  4. 트랜스 코딩 vs 정적으로 미리 생성해놓기
    • 트랜스 코딩의 대안은 웹서버에서 웹페이지의 여러가지 사본을 만드는 것이다.
      • 예_고해상도는 저해상도 이미지를 만든다.
    • 여러가지 이유로 그다지 현식적인 기법이 못된다.
      • 페이지에 대한 어떠한 작은 변화도 여러 페이지의 수정을 요구하게 되고
      • 각 페이지의 모든 버전을 저장하기 위해 더 많은 공간이 필요하게 되며
      • 페이지들을 관리하고, 그것들 중 올바른 것을 골라서 제공해주는 웹서버를 프로그래밍하기 어려워진다.
    • 변환은 더 싼 프락시나 캐시에 있는 외부 에이전트에 의해 수행될 수 있다.

참고자료

profile

author.

Joy Kim @feel5ny

웹 프론트엔드 개발자입니다. 글쓰기와 정리를 좋아합니다.

📚