Aug 5, 2021 - HTTP 검증, 조건부, 캐시

*8월5일

-오늘부로 HTTP 관련 강의를 완강했다. HTTP에 대한 부분적인 이해만으로 프로젝트를 진행했었는데, 이번 기회로 기초를 다진 느낌이다.

 

*HTTP 헤더 캐시

-캐시가 없을 때는 특정한 자료 요청 할 때마다 헤더와 바디로 구성된걸 계속 새로 보냄; 속도,비용면에서 매우 비효율적

-캐시 적용 시 HTTP header에 cache-control : max-age=60으로 넣으면, 60초 동안 해당 캐시 유효함을 나타냄. 따라서 브라우저 캐시에 60초 동안 해당 이미지가 유효해서 재 요청 시에도 서버로 가지않고 브라우저 캐시에서 꺼내서 씀. 따라서 속도 비용면에서 매우 효율적; 

->캐시 유효시간 초과 시, 새롭게 서버에서 데이터 내려주고, 기존 캐시 덮어써서 60초 유효시간 리셋; 즉 네트워크는 사용하게 된 것!

 

*검증 헤더 및 조건부 요청 헤더

-캐시 유효 시간 초과 후, 서버에서 데이터를 변경 했을 수도 있고, 기존 데이터를 변경하지 않았을 수도 있음;

->만약 바뀌지 않았다면 검증 헤더(Last-Modified:2020년 11월 10일 10:00:00)를 통해서 검증 후 데이터 전송 요청 or 캐시 사용 처리를 할 수 있음.

->캐시에 cache-control 및 last-modified를 모두 저장함;

->last-modified가 존재 시, 재요청할때 if-modified-since를 넣어서 검증함.

->서버에서 수정이 안됐으면 304 not modified로 응답하여 body를 전송하지 않음; 따라서 header만 날아가게 됨

->브라우저에서는 cache-control 값 갱신 후, 데이터 사용

-if-modified-since로 요청 시, 데이터 변경 시 200 OK와 함께 모든 데이터 전송, 데이터 미변경시 304 not modified를 주면서 캐시로 redirection 처리

 

*last-modified, if-modified-since의 단점 

-1초 미만 단위로 캐시 조정 불가

-날짜 기반 로직 사용

-서버에서 별도의 캐시 로직을 관리하고 싶은 경우

-데이터를 수정해서 날짜가 다르지만, 최종 데이터가 똑같은 경우? (a to b,  to a) + 날짜 변경 -> 재 다운로드 해버림

 

*해결책으로 ETag(entity tag), if-none-match

-캐시용 데이터에 임의의 고유한 버전 이름을 달아둠; ETag v1.0, ETag a2jiodwjekil3;

-캐시 제어 로직을 서버에서 완전히 관리; 클라이언트는 단순히 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)

-애플리케이션 배포 주기에 맞추어 ETag 모두 갱신 -> 다 다시 다운받게 처리

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

-단순하게 ETag만 보내서 같으면 유지, 다르면 다시 다운로드 처리; 날짜는 그냥 무시해버림!

 

요청 시 header에 cache-control: max-age=60, ETag: "aaaaaa"; 

->두번째 요청 시 시간 60초가 초과됐으면, if-none-match : "aaaaaa"를 보냄, 만약 수정이 안됐으면 304 not modified가 응답됨.

 

 

*캐시제어헤더

 

1)cache-control

-max-age : 유효 시간 초단위

-no-cache : 데이터는 캐시해도 되지만, 항상 origin 서버에 검증(if-modified-since or if-none-match)하고 사용

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

-must-revalidate : 캐시 만료 후 최초 조회 시 원서버에서 검증해야함; 원서버 접근 실패시 반드시 오류가 발생해야함(504 gateway timeout), 캐시 유효 시간이라면 캐시를 사용함.

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

-private : 응답이 해당 사용자만을 위한 것임(기본값)

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

-age:60 : 오리진 서버에서 응답 후 프록시 캐시내에 머문 시간(초)

 

2)pragma

-캐시제어, no-cache, HTTP 1.0 하위 호환

 

3)expires

-expires : Mon, 01 Jan 1990 00:00:00 GMT

-캐시 만료일 지정, 하위 호환.

-캐시 만료일을 정확한 날짜로 지정; 지금은 더 유연한 Cache-Control:max-age 권장하고 있으며, 함께 사용되면 expires는 무시됨.

 

*검증 헤더(validator)

-ETag: "v1.0", ETag:"asid93jrh2l"

-Last-modified: Thu, 04, Jun 2020 07:19:24 GMT

 

*조건부 요청 헤더

-if-match, if-none-match : Etag값 사용

-if-modified-Since, if-Unmodified-Since : Last-modified 값 사용

 

*프록시 캐시(CDN server, cloudFront)

-유튜브 시청 시, 사람들이 잘 안보는 외국 컨텐츠 볼시 꽤 느림; 사람들이 많이 보는 컨텐츠는 속도가 준수함; 많이보는 컨텐츠는 한국 내 프록시 캐시 서버에 있는 것임;

-개개의 웹브라우저가 private 캐시를 보유, 프록시 캐시 서버가 public 캐시를 보유

 

*캐시 무효화

-확실한 캐시 무효화 응답; 일반적인 경우에는 웹브라우저가 자동으로 캐시 해버릴 수 있음; 

 

ex)사용자 통장 잔고는 조금이라도 오류가 날 시 큰 혼선 초래할 수 있음(이체 전, 후의 잔고)

 

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

Pragma : no-cache //과거 버전 막기 위해;

 

*no-cache와 must-revalidate의 차이

-no-cache에 따르면 반드시 원서버에 접근해야하고, must-revalidate에 따르면 반드시 에러가 발생 시 에러를 띄워야 함

-no-cache의 경우 원서버와 프록시서버사이에서 순간적인 네트워크가 단절되어도 기존에 있던 정보라도 응답해줄 수 있음(error or 200 OK)

-must-revalidate의 경우, 원서버와 네트워크가 단절되면, 무조건 504 gateway timeout을 응답하게 함; 통장 잔고와 같은 것은 프록시 캐시를 사용해서 절대 보여주면 안됨.....