캐시

캐시

캐시는 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다.

캐시는 데이터나 값을 미리 복새해 놓음으로써 빠른 속도로 데이터에 접근하기 위해 사용된다.

이런 속도상의 이점 떄문에 컴퓨터의 많은 분야에서 캐시가 사용되고 있다.

대표적인 예로는 CPU 캐시, 디스크 캐시 , 웹 브라우저 캐시 등등 여러 캐시등이 있다.

CPU 캐시

CPU 캐시는 CPU 옆에 존재하는 작은 메모리로, CPU 밖에 존재하는 메인 메모리보다 용량은 적지만 CPU에 가까워 빠른 속도로 데이터에 접근이 가능하다. 따라서 CPU 캐시의 경우 CPU 성능에 직접적인 영향을 주게 된다.

브라우저 캐시

브라우저 캐시는 최근 방문한 사이트를 저장해 놓음으로써 사용자가 다시 사이트를 방문하면 캐시된 데이터를 사용해 빠르게 컨텐츠를 로드할 수 있다.

보통 캐시는 자주 바뀌는 데이터가 아닌 정적 데이터를 저장한다.
따라서 브라우저의 정적자산인 이미지, HTML , CSS , Javascript등을 브라우저 캐시에 저장하게 된다.
또한 , 보통 GET 요청에 대한 응답만 저장을 한다.

브라우저 캐시는 HTTP Cache-control 헤더를 통해 제어할 수 있는데, 자원을 언제, 얼마나 캐시할 지 브라우저에 지정할 수 있다.
또한, 응답 헤더와 요청헤더 둘 다 쓰일 수 있는데, 요청헤더에 쓰일 시에는 중간 서버의 캐시를 가져오지 않겠다는 의미로 종종 쓰인다.

no-store

Cache-Control: no-store
아무것도 캐시 하지 않는다는 의미이다.

no-cache

Cache-Control: no-cache
서버에 캐시를 써도되는지 확인 받고 캐시에 저장한다는 의미이다.

must-revalidate

Cache-Control: must-revalidate
만료된 캐시만 서버에 확인을 받는다.

public, private

Cache-Control: public OR private
public 일 땐 공유 캐시에 저장, private이면 브라우저 같은 private한 공간에 저장

max-age

Cache-Control: private, max-age=3600
캐시의 유효 시간을 할당한다. 초 단위.

캐시 교체 정책

캐시는 성능에 큰 영향을 주지만 그 용량이 작아 모든 데이터를 캐시에 저장할 순 없다.
따라서, 캐시에 어떤 데이터를 저장할 떄 기존의 데이터를 삭제시킬 필요가 있다.

효율적으로 캐시의 데이터를 교체하기 위해 여러가지의 정책이 존재하며 LRU 교체 알고리즘이 주로 사용된다.

LRU 캐시 교체 알고리즘은 가장 최근에 사용된 적이 없는 캐시의 메모리부터 캐시에서 삭제하는 정책이다.

프록시 서버

프록시 서버 또한 대표적인 캐시 사용 예시로써 클라이언트 -> 웹 서버간의 통신을 중계해 주는 역할을 한다.

예를 들면 클라이언트가 어떤 사이트에 접속할 떄, 프록시 서버가 해당 사이트에 대신 요청을 보낸 뒤, 응답을 받아 다시 클라이언트에게 전달해주는 식이다.

왜 굳이 직접 웹서버로 요청을 하지 않고 프록시 서버를 통해 중계하는지 궁금하다.

프록시 서버가 클라이언트와 웹 서버를 중계함으로써 다음과 같은 이점이 발생한다.

1. 개인 정보 보호

만약 www.naver.com 에 Alice가 요청을 보낸다고 하자.
이때, Alice의 IP 주소는 www.naver.com 웹 서버에 전달이 된다.
즉 , Alice의 개인정보인 IP 주소가 www.naver.com 에 노출되는 것이다.

만약 프록시 서버를 사용한다면, www.naver.com에는 프록시 서버의 IP가 기록될 뿐, Alice의 IP 주소는 기록되지 않는다.
따라서 Alice의 IP주소를 보안할 수 있다.

2. 속도 향상

프록시 서버는 캐시를 사용하는데, 최근에 접속한 웹 사이트에 Alice가 또 다시 접속을 요청한다면 미리 캐시해둔 html 파일을 빠르게 제공할 수 있다.

오해 할만한 점

프록시 서버에서는 데이터를 암호화 하지않는다.
프록시 서버는 기본적으로 공용망을 사용하기 떄문에 암호화를 원한다면 VPN을 사용해야한다.