[Network] Cashe(캐시)의 정의 그리고 웹캐시와 Proxy Server, Reverse Proxy 비교

Cashe(캐시)

- 자주 사용되는 데이터를 빠르게 다시 사용할 수 있도록 임시 저장해두는 공간이나 시스템(속도 향상 & 트래픽 감소 목적)

 

 

캐시 종류 설명 예시

브라우저 캐시 (Browser Cache)	사용자 컴퓨터에 저장됨. HTML, CSS, JS, 이미지 등	크롬 개발자 도구에 나오는 from disk cache
프록시 캐시 (Proxy Cache)	중간 서버가 여러 사용자를 위해 저장	학교/기업 네트워크의 프록시 서버(ex. Squid)
CDN 캐시 (Edge Cache)	CDN 서버가 전 세계 여러 위치에 콘텐츠 캐싱	Cloudflare, Akamai, AWS CloudFront
서버 캐시 (Reverse Proxy Cache)	웹 서버 앞단에서 캐시해서 백엔드 접근 줄임	Nginx, Varnish
애플리케이션 캐시	백엔드 애플리케이션 내부의 캐시	Redis, Memcached 등

 

 

Proxy 서버

proxy 서버는 reverse proxy와 이름이 비슷해서 둘을 비교해서 생각하는 경우가 많은데, 그전에 origin server와 대비 되는 개념으로 먼저 이해하는 게 좋다. 애초에 프록시 서버가 생겨나게 된 개념도 origin server의 요청에 대한 캐시역할과 네트워크 bandwidth를 낮추기위한 목적으로 설치된 개념이다. 

 

다음과 같은 네트워크가 있다고 생각해보자. proxy server가 없는 일반적인 Ethernet 기반의 기업 네트워크의 인터넷 액세스를 표현하는 네트워크다. 웹서비스에서 평균적으로 제공하는 object의 크기가 1Mbits이고, browser를 통해서 origin server를 통해  평균 요청 횟수가 초당 15회라고 가정하면, access link를 통해 전송되어야 하는 평균적인 데이터 양은 15Mbps다. 그런데, access link의 bandwidth(transmission rate)가 15.4Mbp라면, traffic intensity는 거의 1에 육박한다.  traffic intensity의 크기가 0.7만 되더라도  delay가 엄청난 양으로 증가하는데, traffic intensity가 1에 가깝다는건, delay가 수십초 이상으로 증가된다는 소리다. 네트워크에서 이정도 속도는 엄청난 delay인데, 주로 access link에서 발생하는 경우가 많다. 

(cf. traffic intensity(link utilization) = traffic 유입속도 / bandwidth(transmission rate))

그리고 RTT(round trip time)이 2초라면, 총 시간이 2sec + minutes + few micrro sec => 여기서 minutes가 바로 access link에서 발생하는 delay 때문이다.

 

위 설명 예시

 

 

해결 방법은 access link를 bandwidth가 큰 access link로 교체하는 방법이 있고, 다른 방법은 여기서 설명하려는 web cashe로 proxy server를 두는 방법이 있다. access link는 정기적으로 ISP에 비용을 지불해야하고 매우 비싸다. 그래서 대게 proxy server를 통해 해결한다.

그런데 사용자의 요청에 Web cache는 무작정 응답하는 것이 아니고, 이 내용이 업데이트 되었는지 original server에 확인을 해야하는데 이때 사용하는 메서드가 conditional GET메서드다. conditional GET 메서드를 통해서 서버에 HTTP request를 보낼 때는 header에 'If-modified-since: <date>'라는 헤더라인을 담아서 보낸다. 

서버는 이 header라인을 보고 <date> 적힌 날짜 이후에 변경사항이 없다면, HTTP/1.0 304 Not Modified라는 응답 메세지를 proxy server로 응답한다. 그러면 proxy server는 이 내용을 보고 client에 cashe에 담긴 object를 응답한다.

