김영한 님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 보고 작성한 내용입니다.
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard
1. 캐시
1-1. 캐시가 없는 경우
-
데이터가 변경되지 않아도 매번 네트워크를 통해서 데이터를 다운로드 받아야 한다
-
클라이언트는 서버에게 매번 HTTP header + body 만큼의 데이터를 받는다
-
느린 사용자 경험
1-2. 캐시 적용
-
cache-control: max-age=(초): 캐시가 유효한 시간 (초) -
서버가 응답 메세지를 보낼 때 위의 헤더를 포함해서 클라이언트에게 전송
-
웹 브라우저에서 캐시를 저장하는 브라우저 캐시에 응답 결과를 저장 (위에서 정한 시간 만큼 유효)
-
두 번째 요청하는 경우, 캐시에 있는지 조회
-
캐시에 있고 아직 시간이 유효하다면 네트워크를 사용하지 않고 바로 캐시에서 가져오면 된다
1-3. 캐시가 유효한 시간을 초과한 경우
-
캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다
-
이 때는 다시 HTTP header + body 만큼의 데이터를 받는다
2. 검증 헤더와 조건부 요청
-
캐시의 유효 시간을 초과했지만, 서버에서 데이터를 변경하지 않은 경우 데이터를 다시 다운로드 하는 것이 아니라 저장해 두었던 캐시를 재사용 가능
-
단> 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요
-
검증 헤더
-
캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
-
서버가 클라이언트에게 보내는 응답 메세지에 포함하는 헤더
-
Last-Modified: 데이터가 마지막에 수정된 시간 표기 ( UTC 표기법으로 적음 ) -
ETag: 캐시용 데이터에 임의의 고유한 버전 이름 표기
-
-
-
조건부 요청 헤더
-
클라이언트가 서버에게 요청할 때 포함하는 헤더
-
Last-Modified와 함께 사용하는 헤더-
If-Modified-Since -
If-Unmodified-Since
-
-
ETag와 함께 사용하는 헤더-
If-Match -
If-None-Match
-
-
조건이 만족하면 200 OK 응답을 받음
-
조건이 만족하지 않으면 304 Not Modified 응답을 받음
-
3. 동작 설명
3-1. Last-Modified & If-Modified-Since
-
서버가 최초 요청에 대한 응답 메세지 헤더에
Last-Modified를 추가해서 보냄- ex>
Last-Modified: (날짜 & 시간)
- ex>
- 클라이언트는 응답 결과를 캐시에 저장하면서 헤더에 포함된 데이터 최종 수정일을 기록
-
캐시 시간을 초과한 경우, 클라이언트가 다시 서버에 요청을 보낼 때
if-modified-since: (날짜 & 시간)을 붙여서 요청 메세지 전송- 헤더에 사용하는 날짜와 시간은 캐시에 기록된 데이터 최종 수정일
-
서버의 응답
-
데이터가 수정되지 않은 경우
-
서버가 응답 메세지를 보낼 때 304 Not Modified를 보낸다
-
message body가 없음 ( HTTP 헤더만 전송 )
-
클라이언트는 캐시에 저장되어 있는 데이터 재사용 & 응답 메세지의 헤더 정보로 캐시의 메타 정보 갱신
-
-
데이터가 수정된 경우
-
서버에서 200 OK를 보낸다
-
body를 포함한 모든 데이터를 전송한다
-
-
-
단점
-
1초 미만(0.x초) 단위로 캐시 조정이 불가능
-
날짜 기반의 로직 사용
-
데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
-
서버에서 별도의 캐시 로직을 관리하고 싶은 경우
- ex> 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우
-
3-2. ETag, If-None-Match
-
캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
- 날짜 기반의 로직이 아님
-
데이터가 변경되면 이 이름을 바꾸어서 변경함 (Hash를 다시 생성)
-
Hash는 데이터를 넣었을 때, 데이터가 같다면 같은 값이 나온다
-
Last-Modified의 단점 중, 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우에 다르게 인식하는 경우를 방지
-
-
Last-Modified와 기본 동작 동일
-
ETag만 서버에 보내서 같으면 유지, 다르면 다시 받음
-
캐시 제어 로직을 서버에서 완전히 관리
4. 캐시 제어 헤더
4-1. Cache-Control : 캐시 제어
-
캐시 지시어 (derectives)
-
Cache-Control: max-age: 캐시 유효 시간 ( 초 단위 ) -
Cache-Control: no-cache: 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용해야함 -
Cache-Control: no-store: 데이터에 민감한 정보가 있으므로 저장하면 안됨 ( 메모리에서 사용하고 최대한 빨리 삭제 )
4-2. Pragma : 케시 제어 (하위 호환)
-
Pragma: no-cache -
HTTP 1.0 하위 호환 ( 지금은 거의 사용하지 않는다 )
4-3. Expires : 캐시 유효 기간 (하위 호환)
-
캐시 만료일을 정확한 날짜로 지정 ( 초단위 X )
- ex>
expires: Mon, 01 Jan 1990 00:00:00 GMT
- ex>
-
HTTP 1.0 부터 사용
-
지금은 더 유연한 Cache-Control: max-age 권장
-
Cache-Control: max-age와 함께 사용하면 Expires는 무시
5. 프록시 캐시
5-1. 설명
-
프록시 캐시 서버를 도입하면, 클라이언트가 origin 서버에 접근 할 때 origin 서버에 직접 접근하는 것이 아니라 프록시 캐시 서버를 거쳐서 접근하도록 함
-
프록시 캐시 서버 : 중간에서 공용으로 사용하는 캐시 서버, public 캐시
-
웹 브라우저 : private 캐시
5-2. Cache-Control : 프록시 캐시
-
Cache-Control: public: 응답이 public 캐시에 저장되어도 된다 -
Cache-Control: private-
응답이 해당 사용자만을 위한 것
-
private 캐시에 저장해야 함 ( 기본값 )
-
-
Cache-Control: s-maxage: 프록시 캐시에만 적용되는 max-age -
Age: 60(HTTP 헤더) : origin 서버에서 응답 후 데이터가 프록시 캐시 내에 머문 시간(초)
6. 캐시 무효화
-
캐시를 적용하지 않는다고 캐시되지 않는 것이 아님 ( 웹 브라우저가 GET 요청인 경우 임의로 캐시를 해버리는 경우도 있음 )
-
확실하게 캐시를 무효화 시키려면 아래 헤더 전부를 메세지의 헤더에 넣어주어야 함
-
Cache-Control: no-cache, no-store, must-revalidate -
Pragma: no-cache( 예전 브라우저가 있을 수 있기 때문에 추가 )
-
6-1. Cache-Control : 캐시 무효화
-
Cache-Control: no-cache-
데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
-
origin 서버에서 검증해야하기 때문에 프록시 캐시 서버가 받아도 origin 서버로 넘긴다
-
-
Cache-Control: no-store- 데이터에 민감한 정보가 있으므로 저장하면 안됨 ( 메모리에서 사용하고 최대한 빨리 삭제 )
-
Cache-Control: must-revalidate-
캐시 만료 후 최초 조회 시 origin 서버에 검증해야함
-
원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
-
must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
-
6-2. no-cache와 must-revalidate 비교
-
no-cahce를 사용하면 항상 origin 서버에 검증하고 사용하는데 왜 must-revalidate가 필요한가?
-
if> 프록시 캐시 서버와 origin 서버가 연결이 끊어져서 origin 서버에 접속할 수 없는 경우
-
no-cache의 경우
-
Error를 보낼 것인지, 200 OK를 보낼 것인지 선택할 수 있음
- 오류보다 오래된 데이터를 보내는 것이 낫다고 생각되면 200 OK 를 선택
-
캐시 설정에 따라 프록시 캐시 서버가 Error 아니면 200 OK를 응답
-
-
must-revalidate의 경우
-
항상 오류를 발생
-
504 Gateway Timeout
-
