캐시 기본 동작 & 검증 헤더와 조건부 요청

웹 브라우저에서 start.jpg를 요청하면 서버에서 star.jpg라는 그림을 찾아준다.

 

Header 부분과 이미지와 관련된 ByteCode가 있다.

캐시가 없을 때

• 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 받아야 한다.

 

• 인터넷 네트워크는 매우 느리고 비싸다.

 

• 브라우저 로딩 속도가 느리다.

 

• 느린 사용자 경험

 

 

 

 

60초 동안은 캐시가 유효하고 응답 결과를 캐시에 저장한다.

 

 

두번째 요청할 때는 캐시를 먼저 살핀다.

60초 안에 찾게되면 캐시에서 바로 가져오게 된다. 네트워크를 아예 탈 필요가 없게 된다.

 

캐시 적용

• 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 되고

 

• 비싼 네트워크 사용량을 줄일 수 있고

 

• 브라우저 로딩 속도가 매우 빠르다.

 

• 빠른 사용자 경혐

 

 

 

 

캐시 시간 초과

star.jpg를 다시 요청하고 60초가 초과되었다.

그러면 다시 웹브라우저에서 서버로 star.jpg를 요청하고 서버는 1.1M로 네트워크를 쓰면서 캐시 데이터를 전송하게 된다.

 

캐시 데이터를 받아서 새로 캐시가 초기화가 될 것이다. 다시 60초 동안 유효한 상태가 된다.

 

캐시 시간 초과

• 캐시 유효 시간이 초과하면, 서버를 통해서 데이터를 다시 조회하고, 캐시를 갱신

 

• 이때 네트워크 다운로드가 발생

 

 

 

 

 

검증 헤더와 조건부 요청

캐시 시간 초과

 

 

캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다.

• 서버에서 기존 데이터를 변경한다. (노란별에서 초록별로)
• 서버에서 기존 데이터를 변경하지 않는다. (노란별 그대로)

 

 

• 캐시 만료후에도 서버에서 데이터를 변경하지 않는다.

 

• 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수가 있다.

 

• 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다.

 

 

검증 헤더 추가로 첫 번째 요청 - 응답 결과를 캐시에 저장해놓고 60초동안 유효한 상태로 둔다.

 

 

 

 

캐시가 들고있는 데이터의 최종 수정일 값을 서버에 넘긴다.

그러면 서버에서 요청을 받고 if-modified-since가 왔네라고 판단한다.

서버에서 star.jpg가 있는데 웹 브라우저가 요청한 최종 수정일과 서버가 가지고 있는 최종 수정일이 같은걸 확인하고

서버에서 검증을 할 수 있다.

 

 

 

 

서버에서 보고 검증이 안됐다고 판단하면

HTTP 응답을 만들 때 304 Not Modified라고 내보낸다.

 

즉 너가 요청을 했는데 변경된게 없다라고 판단을 하게 된다.

그리고 body 부분은 빼고 starter-line과 header만 빼고 전송을 해준다.

 

Header 부분만 전송을 해주기 때문에 네트워크 부하가 확 줄어들게 된다. 그러면 서버에서 웹 브라우저 받았을 때 304 Not Modified다 라고 판단하고 캐시에서 헤더 데이터를 다시 갱신해준다.

 

그리고 다시 캐시에서 데이터를 불러와서 쓰게된다.

 

 

 

 

 

 

정리

검증 헤더( Last-Modified: 2020년 11월 10일 10:00:00)

조건부 요청( if-modified-since: 2020년 11월 10일 10:00:00)

• 캐시 유효 기간이 초과해도, 서버의 데이터가 갱신되지 않으면

 

• 304 Not Modified + 헤더 메타 정보만 응답(바디X)

 

• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신

 

• 클라이언트는 캐시에 저장되어 있는 데이터 재활용

 

• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드

 

• 매우 실용적인 해결책

 

 

구글에서 hello를 검색해보자.

연한거는 캐시에서 불러온것이다. 그림파일을 보게되면 캐시에서 불러왔단 정보를 알 수 있다.

 

그림파일도 상태코드가 304로 잘 나오게 된다. if-modified-since로 부터 데이터가 바뀌었나 보고 안바꼈으면 304 상태코드가 나오게 된다.

 

 

 

 

 

검증 헤더와 조건부 요청2

• 검증 헤더
• 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
• Last-Modified, ETag

 

• 조건부 요청 헤더
• 검증 헤더로 조건에 따른 분기
• If-Modified-Since:Last-Modified 사용
• 조건이 만족하면 200 OK
• 조건이 만족하지 않으면 304 NOT Modified

 

 

 예시로

• If-Modified-Since: 이후에 데이터가 수정되었으면?

 

• 데이터 미변경 예시
• 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00
• 304 Not Modified, 헤더 데이터만 전송(BODY 미포함)
• 전송 용량 0.1M(헤더 0.1M, 바디 1.0M)

 

 

• 데이터 변경 예시
• 캐시: 2020년 11월 10일 10:00:00 vs 2020년 11월 10일 11:00:00
• 200 OK, 모든 데이터 전송(BODY 포함)
• 전송 용량 1.1M (헤더 0.1M, 바디 1.0M)

 

 

 

Last-Modified, If-Modified-Sinced 단점

• 1초 미만(0.x초) 단위로 캐시 조정이 불가능

 

• 날짜 기반의 로직 사용

 

• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우

 

• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

 

• 예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

 

 

 

검증 헤더와 조건부 요청

ETag, If-None-Match

 

 

• ETag(Entity Tag)
• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠

• 예) ETag: "v1.0", ETag: "a2jiodwjekjl3"

   

   

   

• 데이터가 변경되면 이름을 바꿔서 변경함(Hash를 다시 생성)
• 예) ETag: "aaaaa" -> ETag: "bbbbb"

 

• 진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기!

 

 

 

 

 

 

 

서버에서 ETag라는 걸 내려주면 이번에는 ETag 값을 저장한다.

두번째 요청을 했는데 시간이 60초가 초과되었다 

 

 

 

 

 

그러면 서버에 가지고 있는 ETag가 있으면 웹브라우저가 if none-match라고 해서 매치가 안되면이라고 보낸다.

서버에 매치가 되버렸다 그러면 실패인 304 not modified를 보내고

 

 

 

 

데이터가 변하지 않았기 때문에 304 Not Modified를 내고 

캐시는 기존에 저장되있던 데이터를 재활용 할 것이다.

그리고 캐시에서 조회를 하게된다.

 

 

 

검증 헤더와 조건부 요청

ETag, If-None-Match 정리

 

• 진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받는다.

 

• 캐시 제어 로직을 서버에서 완전히 관리

 

• 클라이언트는 단순히 값을 서버에 제공(클라이언트는 캐시 매커니즘을 모른다.)

 

• 예)
• 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
• 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

 

 

 

 

 

 

 

 

 

 

 

<출처 김영한: 모든 개발자를 위한 HTTP 웹 기본 지식 >

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

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