[HTTP] 모든 개발자를 위한 HTTP 웹 기본 지식 - 8

👩‍💻 HTTP 헤더2 - 캐시와 조건부 요청

---

 

 

📌 캐시 기본 동작

✏️캐시의 기본 동작 - 캐시가 없을 때

 

캐시가 없을 때의 첫번째 요청

 

똑같은 이미지를 두 번째 요청

 

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

 

 

 

✏️캐시의 기본 동작 - 캐시를 적용

첫 번째 요청

캐시 저장소에 캐시가 유효하면 네트워크를 타지 않고 그냥 바로 캐시에서 조회하여 가져온다.

• 캐시를 적용한다면...
  • 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된디.
  • 비싼 네트워크 사용량을 줄일 수 있다.
  • 브라우저 로딩 속도가 매우 빠르다.
  • 빠른 사용자 경험

 

캐시 유효 시간이 초과된다면 당연히 다시 서버에 요청을 해야하고, 서버에서 온 응답은 다시 캐시 저장소에 덮어씌우며 저장하게 된다.

• 캐시 시간이 초과된다면?
  • 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
  • 이때 다시 네트워크 다운로드가 발생한다.
  • 만약에 클라이언트 캐시가 만료되어도, 클라이언트가 가진 데이터와 서버가 가진 데이터 똑같을 때, 굳이 다시 다운로드를 받을 필요가 있을까 ? 다음 시간에 이어서 알아보도록 하자.

 

 

 

 

 

 

 

 

 

📌 검증 헤더와 조건부 요청1

✏️캐시 시간 초과

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

: 1번의 경우는 데이터가 변경되었기 때문에 물론 다시 요청해서 캐시를 덮어씌워야 하지만, 2번의 경우 서버에서 기존 데이터를 변경하지 않는데도 굳이 다시 다운로드 받을 필요가 있을까? 이를 해결하기 위해 조건부 요청이란 것이 나왔다.

 

 

 

 

✏️캐시 시간 초과2

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

 

 

 

 

 

 

✏️검증 헤더 추가

:첫 번째 요청

 

첫 번째 요청을 보낼 때 서버에서 Last_modified 라는 최종 수정된 시간을 추가해서 보낸다.

 

두 번째 요청을 보낼 때, 캐시 시간이 초과되었다면 웹 브라우저는 if-modified-since라는 것을 추가해서 서버에 보내게 된다.

 

요청한 것과 서버에서 가지고 있는 데이터의 최종 수정일의 날짜가 똑같다면, 서버에서 이 날짜를 보고 판단하여 수정이 안되면 304 Not MOdified를 보내는데. (" 나 변경된 거 없어") HTTP Body가 없다. 수정된 게 없기 때문에 body를 추가해서 보낼 필요가 없다.

 

캐시를 다시 불러와서 사용하게 된다.

 

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

 

 

 

 

 

 

 

 

 

📌 검증 헤더와 조건부 요청2

✏️ 검증 헤더와 조건부 요청에 대해 더 자세히 알아보자

• 검증 헤더
  • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
  • 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 미포함)
    • 전송 용량 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초 미만(o.x초) 단위로 캐시 조정이 불가능
• 날짜 기반의 로직 사용
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우 (A에서 B로 바꾸고 다시 B에서 A로 바꾸면 결국 데이터 결과는 A로 똑같음)
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
  • 예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

 

 

 

 

 

 

✏️ ETag, If-None-Match

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

ETag 사용해서 캐시에 저장

 

 

캐시 유효 시간인 60초가 초과되어 다시 요청을 보낼 때 If-None-Match(매치가 안되면)에 캐시가 가지고 있는 ETag를 포함해서 보낸다.

 

요청을 보냈을때 데이터가 아직 수정되지 않아 ETag가 매치되는 것을 알 수 있음. 그러면 If-None-Match는 매치가 안되면, 이니까 304 Not Modified를 보낸다.

데이터가 수정되지 않았기 때문에 캐시를 재사용 한다.

 

 

 

• ETag, If-None-Match 정리 

 

 

 

 

 

 

 

 

 

 

 

📌 캐시와 조건부 요청 헤더

✏️ 캐시와 조건부 요청 헤더에 대해 알아보자

• 캐시 제어 헤더
  • Cache-Control: 캐시 제어  (가장 중요)
  • Pragma: 캐시 제어 (하위 호환)
  • Expires: 캐시 유효 기간 (하위 호환)

 

 

 

