[문과 코린이의 IT 기록장] HTTP - 캐시와 조건부 요청 (캐시 기본 동작, 검증 헤더와 조건부 요청, 캐시와 조건부 요청 헤더, 프록시 캐시, 캐시 무효화)
모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...
www.inflearn.com
[문과 코린이의 IT 기록장] HTTP - HTTP메서드 활용 (클라이언트에서 서버로 - 데이터 전송 , HTTP API
[문과 코린이의 IT 기록장] HTTP - HTTP메서드 활용 (클라이언트에서 서버로 - 데이터 전송 , HTTP API 설계 예시) 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의 실무에 꼭 필요한 HT.
vansoft1215.tistory.com
[문과 코린이의 IT 기록장] HTTP - HTTP 상태코드 (HTTP 상태코드란?, 1xx (Informational), 2xx (Successful), 3xx (
[문과 코린이의 IT 기록장] HTTP - HTTP 상태코드 (HTTP 상태코드란?, 1xx (Informational), 2xx (Successful), 3xx (Redirection), 4xx (Client Error), 5xx (Server Error)) 모든 개발자..
vansoft1215.tistory.com
[문과 코린이의 IT 기록장] HTTP - HTTP 일반 헤더 (HTTP 헤더 개요, 표현(Representation), 콘텐츠 협상 (Cont
[문과 코린이의 IT 기록장] HTTP - HTTP 일반 헤더 (HTTP 헤더 개요, 표현(Representation), 콘텐츠 협상 (Content Negotiation), 전송 방식, 일반 정보, 특별한 정보, 인증, 쿠키) 모든..
vansoft1215.tistory.com
1. 캐시 기본 동작
1) 캐시를 사용하지 않을 경우
- 서버의 데이터가 변경되지 않더라도, 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
* 인터넷 네트워크는 굉장히 느리고 비싸서, 이 과정을 진행하는 것이 비효율적임.
- 따라서 브라우저 로딩 속도가 굉장히 느려지며, 느린 사용자 경험을 제공하게 된다.
2) 캐시를 사용할 경우
- 캐시 덕분에, 캐시 사용가능 시간동안은 네트워크를 사용하지 않아도 된다. 따라서 네트워크 사용량을 줄일 수 있다.
- 또한 브라우저 로딩 속도가 매우 빨라지면서, 빠른 사용자 경험을 제공할 수 있게 된다.
* 웹 브라우저에 들어갔던 페이지에, 다시 들어가면 굉장히 빠른 속도로 접근이 가능한 이유가 이 대문.
=> 만약, 캐시 유효 시간이 초과되었다면, 서버를 통해 다시 데이터를 조회하고 캐시를 갱신해야 한다. 이 과정에서 네트워크 다운로드가 다시 진행된다.
=> 그러나, 데이터의 내용이 변경되지 않았는데(즉 클라이언트와 서버가 가진 데이터가 동일한데), 전체를 다시 다운로드 받으면서 네트워크를 사용하는 것은, 비효율적이다.
=> 이 문제는 검증 헤더 및 조건부 요청을 통해 해결할 수 있다.
2. 검증 헤더와 조건부 요청
[ 캐시 유효 시간 초과시, 서버에 다시 요청할 경우 나타나는 두 가지 상황 ]
1. 서버에서 기존 데이터를 변경했다.
2. 서버에서 기존 데이터를 변경하지 않았다.
=> 2번의 경우, 캐시 만료 후, 캐시를 활용하여, 네트워크 부담을 줄일 수 있는 방법이 존재한다.
* 조건 : 클라이언트와 서버의 데이터가 같다는 사실을 확인할 수 있어야 함.
[ 첫 번째 요청시 ]
[ 두 번째 요청시 - 캐시 재사용 ]
1) 검증 헤더
- 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
ex. Last-Modified / ETag
2) 조건부 요청 헤더
- 검증 헤더로 조건에 따른 분기 진행
a. 조건 만족(데이터가 변경되었을 경우) : 200 OK (HTTP 헤더 데이터 + Body 포함 전송)
b. 조건 만족 X(데이터가 미변경 되었을 경우) : 304 Not Modified (HTTP 헤더 데이터만 전송. Body 미포함)
ex. If-Modified-Since(Last-Modified 응답의 경우) / If-None-Match(ETag 응답의 경우)
3) Last-Modified / If-Modified-Since 단점
- 1초 미만(0.x초) 단위로, 캐시 조정이 불가능하다.
- 날짜 기반의 로직을 사용하기 때문에, 데이터를 수정해서 날짜가 변경되었지만, 같은 데이터일 경우 다운로드를 받게 된다.
ex. A파일 -> B파일로 수정했다가, 다시 B파일 -> A파일로 내용을 수정할 경우, 같은 데이터지만 날짜가 달라지기 때문에다시 다운로드 받을 수밖에 없다.
- 주석 및 스페이스와 같은 큰 영향이 없는 변경이어도, 캐시를 사용하지 못하고 다운로드 받아야 한다.
4) ETag(Entity Tag) / If-None-Match란?
- 캐시용 데이터에 임의의 고유한 버전 이름을 달아두며, 데이터가 변경되면 이 이름을 서버에서 변경한다. (즉 캐시 제어 로직을 서버에서 완전하게 관리한다.)
ex. ETag : "v1.0" => ETag : "v1.1"
- 따라서 단순하게 ETag만 보내서 같은 이름이면 유지하고, 다른 이름이면 다시 받도록 한다.
* 위 Last-Modified / If-Modified-Since의 단점을 개선했다.
- ETag 갱신 사례 : 애플리케이션 배포 주기에 맞춰, ETag를 모두 갱신한다.
ex .웹 브라우저 검증 헤더 / 조건부 요청 사례
3. 캐시와 조건부 요청 헤더
- 캐시 제어와 관련된 헤더들
: Cache-Control : 캐시 제어 / Pragma : 캐시 제어 (하위 호환) / Expires : 캐시 유효 기간(하위 호환)
1) Cache-Control (캐시 지시어, directives)
(1) Cache-Control : max-age
- 캐시 유효 시간. 초 단위로 입력 가능.
* 일반적으로 굉장히 길게 초 단위를 잡아서 사용함.
(2) Cache-Control : no-cache
- 데이터는 캐시를 사용해도 되지만, 이 캐시를 쓰기 전에 항상 if-modified-sice 등 조건부 요청을 통해, 원(origin)서버에게 로컬에 있는 캐시 데이터가 변경되었는지 아닌지 검증하고 사용해야 한다.
* 원(origin) 서버 : 마지막 최종 서버
(3) Cache-Control : no-store
- 데이터에 민감한 정보가 존재하기 때문에, 캐시 데이터는 저장하면 안됨.
- 메모리에서 사용하고 최대한 빠르게 삭제되어야 함.
2) Pragma
- Pargma : no-cache : HTTP의 하위 호환으로, 거의 사용되지 않음.
3) Expires
- Expires : Mon, 01 Jan 1990 00:00:00 GMT
: 캐시 만료일을 정확한 날짜로 지정한다. (HTTP 1.0부터 사용됨)
: 그러나 현재는 이보다 좀 더 유연하게 사용 가능한, Cache-Control:max-age를 권장하고 있다.
* Cache-Control:max-age와 함께 사용되면, Expires는 무시된다.
4. 프록시 캐시
- 한국 클라이언트가 미국 서버에 접근하는 경우, 굉장히 거리가 있기 때문에 사람들이 이미지를 다운 받기 위해, 많은 시간을 기다려야 한다.
- 그래서 프록시 캐시라는 서버를 도입해, 미국 서버에 직접 접근하기 전, 한국 서버를 거쳐 오도록 유도한다.
ex. 사람들이 잘 안보는 유튜브 외국 컨텐츠를 보면, 유튜브 로딩 속도가 굉장히 느림. 그러나, 많이 보는 것을 보면 굉장히 로딩속도가 빠름. => 이미 한국 프록시 캐시 서버에 해당 내용들을 캐시로 보유하고 있기 때문
[ Cache-Control : 캐시 지시어(Directives) 기타 종류 ]
a. Cache-Control : public
- 응답이 public 캐시에 저장되어도 된다.
b. Cache-Control : private
- 응답이 해당 사용자만을 위한 것이며, private 캐시에 저장되어야 한다.
c. Cache-Control : s-maxage
- 프록시 캐시에만 적용되는 max-age
d. Age : 60 (HTTP 헤더)
- 오리진 서버에서 응답 후, 프록시 캐시 내에 머문 시간(초)
5. 캐시 무효화
[ 확실한 캐시 무효화 방법 ]
Cache-Control : no-cache, no-store, must-revalidate
Pragma : no-cache
- 캐시를 적용하지 않아도, Get요청의 경우에는 웹 브라우저들이 대부분 스스로 판단해 캐시를 저장해버린다.
- 따라서, 이 페이지에서는 진짜 캐시 활동이 진행되면 안 될 경우, 위의 코드를 모두 넣어줘야 한다.
ex. 현재 사용자의 통장 잔고 출력 페이지
(1) Cache-Control : no-cache
- 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용해야 한다.
(2) Cache-Control : no-store
- 데이터에 민감한 정보가 있으므로, 저장하면 안 된다. 즉, 메모리에서 사용하고 최대한 빨리 삭제해야 한다.
(3) Cache-Control : must-revalidate
- 캐시 만료 후, 최초 조회시 원 서버에 검증해야 한다.
- 만약 원 서버 접근이 실패한다면, 반드시 504(GateWay Timeout) 오류가 발생해야 한다.
- 캐시 유효 시간이라면 캐시를 사용한다.
(4) Pragma : no-cache
- 아직 HTTP 1.0이하가 사용될 경우, 캐시를 사용하지 않게 하기 위해 이 구문을 작성한다.
[ Cache-Control : no-cache와 Cache-Control : must-revalidate의 차이 ]
- no-cache의 경우, 프록시 캐시에서 원 서버로 보내는 과정에서, 네트워크가 단절될 경우, 오래된 과거 데이터라도 프록시 캐시에서 전송한다.
- must-revalidate의 경우, 프록시 캐시에서 원 서버로 보내는 과정에서, 네트워크가 단절될 경우, 504 Gateway Timeout이 발생한다.
| * 유의사항 - 아직 공부하고 있는 문과생 코린이가, 정리해서 남겨놓은 정리 및 필기노트입니다. - 정확하지 않거나, 틀린 점이 있을 수 있으니, 유의해서 봐주시면 감사하겠습니다. - 혹시 잘못된 점을 발견하셨다면, 댓글로 친절하게 남겨주시면 감사하겠습니다 :) |
