8.HTTP 헤더2 - 캐시와 조건부 요청

인프런의 모든개발자를 위한 HTTP 웹 기본 지식 강의를 들은 내용을 정리하는 포스트입니다. 

---

캐시 기본 동작

캐시란 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다.  캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수있기 때문이다. (위키피디아 정의)

HTTP 통신에서도 캐시를 사용한다. 

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

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

처음 응답을 받을때 캐시에 저장하라고 서버에서 응답을 받으면 해당결과를 브라우저가 유효시간동안 캐시에 저장해둔다.

그 이후 유효시간내에 같은자료를 요청하면 서버로 가지 않고 브라우저 캐시에서 꺼내쓴다. 

그런데 캐시유효시간이 초과되면 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다. 데이터가 바뀌었다면 이해가가지만 여전히 바뀌지 않은 데이터에 대해서도 이렇게 하는건 너무 비효율적이지 않을까?

=>그래서 검증헤더와 조건부 요청을 이용한다.

---

검증 헤더와 조건부 요청

캐시만료후에도 서버에서 데이터를 변경하지않았다면...
=> 클라이언트가 저장하고 있는 캐시를 재사용할 수 있을거다....
=> 다만 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요함.

• 검증 헤더
- 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
- Last-Modified , ETag
- ETag: "v1.0", ETag: "asid93jkrh2l"
- Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT

• 조건부 요청
- 검증 헤더로 조건에 따른 분기
- If-Modified-Since: Last-Modified 사용
- If-None-Match: ETag 사용
- 조건이 만족하면 200 OK
- 조건이 만족하지 않으면 304 Not Modified

• ETag, If-None-Match
- 진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기!
- 캐시 제어 로직을 서버에서 완전히 관리
- 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)
ex) 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

---

캐시 제어 헤더

• Cache-Control: max-age
• 캐시 유효 시간, 초 단위

• Cache-Control: no-cache
• 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용

• Cache-Control: no-store
• 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

• Pragma: no-cache
• HTTP 1.0 통신요청이 들어왔을때 하위 호환을 위해서 사용함.(지금쓰는 HTTP는 주로 1.1이니까....)

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

---

프록시 캐시

프록시 캐시는 원(origin)서버가 너무 멀어서 좀더 가까운 곳에 캐시서버를 설치하고 거기에 캐시를 저장해서 데이터를 더 빠르게 전달 할 수 있는 캐시를 의미한다. 

한국의 클라이언트들은 프록시 캐시에저장된 캐시로 빠르게 정보를 받아 볼 수 있다.

관련 지시헤더
• Cache-Control: public
• 응답이 public 캐시에 저장되어도 됨

• Cache-Control: private
• 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)

• Cache-Control: s-maxage
• 프록시 캐시에만 적용되는 max-age

• Age: 60 (HTTP 헤더)
• 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

---

캐시 무효화

요즘의 클라이언트는 많이 발달해서 캐시관련 헤더를 표기하지 안아도 자기가 멋대로 캐싱을 해버리는 경우가 종종있다. 따라서 민감한 정보등의 보안을 위해 확실하게 캐싱을 하지말라고 메세지에 표현해두고 싶다면 아래와 같이 써야한다. 

• Cache-Control: no-cache, no-store, must-revalidate
• Pragma: no-cache (HTTP 1.0 하위 호환 때문에 같이 표기)

no-cache와 must-revalidate를 같이 쓰는 점이 의아할수 있는데 위의 도식처럼 no-cache의 경우 프록시 서버에 따라 오류가아니라 원래데이터를 보여주는 경우도 있기 때문에 504 메세지를 받기 위해서는 must-revalidate가 필요하다.