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

1. 캐시 기본 동작

 

1) 캐시가 없을 때

- 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 함.

- 인터넷 네트워크는 매우 느리고 비싸다.

- 브라우저 로딩 속도가 느리다.

- 느린 사용자 경험

 

2) 캐시 적용

- 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨.

- 비싼 네트워크 사용량을 줄일 수 있음.

- 브라우저 로딩 속도가 매우 빠르다.

- 빠른 사용자 경험

>> 첫 번째 요청 시 캐시가 유효한 시간을 서버에서 응답으로 보내면 > 클라이언트에서 받아 브라우저 캐시에 저장

>> 이후 새로 요청이 왔을 때 브라우저 캐시를 먼저 살피고 유효시간이 초과되지 않으면 캐시에서 조회할 수 있음.

>> 만약 캐시 시간이 초과될 경우 다시 클라에서 서버로 요청을 보내고 다시 같은 형식의 응답을 보내주면 캐시를 갱신한다. 이때 다시 네트워크 다운로드가 발생한다. 

 

 

2. 검증 헤더와 조건부 요청 1

1) 캐시 시간 초과 시

: 서버에 다시 요청했을 때 두가지 상황이 나타난다. 

• 서버에서 기존 데이터를 변경함.
• 서버에서 기존 데이터를 변경하지 않음. -> 이 경우에 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용할 수 있다! (단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 방법이 필요!!)

 

2) 검증 헤더 추가

>> 첫 번째 요청을 보낼 때 캐시 유효 시간과 함께 Last-Modified 데이터가 마지막에 수정된 시간을 함께 응답에 담아 보낸다. 이를 브라우저 캐시에 저장할 때에도 Last-Modified를 함께 저장해둔다. 

>> 캐시 유효 시간이 초과되었을 때 다시 두 번째 요청을 보내며 데이터 최종 수정일을 함께 보낸다.

>> 서버 측에서 최종 수정일을 확인하고, 수정되지 않았다면 HTTP 응답을 304 Not Modified를 보내준다. 헤더만 있고, HTTP Body는 없이 보낸다. 그렇게 되면 네트워크 부하가 줄어든다.

>> 이후 클라 측에서 다시 캐시를 갱신한다. 

 

3) 정리

- 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 -> 304 Not Modified + 헤더 메타 정보만 응답.

- 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신

- 클라이언트는 캐시에 저장되어 있는 데이터 재활용 가능

- 결과적으로 네트워크 다운로드가 발생하긴 하지만, 용량이 적은 헤더 정보만 다운로드! 

 

3. 검증 헤더와 조건부 요청2

 

1) 검증 헤더

- 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터

- Last-Modified, ETag

 

2) 조건부 요청 헤더

- 검증 헤더로 조건에 따른 분기

- If-Modified-Since: Last-Modified 사용

- If-None-Match: ETag 사용

- 조건이 만족하면 200 OK

- 조건 불만족시 304 Not Modified

 

3) Last-Modified, If-Modified-Since 의 단점

- 1초 미만(0.x초) 단위로 캐시 조정이 불가능

- 날짜 기반의 로직 사용

- 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우

- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 (ex. 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우)

 

4) ETag(Entity Tag), If-None-Match

- 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠 / 데이터가 변경되면 이 이름을 바꾸어서 변경함 (Hash를 다시 생성)

- 진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기! 

- 캐시 제어 로직을 서버에서 완전히 관리. 

- 클라이언트는 단순히 이 값을 서버에 제공 (캐시 매커니즘을 모름!)

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

 

>> 첫 번째 요청 시 서버 측에서 ETag를 함께 응답으로 첨부하고, 클라이언트는 이를 ETag와 함께 캐시에 저장한다. 

>> 두 번째 요청 시 캐시 시간이 초과하면 If-None-Match로 캐시에 있는 ETag 값을 요청과 함께 보낸다. 

>> 서버에서 ETag 값을 확인 후 같으면 304 Not Modified로 HTTP Body 없이 응답을 보낸다. 

 

 

4. 캐시와 조건부 요청 헤더

1) Cache-Control 캐시 제어

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

2) Pragma 캐시 제어 (하위 호환)

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

3) Expires 캐시 유효 기간 (하위 호환)

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

 

5. 프록시 캐시 

 

1) Cache-Control 

• Cache-Control: public 응답이 public 캐시에 저장되어도 됨
• Cache-Control: private 응답이 해당 사용자만을 위한 것. 기본값
• Cache-Control: s-maxage 프록시 캐시에만 적용되는 max-age
• Age: 60 (HTTP 헤더) 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간 (초)

 

6. 캐시 무효화

1) 확실한 캐시 무효화 응답

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

>> no-cache의 경우 원 서버에 확인 요청을 하고 원 서버의 검증을 거친 뒤 응답을 하는데, 원 서버에 접근할 수 없는 경우에는 프록시 캐시에서 응답할 수가 있다.

>> must-revalidate의 경우에는 똑같이 원 서버에 확인 요청을 하는데, 원 서버에 접근할 수 없는 경우에는 항상 오류가 발생되어야 한다. (504 Gateway Timeout)

 

>> 결론 : 이렇게 해야 확실하게 캐시 무효화가 된다는 이야기. 

 

 

 

 

 

 

 

---

** 해당 내용은 김영한님의 강의를 수강하며 정리한 것입니다.

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 강의 | 김영한 - 인프런