당연히 <date>이후에 변경된 사항이 있다면, 200 OK 응답 상태코드와 함께 변경된 데이터를 응답한다.

 

proxy server로 local web cache를 통해 network delay를 해결한 방법 예시 그림.

 

 

이렇게 되면 15번의 요청중에서 최초의 요청만 origin servers로 요청이 갈 것이고, 이후의 요청은 proxy server로 요청이 간다. proxy server와 다르게 origin server 쪽에도 비슷한 역할을 하는 server가 있는데 이게 바로 reverse proxy이다.

 

 

리버스 프록시와 정방향 프록시 정리

관점	리버스 프록시	정방향 프록시
내가 서버 운영자	✅ 사용함 (내 서버 보호, 성능 향상)	❌ 불필요
내가 클라이언트	❌ 사용 안 함	✅ 사용 가능 (외부 요청 캐시)
주체	서버 측에 설치	클라이언트 측 네트워크에 설치
주 목적	서버 부하 분산, 캐시, 보안	외부 요청 절약, 검열, 로깅 등

 

 

• 정방향 프록시 사용 예시
  • 학교에 입장에서 링크 대역폭으로 초과로 인한 네트워크 트래픽이 증가하면, 프록시 서버를 두어 access netowork와의 트래픽을 최소화하고 내부 캐시를 통해 속도 저하 문제 해결 가능.
  • 이러한 웹 캐시는 ISP에 의해서 설치되는데, 영세한 content provider는 이러한 웹캐시의 덕을 볼 수 있다. 웹 캐시는 네트워크의 엣지에 설치되어 있는데 여러 곳곳에 웹캐시가 잘 분포 되어 있다면, 여러 ISP와 연결되어 있지 못한 영세한 content provider도 효과적으로 컨텐츠를 전달 할 수 있다.

 

• 리버스 프록시 사용 예시
  • 반대로 인터넷 서비스 제공 기업 입장에서 클라이언트 요청에 서버의 부하를 분산하기 위해 웹서버 앞단이나 웹서버 내부에 리버스 프록시를 둘 수 있다.

 

 

 

리버스 프록시와 정방향 프록시 사용 용도에 따른 정리

Nginx	리버스 프록시 (Reverse Proxy)	웹 서버 앞단에서 로드밸런싱, 캐싱, SSL 종료 등
Squid	정방향 프록시 (Forward Proxy)	클라이언트 측에서 외부 요청 필터링, 캐싱, 로깅 등

 

Nginx, Squid 비교

Nginx – 리버스 프록시 전문

• 서버 측에서 운영 (내 서버 보호 & 성능 향상)
• 특징:
  • 정적 리소스 캐싱
  • 로드 밸런싱
  • HTTPS SSL 종료
  • 웹 서버 앞단 보안 역할
• 가벼우면서도 고성능
• 설정도 상대적으로 직관적

 

Squid – 정방향 프록시 전문

• 클라이언트(회사, 학교, 내부망) 측에서 운영
• 특징:
  • 외부 사이트 접근 통제 (차단/허용)
  • 외부 요청 캐싱 (속도 향상 & 트래픽 절감)
  • 로깅 및 사용자 추적
  • 인증 및 필터링 가능
• ISP, 교육기관, 대기업 방화벽 시스템에서 많이 사용됨

 

 그럼 Nginx는 정방향 프록시 역할 못 하나?

• 할 수는 있지만 일반적이지 않다.
• 정방향 프록시는 인증, 접근 제어, 캐싱 등이 더 중요하고 복잡해서 Squid 같은 전용 솔루션이 적합하다.

 

요약

• Nginx는 “내가 서버 운영자”일 때 사용하는 리버스 프록시
• Squid는 “내가 외부 요청을 보내는 클라이언트 조직”일 때 사용하는 정방향 프록시

 

 

참고자료 :  Computer Network Top-Down Approach Network 7th, KOCW 네트워크 강의(이화여대 이미정 교수)