HTTP - 캐시(2)

이번 포스트는 지난번 포스트에 이어 캐시에 대해 계속 알아보겠습니다.

 

캐시의 유효기간이 지난 경우

다시 서버와 통신을 해서 캐시 유효시간을 갱신해야 합니다.

하지만 단순히 캐시만 갱신하는데 동일한 데이터를 가져와야 하는 경우가 있을 것입니다.

이런 경우는 뭔가 좀 비효율적인 것 같습니다.

 

그래서 캐시 검증 헤더와 조건부 요청이라는 것이 있습니다.

 

똑같은 말을 한번만 더하겠습니다.

캐시 유효시간이 지난 경우 다시 서버와 통신을 해야합니다.

그럴 때 2가지 상황이 있죠

1. 서버가 기존 데이터를 변경함
2. 서버가 기존 데이터를 유지함

1번의 경우는 어쩔 수 없이 새로운 데이터를 받아오는 것이 맞지만

2번의 경우 단순히 유효시간만 지났기 때문에 브라우저 캐시에 저장된 데이터를 그대로 가져다 쓰고 싶습니다.

이럴 때는 클라이언트의 캐시와 서버의 데이터가 갖다는 보장이 있어야 하고, 그런 방법이 필요합니다.

 

이 때 쓰는 헤더는 다음과 같습니다.

• Last-Modified: 2020-10-10 12:00:00 GMT
• 헤더 이름을 보면 알겠지만, 마지막으로 수정된 시간을 저장하는 헤더입니다.
• 실제 시간 표현은 예시와 다를 수 있습니다.(제가 임의로 적음)

 

그러면 캐시 유효 시간이 지나 검증할 때를 알아보죠.

• 다시 GET /circle.jpg라는 요청을 보냅니다.
• 이 때, if-modified-since라는 헤더를 사용합니다. 그리고 이 헤더에는 Last-Modified에 저장된 값이 들어갑니다.
• ex) if-modified-since: 2020-10-10 12:00:00 GMT
• GET 요청에 if-modified-since 헤더를 추가해서 전송합니다.
• 서버에서 해당 데이터의 최종 수정 날짜를 비교합니다.
• 만약 헤더에 있는 날짜와 같다면? → 데이터 수정 X
• 응답은 HTTP/1.1 304 Not Modified 로 전송됩니다.
• 그리고 HTTP 바디 부분은 없는 형태로 전송됩니다.

오.. 이렇게 되면 나름 효율적일 것 같습니다 ㅎㅎ

 

캐시 유효시간 검증 정리

1. 캐시 유효시간 초과 → 서버에 요청
2. 갱신이 일어나지 않은 경우 : 304 Not Modified 응답 코드 + 헤더만 전송
3. 클라이언트는 서버의 응답 헤더 정보로 캐시 정보 update
   or 캐시에 저장된 데이터 재활용
4. 네트워크 통신은 있지만, 헤더만 전송되는 경우 있음
5. 효율적인 방법이다.

실제로 이런 방식은 많은 곳에서 사용된다고 합니다.

 

Last-Modified와 if-modified-since 에는 단점들도 존재하는데요,

• 초 단위까지만 가능 → 1초 미만의 단위는 불가능
  실시간 정보를 저장해야하는 캐시의 경우에는 조금 비효율적일 수 있음
• 날짜 기반의 로직 사용
  ex) 데이터를 수정해서 날짜는 달라졌지만, 결국에는 이전에 저장한 데이터와 같은 경우
       → 데이터 변경이 없지만, 날짜는 다르기 때문에 캐시 update가 발생..
•  

 

근데 이런 검증 헤더는 더 있다고 합니다.

• Last-Modified
• ETag

 

그리고 조건부 요청도 약간 달라집니다.

• if-modified-since : Last-Modified와 같이 사용
• if-none-match : ETag와 같이 사용
• 조건에 만족하면 200 OK
• 만족 안하면 304 Not Modified

 

그럼 이제 ETag와 if-none-match를 알아봅니다.

• 이 헤더들은 Last-Modified와 if-modified-since의 단점을 해결했다고 함
• ETag(Entity Tag)
• ETag에는 캐시용 데이터에 임의의 값을 부여하는 것입니다.
  → 어떤 한 데이터에 해시값을 부여한다고 생각하면 편하겠습니다.
  → 데이터가 변경되면 해시값이 변경 & 데이터가 같으면 해시값도 같음
• ETag의 값과 비교해서 다른지 같은지 확인합니다. ㅎㅎ

 

그러면 ETag가 어떻게 사용되는지 알아보죠.

1. 클라이언트는 이전에 GET /circle.jpg 라는 요청을 통해 ETag: "abcedfg" 라는 값을 받았다고 가정합니다.
2. 그리고 클라이언트가 다시 요청을 보냅니다.
3. 이 때 if-none-match: "abcedfg" 헤더가 같이 보내집니다.
4. 서버에서 해당 데이터의 임의의 값을 확인
   → 만약 "abcedfg"라는 결과가 나오면 데이터는 변경 X
5. HTTP/1.1 304 Not Modified라는 응답이 옴 + HTTP 바디는 없음
6. 응답결과를 통해 캐시 update

 

ETag에 대해 정리하겠습니다.

• 정말 단순 : ETag 값만 보내서 같으면 유지 or 다르면 다시 보내기
• 캐시 제어 로직을 서버에서만 담당
  → 클라이언트는 캐시가 어떤 로직으로 동작하는지 알 수 없음
      클라이언트는 단순히 ETag 값만 제공

 

 

이렇게 캐시에 대해 알아보면서 

Last-Modified, ETag 헤더에 대해 알아봤습니다.

캐시가 이런 방식으로 동작하는지 이번에 처음 알게된 것 같습니다.

아마 알아두면 언젠가는 써먹지 않을까요?

 

 

 

 

이번 포스트를 마치겠습니다.

 

 

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