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

 

본 포스팅은 우아한 형제들, 김영한 님의 '모든 개발자를 위한 HTTP 웹 기본 지식' 강의를 수강 후 정리한 글입니다.

 

 

 

1. 캐시 기본 동작

-> 아래와 같이 star 이미지를 요청하면 1.1Mbyte 용량의 데이터가 전송된다 (헤더 + 이미지 용량).

-> 캐시가 없을 때, 두번째 요청을 한다면 똑같이 1.1Mbyte 용량의 데이터가 전송된다 (같은 요청이니, 같은 용량 전송)

 

2. 캐시가 없을 때, 

-> 서버측의 데이터가 변경되지 않아도 계속 네트워크를 통해 데이터를 다운받아야 한다.

-> 느리고 비싸며, 브라우저 로딩 속도가 느리다 = 느린 사용자 경험 (slow ux)

 

3. 캐시 적용할 때,

-> 1.1Mbyte의 데이터를 캐시 저장소에 저장한다.

-> 두번째 요청에서 웹 브라우저는 네트워크를 타지 않고, 브라우저 캐시에서 곧 바로 데이터를 조회할 수 있다.

4. Cache-control: Max-age = 60

-> 60초 동안만 유효한 캐시.

-> 60초 이후 부터는, 서버에서 새로 데이터를 받아와 캐시에 저장해야한다 (캐시 갱신).

-> server와 캐시의 데이터가 다른 경우도 발생할 수 있음을 인지하자 (서버 데이터의 업데이트 경우)

 

5. 캐시 시간 초과일 때, 

• 1) 서버에서 기존 데이터를 변경
• 2) 서버에서 기존 데이터를 변경하지 않음 -> 시간 초과된 캐시 데이터와 서버 데이터가 같다는 사실을 확인할 수 있다면, 기존 캐시의 데이터를 재사용 가능

6. 검증 헤더 추가 < 첫 번째 요청 >

-> Header에 last-modified 검증 헤더 추가

-> 데이터가 마지막에 수정된 시간 표시

7. 검증 헤더 추가 < 두 번째 요청 >

8. 검증 헤더(last-modified)와 조건부 요청(if-modified-since)

-> 304 not Modified + 헤더 메타 정보만 응답 된다. ( 바디 x )

-> 캐시의 메타 정보는 서버가 보낸 응답 헤더 정보로 갱신된다.

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

-> 결과적으로, 네트워크 다운로드가 발생하지만, 용량 적은 헤더 정보만 다운로드한다 => 매우 실용적인 해결책

 

9. ETag (Entity Tag)

-> 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다. ex) ETag: 'v1.0', ETag: 'v2.0'

-> 데이터가 변경되면 이 이름을 바꾸어 변경함 (Hash를 다시 생성)

• ex) ETag: 'aaaa' --> ETag: 'bbbb'

10. ETag 동작 원리-결과

-> ETag만 보내서 같으면 유지, 다르면 다시 네트워크를 탄다. (key-value 비교 형식)

-> 캐시 저장소에서 보낸 ETag와 서버의 ETag는 이름은 같지만, hash 방식이기에, value값이 다를 수 있다(데이터가 업데이트 됐을 시). 

-> 즉, ETag만 서버에 보내 일치/불일치 여부를 확인 할 수 있고, 그리하여 캐시제어 로직을 서버에서 완전히 관리할 수 있게 된다.

 

11. 캐시 제어 헤더

• Cache-control: 캐시 제어
• Pragma: 캐시 제어 (하위 호환)
• Expires: 캐시 유효 기간 (하위 호환): 캐시 만료일을 정확한 날짜로 지정 -> 지금은 더 유연한 cache-control: max-age 권장

12. Cache-control

-> max-age: 캐시 유효 시간, 초 단위

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

-> no-store: 데이터에 민감 정보 있으면 저장하지 않는다.

 

13. 조건부 요청 헤더

• if-match, if-none-match: ETag 값 사용
• if-modified-since, if unmodified-since: last-modified 값 사용
• ETag와 last-modified 둘은 서로 반대된다.

14. 프록시 캐시

-> 자주 사용되는 데이터를 proxy 캐시 서버에 배치

-> 0.5초 걸려 미국 서버까지 가지 않고, 프록시 서버에서 0.1초만에 해결한다.

 

-> cache-control: public -> 응답이 public 캐시에 저장되어도 됨

-> cache-control: private -> 응답이 해당 사용자만을 위한 것 ( private 캐시에 저장해야한다(기본값) )

 

15. 캐시 무효화

-> 확실한 캐시 무효화: 중요한 정보나 민감 데이터를 다룰 경우 확실히 캐시를 무효화 설정해야한다.

 

16. Cache-control

• no-cache: 데이터는 캐시해도 되지만, 항상 origin서버에 검증하고 사용
• no-store: 데이터에 민감한 정보가 있으므로, 저장하면 안된다.
• must-revalidate: 캐시 만료 후 최초 조회시 origin 서버에 검증하고 사용 -> origin 서버 접근 실패시 반드시 오류가 발생해야함 (504, Gateway Timeout)

17. no-cache와 must-revalidate의 차이

-> no-cache

-> must-revalidate