Chapter 17. Content Negotiation and Transcoding
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 요약
Caching and Alternates
- 캐시된 응답을 전송할지 결정하기 위해 Accept 헤더 사용
- Variants (Alternates)
- 캐시에 저장된 동일 URL, 다른 버전의 문서 (ex. 프랑스어 버전, 스페인어 버전)
- Content Negotiation을 통해 어느 버전으로 응답할지 결정한다
Vary
- 서버가 문서나 특정 콘텐츠를 선택하는 데 필요한 클라이언트 요청 헤더의 목록을 담는다
- 새로운 요청 도착 -> 캐시가 Content-Negotiation 헤더를 통해 일치하는 문서를 찾는다
- 이때 서버가 캐싱된 응답에 Vary 헤더를 포함했는지 반드시 확인해야 한다
- Vary 헤더가 있다면 새로운 요청의 헤더 값이 캐싱된 요청의 것과 같은지 확인해야 한다
Transcoding
- 요청에 완벽히 일치하는 문서가 없을 때, 에러를 발생시키지 않고 존재하는 문서 중 하나를 클라이언트가 사용할 수 있는 형태로 변환하는 것
- (Ex) HTML -> WML, 고화질 이미지 -> 저화질 이미지
장점: 웹 서버에 페이지의 사본을 여러 개 저장하는 경우 발생하는 문제 해결
- (문제1) 페이지가 조금이라도 바뀌면 전부 다 수정되어야 함
- (문제2) 더 많은 공간 차지
- (문제3) 서버가 올바른 문서를 결정하고 제공하기 어려움
단점: 콘텐츠 제공에 지연 발생 (단, 다른 장치(프록시나 캐시)에서 연산을 수행하는 경우 서버 부하를 줄일 수 있다)
Format Conversion
- Content-negotiation 헤더를 통해 클라이언트가 인지할 수 있는 형태로 포맷을 변환하는 것
Transcoding이나Format Conversion은 콘텐츠 인코딩, 전송 인코딩과 다른 개념- 인코딩은 콘텐츠를 효과적으로 안전하게 전달하기 위해 사용
- 트랜스코딩과 포맷 변환은 사용자 디바이스에서 콘텐츠를 볼 수 있게 하기 위해 사용
Information Synthesis
- 문서를 요약하는 정보의 핵심 요소로 트랜스코딩에서 주로 사용
- (Ex) 문서를 바탕으로 섹션 제목 생성, 페이지에서 광고 제거, 키워드 중심으로 카테고리화
Content Injection
- 기존 콘텐츠에 추가적인 콘텐츠를 덧붙이는 동적 트랜스코딩 기법
- 트랜스코딩은 일반적으로 콘텐츠의 양을 줄이기 위해 사용되지만 Content-Injection의 경우 콘텐츠의 양이 증가한다.
- (Ex) 자동 광고 생성기, 유저 추적 시스템
✏️ 코멘트
인턴을 하면서 캐시를 다룰 일이 많이 있었다. 사용자마다 응답이 달라지는 것은 물론이거니와 시간에 따라, 상황에 따라 응답이 바뀌는 경우도 잦아서.. 값을 관리하는 게 여간 어려운 일이 아니었다. 그때는 주로 DB에서 가져온 엔티티를 캐싱하는 작업을 했었지만, 만약 HTTP를 통해 주고받는 JSON 응답을 캐싱해야 하는 상황이 온다면 실제 프록시에서 하는 것처럼 API마다 max-age, max-stale, min-fresh와 같은 옵션을 추가해줄 수도 있겠다는 생각이 들었다. 애플리케이션단에서 헤더 까서 유효기간 계산하고 새로운 응답을 생성할지 말지 결정하는..? 그런 애노테이션이 있으면 단순히 TTL로 관리하는 것보다 체계적으로 캐시 값을 관리할 수 있을 것 같다. 지금 읽은 내용과 크게 연관은 없지만 갑자기 생각나서 적어봤다.
트랜스코딩은 MSA에서 굉장히 중요한 개념일 것 같다. 다른 서버로부터 정상적인 응답을 받을 수 없는 상황이라면 폴백 응답을 통해 서비스 가용성을 보장하는 게 가장 이상적이다. 서킷브레이커의 역할이 사실상 HTTP 책에서 이야기하는 트랜스코딩과 같지 않을까 하는 생각이 들었다.
다람쥐 책이 오래되긴 했어도 바이블처럼 다루어지는 이유가 있는 것 같다. 프로토콜에 대한 지식도 주지만, 다양한 응용 기술들을 어떻게 활용하면 좋을지 인사이트를 주는 게 참 좋다.
틈틈이 두 페이지씩 원서 읽기