공부/HTTP

HTTP 웹 기본 지식 ➄ HTTP 헤더 / 캐시, 검증, 조건부 요청

jihyee 2022. 1. 2. 16:14
 

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., 웹 기술을 사용하는 개발자라면 누구나 OK!꼭 필요한 HTTP의 핵심을 알려드립니다. 📣 확인해주세요!본 강의는 자바 스

www.inflearn.com

위 강의를 통해 공부한 내용을 정리함

 

 

 

 

 

캐시

캐시는 네트워크 통신으로 인한 비용과 시간을 줄이기 위해 사용한다.

데이터를 요청하고 응답받는 과정에 하드웨어적으로 생각했을 때 굉장한 시간과 비용을 들게 함.

근데 만약 요청이 거의 바로 이어지거나 반복되거나 등의 이유로 데이터가 거의 변경되지 않는다면 중복되는 데이터 통신이 된다.

 

 

 

그럴 때 네트워크 비용과 시간을 줄이기 위해 캐시를 사용한다. 헤더에 Cache-Control 헤더를 명시하고 보내주면 여기에 명시된 정보를 바탕으로 브라우저 캐시에 데이터가 저장된다. 이러면 그 정보에 일치하는 데이터 요청이 왔을 때 직접 네트워크 타고 서버에서 데이터를 응답받는 게 아니라 브라우저 캐시에서 데이터를 바로 응답받는다.

 

 

 

만약 캐시 유효 시간이 초과한 경우 두 가지 가능성이 있다

 

  1. 브라우저 캐시에 저장된 데이터와 서버 데이터가 같은 경우
  2. 브라우저 캐시에 저장된 데이터와 서버 데이터가 다른 경우

 

 

2의 경우는 첫 번째 요청과 같이 그대로 다시 데이터를 다시 받으면 된다.

1의 경우는 데이터를 그대로 다시 받는 게 아까울 수 있음. 2의 경우를 가정하고 서버 데이터와 브라우저 캐시 데이터가 같은지 다른지 확인해서 처리를 달리하는 방식을 사용하면 좋을 것 같음.

 

 

 

 

 

이를 위한 방법이 바로 최종 수정 시간이라는 검증 헤더를 추가하는 것이다.

 

Last-Modified라는 검증 헤더를 추가해서 응답을 보내면 클라이언트 측에서는 해당 정보를 함께 브라우저 캐시에 저장한다. 

두 번째 요청이 발생했는데 캐시 유효 시간도 초과한 경우라면 데이터를 통으로 주고받는 것을 막기 위해 요청에 if-modified-since라는 조건부 요청 헤더를 달고 보낸다. → if 붙는 게 조건부 요청임

서버는 해당 날짜와 데이터 최종 수정일 날짜를 비교해서 만약 이후 수정됐으면 첫 번째 요청과 동일하게 응답을 보내고 수정이 안됐으면 (결국 브라우저 캐시 데이터나 서버 데이터나 같다는 뜻) 데이터 payload 없이 304 not-modified 응답 메시지를 보내게 된다.

해당 응답이 오면 클라이언트는 브라우저 캐시에서 데이터를 가져다 쓴다.

 

요청과 응답은 발생한다! 

근데 중요한 건 메시지 바디에 데이터를 안 담고 요청을 주고받기 때문에 주고받는 데이터의 용량을 매~우 줄일 수 있다.

 

 

 

 

ETag

이렇게 캐시 정보에 관한 검증, 조건부 헤더들이 있는데 만약 날짜 기반으로 한 해당 헤더 말고 다른 검증, 조건부 헤더를 만들고 싶다 하면 ETag를 활용하면 된다.

 

날짜 대신 ETag값을 기준으로 한다는 점 빼고는 위 캐시 검증, 조건부 헤더와 방법은 일치한다.

 

 

 

 

 

 

 

<검증 헤더와 조건부 헤더 정리>

 

 

 

 

 

캐시 제어 헤더

여러 방법들로 캐시에 대한 것을 제어할 수 있다.

 

 

ex) 캐시 무효화

 

☆ 왜 no-cache 하는데 must-revalivate 도 해야 하는 걸까?

 

no-cache 만 명시하면 만약 프록시에서 원서버 사이에 문제가 발생했을 때 그래도 에러나는 것보단 프록시에 저장된 기존 데이터라도 보내주라고 설정해놓은 경우가 있어서 결국 캐시를 사용하게 될 수도 있다. 

 

그렇기 때문에 완벽한 캐시 무효화를 하기 위해선 must-revalidate까지 넣어줘야 한다.

 

 

 

 

 

 

※ 개인 프로젝트할 때 그런 경우는 없겠지만 개인 api 키나 계좌 정보 같은 중요 데이터를 주고받으면 중간 캐시에 저장되지 않게 하기 위해서 캐시 무효화 헤더를 꼭 추가하자 ※

 

 

 

 

 

프록시 서버

 

 

빛의 속도가 빠르더라도 한국에서 미국 서버로 데이터 주고받으면 느릴 수밖에 없음..

 

중간에 공용으로 사용하는 public 캐시 서버를 한국에 두면 첫 요청이 아닌 경우에는 요청이 중복되면 프록시 캐시에 저장돼서 좀 빠르게 데이터를 주고받을 수 있다.