HTTP - 캐시(3)

이번 포스트에서도 캐시에 대해서 알아보겠습니다.

 

캐시에 대해 알아야 할 것들이 조금 있네요 ㅎㅎ

그래도 계속 이어나가겠습니다.

 

먼저 캐시와 관련된 헤더들 중 알아두면 좋을 것들에 대해 살펴보겠습니다.

1. Cache-Control

• 캐시 제어 헤더
• Cache-Control: max-age
  
  • 캐시의 유효 시간을 나타냄
  • 초(second)단위
• Cache-Control: no-cache
  • 데이터를 캐시해도 되지만
  • 항상 원(origin) 서버에 검증 후 사용하기
    보통 중간에 프록시 캐시 서버가 존재함 → 프록시 캐시 서버가 아닌 원 서버 검증하기
• Cache-Control: no-store
  • 민감 데이터가 있으므로 저장하면 안됨 or 최대한 빨리 삭제
  • ex) 주민번호, 비밀번호 등

요즘에는 Cache-Control 헤더로 거의 모든 것을 처리한다고 합니다.

2. Pragma

• Pragma: no-cache
• 이런 식으로 사용
• HTTP 1.0과 하위 호환됨
• 요즘은 잘 안 씀

3. Expires

• 캐시 만료일 지정
• expires: Mon, 12, Dec 2020 00:00:00 GMT
• 캐시 만료일을 날짜로 저장
• HTTP 1.0 부터 사용
• Cache-Control: max-age가 좀 더 유연 → 권장
  Cache-Control과 Expires를 같이 쓰면 Expires 무시
• 요즘은 잘 안 씀

 

다음으로 프록시 캐시에 대해 알아보겠습니다.

네트워크 통신은 클라이언트와 원(origin) 서버와 통신이 이루어져야 합니다.

근데 origin 서버가 매우 멀리 떨어져 있다면? (ex. 미국)

그러면 이미지 하나 다운받는데도 상당한 시간이 소요된다고 합니다.

이런 문제를 해결하기 위해 프록시 캐시 서버가 생겼는데..

• 클라이언트(웹브라우저) - 프록시 캐시 서버 - 원(origin) 서버
• 이렇게 연결되어 있다고 보면 됩니다.
  그래서 클라이언트는 프록시 캐시 서버와 연결됩니다.
• 클라이언트와 프록시 캐시 서버가 연결되어 있으면 통신이 훨씬 빨라진다고 합니다.
• 클라이언트에서 처음 접속하는 경우는 프록시 캐시 서버에 데이터가 없기 때문에 조금 느림
  그 다음부터는 프록시 캐시 서버에 저장되어 있으므로 빠름

그리고 public, private 캐시 개념도 있습니다.

• public cache: 공용으로 사용되는 캐시 → 보통 프록시 캐시
• private cache: 로컬 & 웹브라우저에 저장되는 캐시

 

그리고 Cache-Control에 대해 조금 더 알아보겠습니다.

• Cache-Control: public
  
  • 응답이 public 캐시에도 저장됨
• Cache-Control: private
  • 응답이 사용자만을 위한 것 →private 캐시에 저장되어야 함
  • 기본값은 private
• Cache-Control: s-maxage
  • 프록시 캐시에서만 적용되는 max-age
  • 보통은 쓸 일이 없음.. 특별한 경우에 사용
• Age: 50
  • 원(origin) 서버에서 응답 후 프록시 캐시 내에 머문 시간 기록
  • 보통은 쓸 일 없음

 

 

다음은 캐시 무효화에 대해 알아보겠습니다.

어떤 경우에는 캐시가 적용되지 않아야 할 떄도 있습니다.

근데 브라우저가 임의로 캐시를 적용할 수 있다고 합니다.

그럼 그런 경우를 방지할 필요가 있겠습니다.

• Cache-Control: no-cache. no-store, must-revalidate
• Pragma: no-cache

이 2가지 헤더를 넣으면 됩니다.

 

1. Pragma: no-cache

• 하위 버전과의 호환 때문에 넣습니다.

2. Cache-Control: no-cache

• 데이터 캐시는 가능하지만, 항상 원(origin) 서버에 검증 후 사용하기

3. Cache-Control: no-store

• 민감 데이터가 있으므로 저장하면 안됨

4. Cache-Control: must-revalidate

• 캐시 만료후 최초 조회 시 원(origin) 서버에 검증 필요
• 원(origin) 서버 접근 실패 시 반드시 오류 발생해야 함
  504(Gateway Timeout)

 

음? 적고보니 no-cache와 must-revalidate이 뭔가 비슷해보입니다.

어떤 부분에서 다를까요?

일단 공통 부분에 대해 알아봅시다.

• ETag와 같이 쓰인다고 가정합니다.
• 요청에 no-cache와 ETag값이 같이 넘어갑니다.
• 프록시 캐시 서버로 넘어간 후 원 서버로 전송됩니다.
• 원 서버에서 ETag값을 검증합니다.
• 만약 ETag 값이 같다면 304 응답코드가 전송될 것입니다.

그런데 만약 어떤 이유로 원(origin) 서버와 통신이 끊겨버린다면?

그래서 원(origin) 서버에서 검증을 할 수 없다면?

이 때는 어떨까요?

no-cache의 경우

• 캐시 서버마다 다르다고 합니다.
• 에러를 전송하거나
• 200 OK를 전송하거나
• 200 OK를 전송하면 옛날 데이터가 맞다고 하는 것이니 이는 문제가 생길 수도 있는 부분입니다.

반면 must-revalidate의 경우

• 원서버에 접근 X?
• 항상 오류코드 전송(항상 오류 발생)
• 504 Gateway Timeout 전송

 

이런 이유가 있기 때문에 must-revalidate도 같이 넣어야 합니다.

 

 

 

이렇게 해서 캐시에 대해 알아봤습니다.

와.. 생각보다 길었습니다.

캐시가 이런저런 거 고민하면 꽤 복잡하네요..

 

 

이렇게 해서 HTTP 캐시에 대한 포스트를 마치겠습니다.

 

 

 

 

 

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