Today
- 웹캐시
- 프록시서버
캐시
- 컴퓨터 캐시 : 일반적으로 일시적인 데이터를 저장하기 위한 목적으로 존
재하는 고속의 데이터 저장공간 - 웹 캐시 : 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치
웹서비스에서 캐시가 적용되는 예제- 클라이언트 & 네트워크 : http캐시 헤더 등
캐시 처리단계
1.요청받기
2.파싱
3.검색
4.신선도 검사
5.응답 생성
6.발송
7.로깅
웹캐시
브라우저에서 캐시를 저장할 땐 헤더에 cache-control 속성을 통해
캐시가 유효한 시간을 지정할 수 있다.
캐시 장점
캐시는 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여준다.
캐시는 원 서버에 대한 요청을 줄여주고
서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다.
브라우저 로딩 속도가 매우 빠르다
캐시 검사
- 캐시의 유효기간이 초과되었지만 변경이 없기때문에 해당 데이터를 써도 되는 상황에 사용되는 검증방법
- HTTP는 캐시 된 객체를 재 확인하기 위해 검증헤더와 조건부요청을(헤더) 사용한다
조건부 GET
서버가 갖고있는 문서가 캐시가 갖고있는것과 다른 경우에 객체 본문을 보내달라고 하는것
HTTP 다섯가지 조건부 요청헤더
- IF-Match
- IF-None-Match (v)
- IF-Modified-Since (v)
- IF-Unmodified-Since
- IF-Range
모든 조건부헤더는 ‘IF-‘ 로 시작한다
Last Modified & IF-Modified_Since
ETag & IF-None-Match
- 캐시 제어 로직을 서버에서 관리하고 싶다면 ETag 사용
Cache-Control ( no-cache vs must-revalidate )
no-cache와 must-revalidate 모두 원 서버에 검증해야하지만 그에 대한 응답에 대해 다른 점이 있다
no-cache
캐시 서버 요청을 하게되고 프록시 캐시 서버에 도착하면 no-cache인 경우 원 서버에 요청을 하게 된다.
그리고 원 서버에서 검증 후 304 응답을 하게 된다.
만약 프록시 캐시 서버와 원 서버간 네트워크 연결이 단절되어 접근이 불가능 하다면,
no-cache에서는 응답으로 오류가 아닌 오래된 데이터라도 보여주자라는 개념으로 200OK으로 응답을 한다.
must-revalidate
원 서버에 접근이 불가할 때 504 Gateway Timeout 오류를 보낸다.
통장 잔고 등 중요한 정보가 원 서버를 못 받았다고 해서 예전 데이터로 뜬다면
큰 문제가 생기기때문에 이런 경우 must-revalidate를 써야 한다.
마치며,
HTTP헤더에 정말 많은 내용들이 담겨있으며 만약 페이지를 구현할 시에는 어떤 페이지를 만들고자에 맞추어서 상황에 맞게 잘 사용해야 할 것 같다.
네트워크는 이론이 중요한거 같아 책과 MDN을 참고하여 다른 내용도 확인해 보아야 할 것 같다.
