안녕하세요 오늘은 캐시와 조건부 요청에 대해서 알아보도록 하겠습니다.

🎈 캐시 기본 동작

예를들어 캐시가 없다. 웹브라우저에서 star.jpg를 서버에 요청 했을 때 서버에서는 star.jpg 관련된 그림을 내려준다. 그럼 웹브라우저에서 별이라는 이미지를 그릴 것이다.

캐시가 없을 때

• 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
• 인터넷 네트워크는 매우 느리고 비싸다.
• 브라우저 로딩 속도가 느리다.
• 느린 사용자 경험

이제 캐시를 적용을 하면 어떻게 되느냐하면 웹브라우저에서 캐시와 관련된 것을 세팅을 하고 서버에 캐시를 적용하면 cache-control이라고 이것을 헤더에 넣어 줄 수가 있다. 캐시가 유효한 시간은 max-age = 60이라고 하면 60초 동안 캐시가 유효하다는 뜻이다.

최초로 요청을 할 때는 star.jpg를 브라우저에 내려줄 때 브라우저 캐시를 저장해주는 공간에다 응답 결과를 저장해준다. (max-age=60)이라고 했으니 60초 동안 !!

이렇게 응답결과를 캐시에 저장했으니 두 번째 요청할 때는 브라우저가 캐시를 먼저 뒤진다. 그럼 네트워크를 아예 탈 필요가 없이 star.jpg를 캐시에서 가져온다.

캐시 적용

• 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
• 비싼 네트워크 사용량을 줄일 수 있다.
• 브라우저 로딩 속도가 매우 빠르다. (메모리 아니면 하드디스크에서 바로 가져오기 때문에)
• 빠른 사용자 경험

그래서 웹브라우저 한 번 들어갔다가 다시 들어가면 굉장히 빨리 열리는 경우를 겪어봤을 텐데 이게 바로 캐시가 저장되어 있어서 그런 것이다.

캐시 적용 (세 번째 요청/캐시 시간 초과)

세 번째 요청을 했을 때, 만약에 60초가 초과 된 상태라고 보자. 그럼 당연히 다시 요청을 해야한다. 그럼 받은 데이터를 가지고 기존 것을 지운 후 다시 캐시를 덮어 씌우면서 새로 캐시가 초기화되면 60초가 유효한 상태로 된다.

캐시 시간 초과

• 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다. 이때 다시 네트워크 다운로드가 발생한다.
  ✨그런데✨ 만약에 클라이언트 캐시가 만료가 되었다. (60초가 지난상태) 클라이언트가 가진 데이터와 서버와 가진 데이터가 똑같다면 또 다시 star.jpg라는 파일을 다운로드 받을 필요가 있을까 ? 이런 매커니즘을 설명을 하자면

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

1. 서버에서 기존 데이터를 변경함
2. 서버에서 기존 데이터를 변경하지 않음

이렇게 되면 용량이 1M가 되는데 굳이 처음부터 다시 다운로드 받아야 할 필요가 있을까 라는 의문이든다.

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

이때, 검증 헤더 추가

처음 요청을 할 때, star.jpg를 요청을 한다. 그럼 서버에서 cache-control을 60초 동안 할 수 있다고 가정해보자. 그런데 여기서 Last-Modified를 또 추가할 수 있다. 이 데이터가 마지막으로 수정 된 최종 수정일을 여기다 넣어두는 것이다. (UTC 표기법으로 적어두어야 한다)

웹 브라우저에서 응답 결과를 당연히 캐시에 저장하고, 60초 유효하다는 것도 적어두고. 하나 더 더해진다. 바로 데이터 최종 수정일이 2020년 11월 10일 10:00:00이라고 말이다. (Last-Modified) 이 것을 추가적으로 기록하고 있는 것이다.

60초가 지나면 이제 검증 헤더라고 있는데,

데이터 최종 수정일은 2020년 11월 10일 10:00:00 이거라고 서버에 넘겨준다. 그럼 서버에서 요청을 if-modified-since(조건부요청)로 보내진 것을 받고 서버에서 데이터 최종 수정일이 잘 반영이 되었는지 검증을 할 수 있다. 보니까 두 개의 날짜가 똑같다. 이렇게 되면 날짜를 보고 판단을 할 수 있다.

그렇게 했을 때, 서버에서는 수정이 안되었다고 인식하고 304 Not Modified라고 나온다. 요청을 했는데 난 변경된게 없어 라는 뜻.
그리고 Last-Modified를 다시 보낸다. 근데 중요한 것이 있는데, HTTP Body가 없다. 왜냐하면 수정된 것이 없기 때문이다. 그래서 응답을 전송할 때는 바디를 빼고 Start 라인이랑 헤더 부분만 응답을 만들어서 보내준다.

그러면 웹브라우저에서 받았을 때, 응답 결과를 재사용하고 헤더 데이터를 갱신한다.
이렇게 캐시를 다시 세팅하고 웹브라우저에서 캐시에서 조회하여 쓴다.

이렇게 되면 전송할 수 있는 용량을 확 줄일 수 있다.

🔥 검증 헤더와 조건부 요청 정리

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답 (바디x)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책

이게 Request 헤더인데 요청을 보낼 때 if-modified-since(조건부요청)로 보냈는데 status는 304로 뜬다. 데이터 안바꼈다 그대로 써도 된다라는 뜻.

🟡 검증 헤더

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

🟡 조건부 요청 헤더

• 검증 헤더로 조건에 따른 분기
• If-Modified-Since: Last-Modified 사용
• If-None-Match: ETag 사용
• 조건이 만족하면 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 미포함) 304는 리다이렉션이다.
• 전송 용량 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-Since 단점

• 1초 미만(0.x초) 단위로 캐시 조정이 불가능
• 날짜 기반의 로직 사용
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
  클라이언트에서 서버에서 요청을 했으면 서버입장에서는 파일에 날짜는 갱신되어있지만 실제 컨텐츠는 갱신이 안될 수도 있다. 이런 경우에도 전체 데이터를 다시 다운받는다.
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
  - 예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우
  

서버에서 완전하게 캐시 매커니즘을 컨트롤 할 수 있는 방법이 있다. 바로 ETag 이다.

🔥 ETag, If-None-Match

🟡 ETag

• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
  - 예) ETag: "v1.0", ETag: "a2jiodwjekjl3"
  
• 데이터가 변경되면 이 이름을 바꾸어서 변경한다. (해시를 다시 생성)
  - 예) ETag: "aaaaa" -> ETag: "bbbbb"
  
• 진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기!

이것도 데이터를 내려줄 때 실패하면 304 라는 상태코드가 뜬다. 304 Not Modified !

정리

• 진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기.
• 캐시 제어 로직을 서버에서 완전히 관리
• 클라이언트는 단순히 이 값을 서버에 제공 (클라이언트는 캐시 메커니즘을 모른다)

예 )

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

🔥 캐시 제어 헤더

🟡 Cache-Control : 캐시 제어

• max-age : 캐시 유효 시간, 초 단위
• no-cache : 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용한다.
• Cache-Control : no-store
• 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

Pragma (하위 호환)

• Pragma : no-cache
• HTTP 1.0 하위 호환

Expires 캐시 만료일 지정

• expires: Mon, 01 Jan 1990 00:00:00 GMR

• 캐시 만료일을 정확한 날짜로 지정

• HTTP 1.0부터 사용

• 지금은 더 유연한 Cache-Control:max-age 권장

• Cache-Control : max-age와 함께 사용하면 Expires는 무시