Chapter 17 - 내용 협상과 트랜스코딩

📌 읽으면서 밑줄친 내용 그대로 옮겨 적음. *이 붙은 문장은 생각.
기법 어떻게 동작하는가 장점 단점
클라이언트 주도 클라이언트가 요청을 보내면, 서버는 클라이언트에게 선택지를 보내주고, 클라이언트가 선택한다. 서버 입장에서 가장 구현하기 쉽다. 클라이언트는 최선의 선택을 할 수 있다. 대기시간이 증가한다. 즉, 올바른 콘텐츠를 얻으려면 최소 두 번의 요청이 필요하다.
서버 주도 서버가 클라이언트의 요청 헤더를 검증해서 어떤 버전을 제공할지 결정한다. 클라이언트 주도 협상보다 빠르다. HTTP는 서버가 가장 적절한 것을 선택할 수 있도록 q값 메커니즘을 제공하고, 서버가 다운스트림 장치에게 요청이 어떻게 평가되는지 말해줄 수 있도록 하기 위해 Vary 헤더를 제공한다. 만약 결정이 뻔하지 않으면(헤더에 맞는 것이 없으면), 서버는 추측을 해야만 한다.
투명 투명한 중간 장치(주로 프락시 캐시)가 서버를 대신하여 협상을 한다. 웹 서버가 협상을 할 필요가 없다. 클라이언트 주도 협상보다 빠르다. 투명 협상을 어떻게 하는지에 대한 정형화된 명세가 없다.
  • 클라이언트 주도 협상
    • 기술적으로 서버에게는 클라이언트에게 줄 선택지를 표현하는 두 가지 방법이 있다.
      • 여러 가지 버전에 대한 링크와 각각에 대한 설명이 담긴 HTML 페이지를 돌려준다.
      • 300 Multiple Choices 응답 코드로 HTTP/1.1 응답을 돌려준다.
  • 서버 주도 협상
    • 내용 협상 헤더
      • Accept → 서버가 어떤 미디어 타입으로 보내도 되는지 알려준다.
      • Accept-Language → 서버가 어떤 언어로 보내도 되는지 알려준다.
      • Accept-Charset → 서버가 어떤 차셋으로 보내도 되는지 알려준다.
      • Accept-Encoding → 서버가 어떤 인코딩으로 보내도 되는지 알려준다.
    • 내용 협상 헤더의 품질값
      • q값은 0.0부터 1.0까지의 값을 가질 수 있다(0.0은 가장 낮은 선호도, 1.0은 가장 높은 선호도)
    • Vary 헤더는 캐시에게(그리고 클라이언트나 그 외의 모든 다운스트림 프락시에게) 서버가 내줄 응답의 최선의 버전을 결정하기 위해 어떤 요청 헤더를 참고하고 있는지 말해준다.
  • 투명 협상
    • HTTP/1.1 명세는 투명 협상에 대한 어떤 메커니즘도 정의하지 않았지만, 대신 Vary 헤더를 정의했다. 서버는 응답에 Vary 헤더를 포함시켜 보냄으로써 중개자에게 내용 협상을 위해 어떤 헤더를 사용하고 있는지 알려줄 수 있다.
  • 트랜스코딩
    • 포맷 변환
      • 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것
    • 정보 합성
      • 문서에서 정보의 요점을 추출하는 것
        • 각 절의 제목에 기반한 문서의 개요 생성, 페이지에서 광고 및 로고 제거 등
    • 내용 주입
      • 자동 광고 생성, 사용자 추적 시스템 등

알게된 점

  • 이번 장 전체

관련해서 같이 이야기 나누고 싶은 점

  • 뭔가 와닿지는 않는 내용이네요. 🫠