[HTTP] 캐시_304 Not Modified (Last-Modified& ETag)

Last-Modified

(if-modified-since)

• 캐시 만료후에도 서버에서 데이터를 변경하지 않음
• 그러면 데이터를 전송하는 대신에 브라우저에 저장해 두었던 캐시를 재사용할 수 있다.
• 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요.

 

검증 헤더 추가

1. 요청 > GET /star.jpg

[헤더]

HTTP/1.1 200 OK

Content-Type: image/jpeg

cache-control: max-age=60

Last-Modified: 2022년 9월 3일 08:54:00

Content-Length: 34012

[HTTP BODY: ..........................]

 

2. 헤더 + 바디 크기로 하여 1.1M를 전송한다. (데이터 최종 수정일 2022년 9월 3일 08:54:00)

3. 브라우저 캐시 > 응답 결과를 캐시에 저장 + 데이터 최종 수정일을 기록해 놓는다.

4. 60초 후(cache-control: max-age=60이기 때문에 60초 안에 호출하면 브라우저 캐시안에 있는 것을 가져온다) 재요청

        > 요청을 보내기 전 브라우저 캐시에 last-modified값이 있으면 요청 헤더에 추가를 한다.

        > GET /star.jpg  /  if-modified-since: 2022년 9월 3일 08:54:00

5. 서버 > 브라우저에서 요청한 if-modified-since의 값과 서버의 데이터 최종 수정일을 비교한다.

      > 데이터가 아직 수정되지 않았다.

6. 응답

[헤더]

HTTP/1.1 304Not Modified

Content-Type :image/jpeg

cache-control: max-age=60

Lasg-Modified: 2022년 9월 3일 08:54:00

Content-Length: 34012

[** HTTP Body **가 없음]

>> 바디가 없는 헤더만 전송함 ( 0.1M 전송 )

7. 브라우저 캐시 다시 세팅 > 응답 결과를 재사용, 헤더 데이터 갱신 > 60초 유효 >> 브라우저는 캐시에서 조회한다.

 

• 캐시 유효 시간이 초과해도, 서버의 데이터가 변경사항이 없으면 304 Not Modified + 바디 데이터가 없는 헤더 정보만 응답한다.
• 브라우저는 캐시의 메타 정보를 갱신 후 캐시에 저장되어 있는 데이터를 재활용 한다.

Last-Modified 단점

• 1초 미만 단위로 캐시 조정 불가능
• 날짜 기반의 로직 사용
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

 

ETag

(If-None-Match)

• Entity Tag
• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠 ( ETag: "abcdefg" )
• 데이터가 변경되면 이 이름을 바꾸어서 변경함
  • ETag: "aaa" -> ETag: "bbb"
• ETag만 보내서 같으면 유지, 다르면 다시 받기

 

1. 요청 > If-None-Match

2. 응답 > 304 Not-Modified

3. 브라우저 캐시에서 조회