✏️ Cache-Control

: 캐시 지시어(directives)

• Cache-Control: max-age
  • 캐시 유효 시간, 초 단위
• Cache-Control: no-cache
  • 데이터는 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용
• Cache-Control: no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)
• Cache-Control: public
  • 응답이 public 캐시에 저장되어도 됨
• Cache-Control: private
  • 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본 값) (ex) 사용자 기본 정보같은 것

 

 

 

✏️ Pragma 

:캐시 제어(하위 호환)

• Pragma: no-cache
• HTTP 1.0 하위 호환
• 잘 사용하지 않음

 

 

 

✏️ Exoures

:캐시 만료일 지정(하위 호환)

• expires: Mon, 01 Jan 1990 00:00:00 GMT
• 캐시 만료일을 정확한 날짜로 지정
• 지금은 더 유연한 Cache-Control: Max-age 권장
• Cache-Control: max-age와 함께 사용하면 Expires는 무시 됨

 

 

✏️ 검증 헤더와 조건부 요청 헤더 (정리)

 

 

 

 

 

 

 

 

 

 

 

📌 프록시 캐시

✏️ 프록시 캐시에 대해 알아보자

한국에 있는 클라이언트에서 미국에 있는 원 서버에 접속하려면 한국에 있는 클라이언트들은 모두 0.5초씩 기다려야한다. (생각보다 긺) 그래서 이를 해결하기 위해 프록시 캐시를 도입하였다.

 

 

"프록시 캐시 사용"

 

한국 프록시 캐시 서버를 한국 어딘가에 도입 해놓고, 웹브라우저가 이 proxy-cache 서버에 접근하도록 만든다.
웹 브라우저가 들어오면 기존에 있던 미국에 있는 원 서버로 들어가는 것이 아니라 한국에 있는 프록시 캐시 서버로 IP가 들어가게 된다. 그러면 웹 브라우저 1, 2,3 다 모두 빠르게 응답을 받을 수 있다. (그래서 유튜브같은 걸 빠르게 볼 수 있음.
그래서 외국에 있는 개발 동영상 같이 사람들이 잘 보지 않는 동영상은 되게 느린데, 사람들이 많이 보는 외국 컨텐츠같은 동영상은 로딩이 굉장히 빠르다. )

 

 

 

 

 

 

 

 

 

 

 

📌 캐시 무효화

✏️ Cache-Control: 확실한 캐시 무효화 응답

: 캐시를 적용 안하면 캐시가 안되는거 아닌가요? -> 아니다. 캐시를 적용을 안해도 웹 브라우저들이 GET요청인 경우 임의로 캐시를 해버림

• 사용자의 통장 잔고 등, 이런 것들은 계속 갱신이 될 수 있기 때문에 캐시를 하면 안된다.
• "이런 화면은 절대로 캐시가 되면 안돼"싶을때 이것들을 넣어줘야 한다.
• Cache-Control: no-cache, no-store, must-revalidate
• Pragma:no-cache
  • HTTP 1.0 하위 호환

 

 

✏️ Cache-Control

:캐시 지시어 - 확실한 캐시 무효화

 

• Cache-Control: no -cache
  • 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)
• Cache-Control: no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)
• Cache-Control: must-revalidate
  • 캐시 만료후 최초 조회시 원 서버에 검증해야함
  • 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
  • must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
• Pragma: no-cache
  • HTTP 1.0 하위 호환

 

 

 

 

 

✏️ no-cache vs must-revalidate

 

 

1. no-cache 기본 동작

no-cache는 ETag같은걸로 물고 들어가게 되면 프록시 캐시 서버는 받고 no-cache면 "이거는 내가 처리하면 안되네"라고 하고 원 서버에 요청한다. 그러면 원서버가 검증을 하게 된다.

 

no-cache로 보냈을때 만약에 proxy-cache 서버가 순간 네트워크 단절로 인해 원 서버에 접근이 불가한다면, 장애가 나는 것보다 옛날 데이터라도 보여주자 라는 설정을 하는 경우가 있다. 그러면 proxy-cache 서버는 200으로 응답으로 할 수도 있다.

 

 

2.  must-revalidate 

no-cache로 보냈을때 만약에 proxy-cache 서버가 순간 네트워크 단절로 인해 원 서버에 접근이 불가한다면, 무조건 504 Gateway Timeout을 나오도록 한다.