본문 바로가기

전체 글83

캐시 무효화 Cache-Control 확실한 캐시 무효화 응답 Cache-Control : no-cache , no-store , must-revalidate Pragma : no-cache -HTTP 1.0 하위호환(과거 브라우저용) Cache-Control : must-revalidate no-cache사용시 검증 해야하는데 must-revalidate 사용 이유? 캐시 만료 후 최초 조회시 원서버에 검증해야한다! 원서버 접근 실패시 반드시 오류발생 프록시 캐시에서 원서버로 접근 불가시 no-cache 캐시 서버 설정에 따라 캐시 데이터를 반환 할 수 있다 must-revalidate 항상 오류가 발생해야 한다 , 504 Gateway Timeout 2024. 2. 12.
HTTP - 프록시 캐시 프록시 캐시 도입 브라우저 - 프록시 캐시서버(Froxy) - 미국에 있는 원 서버(Origin) 웹브라우저에서 프록시 캐시 서버로 먼저 접근 웹브라우저(private 캐시) 프록시서버(public 캐시) 캐시 지시어 Cache-Control : public 응답이 public 캐시에 저장되어도 됨 Cache-Control : private 응답이 해당 사용자만을 위한 것임 , private캐시에 저장해야 함(기본값) Cache-Control : s-maxage 프록시 캐시에만 적용되는 max-age Age : 60(HTTP 헤더) 오리진서버(원서버)에서 응답 후 프록시 캐시 내에 머문 시간(초) 2024. 2. 12.
HTTP 헤더 2 - 캐시 , 조건부 요청헤더 캐시 , 조건부 요청 헤더 캐시제어헤더 Cache-Control : 캐시제어 max-age : 유효시간 , 초단위 no-cache : 데이터는 캐시해도 되지만 , 항상 원(origin)서버에 검증하고 사용 If-Modified-Since 원서버(origin)의 의미 : 중간 캐시 서버(프록시 서버등)가 아닌 본래의 서버 no-store : 데이터에 민감한 정보가 있으므로 저장하면 안된다(메모리에서 사용하고 최대한 빨리삭제) Pragma캐시제어(하위호환) no-cahce Expires 캐시 만료일 지정(하위호환) 만료일을 정확하게 날짜로 지정 검증헤더/조건부 요청 헤더 검증 헤더 ETag Last-Modified 조건부 요청 헤더 If-Match , If-None-Match : ETag값 사용 If-Mod.. 2024. 2. 12.
HTTP 헤더2 - 캐시 기본동작 , 조건부 요청 캐시가 없으면 데이터가 변경되지 않아도 요청시마다 계속해서 다운로드를 받아야 한다 캐시적용 1 캐시가 유효한 시간 설정 캐시 적용 2 캐시덕분에 네트워크 사용량 줄일수 있다(비용 감소) 브라우저 로딩속도 빠르다 빠른 사용자 경험 캐시 적용3(캐시시간 초과) 유효시간 초과시 서버통해서 데이터 다시 조회, 캐시 갱신 이따 다시 네트워크 다운로드 발생(비용발생) stay? 캐시시간이 초과 되었다면 재요청시 조회 , 갱신과 같은 과정을 반복하여 다시 다운로드를 해야한다 ex) 기존 데이터와 완전히 동일하지만 캐시시간 초과되었다는 이유로 같은 동작을 또 수행해야한다 => 트래픽 발생 캐시 초과하여 서버에 재요청시 두가지 상황이 나타난다 1. 서버에서 기존 데이터를 변경 2. 서버에서 기존 데이터 변경하지 x 2번.. 2024. 2. 12.

티스토리툴바