ETag(Entity Tag) -캐시용 데이터에 임의의 고유한 버전 이름을 달아 둠 -> ETag : "v1.0", ETag:"a2asd59" -데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성) -> ETag:"aaaaa" -> ETag:"bbbb" -단순하게 ETag보내서 검증 날짜가 아니고 이름을 붙여 놓는거다.!!!! If-None-Match ---------> 304 or 200 -ETag 보내서 같으면 유지, 다르면 새로~~ -캐시 제어 로직을 서버에서 완전히 관리 -클라이언트는 단순히 이 값을 서버에 제공(메커니즘 모름)

검증헤더 검증 헤더. -캐시 데이터와 서버 데이터가 같은지 검증. -Last-Modified, ETag 조건부 요청 헤더. -검증 헤더로 조건에 따른 분기. -If-Modified-Since: Last-Modified 사용 -If-None-Match:ETag 사용 -조건이 만족하면 200 OK -조건이 만족하지 않으면 304 Not Modified If-Modified-Since: 이후에 데이터 수정되었나~? -데이터 미변경 = 304 Not Modified, Body없는 헤더 데이터만 전송 -데이터 변경 = 200 OK, 모든 데이터 Body포함 전송. 단점 -초단위 미만 불가능 마지막이 초니까. -날짜로 하니까 바꿨다가 다시 원복해도 적용을 못함. -서버에서 별도의 캐시 로직을 관리하고 싶은 경우. ..

검증헤더와 조건부 요청 캐시 시간 초과. 캐시 유효시간이 초과해서 서버에 다시 요청이 오면? -서버에서 기존 데이터를 변경. -서버에서 기존 데이터를 변경하지 않음. 2가지 경우가 나타난다. -데이터가 다르면 어쩔 수 없고. -같은 데이터를 또 받는다? 다시 쓰면 되는데. 단, 서버데이터 로컬캐시 데이터가 같다는 "검증"이 필요. 헤더에 cache-control:max-age=60 Last-Modified:2020년 11월 10일 10:00:00 -최종 Last-Modified!!!!!!!! 그래서 클라이언트가 if-modified-since: 2020년 11월 10일 10:00:00 넣어서 보낸다. 서버: 서버에서 확인을 한다. 어? 똑같네? "검증" 그러면 HTTP/1.1 304 Not Modifie..

HTTP 헤더2 - 캐시 캐시가 없으면 - 요청마다 헤더 바디부, 1.1mb 이미지 내려준다. -데이터 계속 받아야 함. -인터넷 네트워크는 매우 느리고 비싸다. -브라우저 로딩속도 문제. -사용자의 불편함(한국에선 치명적인 '느리다' 경험) 캐시가 있으면 - 요청 -> 브라우저 캐시에 응답결과 저장. 요청 -> 캐시에서 바로 가져옴! 네트워크가 필요가 없어 -네트워크 사용하지 않아도 된다 -비싼 네트워크 사용량 줄인다 -브라우저 로딩속도 매우 빠르다 -빠른 사용자 경험 그런데? 캐시 유효시간이 있다. 만약 60초로 설정되어있으면 그 시간 이후 요청 -> 데이터 다시 조회, 캐시 갱신. -> 다시 다운로드 실행.... 별...뭐가 좋은거지? - 다음 글에 있음