Proxy
Proxy란
프록시 서버란 인터넷 상의 여러 네트워크들에 접속할 때 중계 역할을 해주는 프로그램 또는 컴퓨터를 의미한다. 프록시는 요청을 가로챈 뒤 응답을 되돌려준다. 이렇게 가로챈 요청을 전달하거나, 하지 않거나(e.g. 캐시), 수정할 수도 있다(e.g. HTTP 헤더 수정).
프록시는 사용자의 로컬 컴퓨터에 존재할 수도 있고, 인터넷 상에서 사용자의 컴퓨터와 기점 서버 사이 그 어느 곳에든 존재할 수 있다. 일반적으로 크게 주로 2가지 종류의 프록시 서버가 존재한다.
-
포워드 프록시(forward proxy)는 인터넷 상에서 어디로든지 요청을 전송해주는 프록시다.
-
리버스 프록시(reverse proxy)는 인터넷에서 요청을 받으면, 내부망 내의 서버로 전송해준다.
Cf. Proxy server - MDN Web Docs Glossary: Definitions of Web-related terms | MDN
Web Cache
프록시 서버(Proxy server)라고도 불리는 웹 캐시(Web Cache)는 기점 웹 서버(Origin Web server)를 대신하여 HTTP 요구를 충족시키는 네트워크 개체다.
-
사용자가 (로컬) 웹 캐시를 가리키도록 브라우저를 구성한다.
-
브라우저는 모든 HTTP 요청을 캐시로 보낸다.
- 캐시에 object가 있는 경우: 캐시가 클라이언트에 object를 반환한다.
- 기점(origin) 서버로부터 object 요청을 받고, 수신된 object를 캐시한 다음 object를 클라이언트에 반환한다.
-
웹 캐시는 클라이언트와 서버의 역할을 모두 수행한다.
- server for original requesting client
- client to origin server
-
서버는 응답 헤더에서 object의 허용 가능한 캐싱에 대해 캐시에 알려준다.
Cache-Control: max-age=<seconds>Cache-Control: no-cache
no-cache 값은 대부분의 브라우저에서 max-age=0 과 동일한 뜻을 가진다. 즉, 캐시는 저장하지만 사용하려고 할 때마다 서버에 재검증 요청을 보내야 한다.Cache-Control: no-store
no-store 값은 캐시를 절대로 해서는 안 되는 리소스일 때 사용한다. 캐시를 만들어서 저장조차 하지 말라는 가장 강력한 Cache-Control 값이다. no-store를 사용하면 브라우저는 어떤 경우에도 캐시 저장소에 해당 리소스를 저장하지 않는다.
max-age=0 값이 Cache-Control 헤더로 설정되었을 때, 매번 리소스를 요청할 때마다 서버에 재검증 요청을 보내야 한다. 네트워크 요청을 아끼고 사용자에게 빠른 웹 경험을 제공하기 위해서 no-store를 사용한다.
웹 캐싱을 사용하는 이유
-
클라이언트 요청에 대한 응답 시간이 단축된다. (∵ 캐시가 클라이언트에 더 가깝게 위치)
-
한 기관에서 인터넷으로의 접속하는 링크(access link)상의 웹 트래픽을 대폭으로 줄일 수 있다.
트래픽을 줄여주면, 기관(회사나 대학)은 자주 대역폭을 개선할 필요가 없어져 비용을 줄일 수 있고, 애플리케이션 성능을 개선한다.
-
콘텐츠 제공업체가 콘텐츠를 보다 효과적으로 전송할 수 있도록 지원한다. (∵ 인터넷에 캐시 밀집)
콘텐츠 전송 네트워크(Content Distribution Network, CDN) 회사는 인터넷 전역을 통해 많은 지역적으로 분산된 캐시를 설치하고 있으며, 이를 통해 많은 트래픽을 지역화하고 있다.
조건부 GET
웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만, 캐시 내부에 있는 객체의 복사본이 새것이 아닐 수 있다는 문제를 야기한다. 다행히도, HTTP는 클라이언트가 브라우저로 전달되는 모든 객체가 최신의 것임을 확인하면서 캐싱을 하게 해주는 방식을 갖고 있다. 이러한 방식을 조건부 GET이라고 한다.
- 클라이언트: HTTP 요청에서 브라우저에 캐시된 복사본의 날짜를 지정한다.
HTTP 요청이 GET 방식을 사용하고,GET /fruit/strawberry.gif HTTP/1.1 Host: www.suhhee.com If-modified-since: Fri, 19 April 2024 22:29:52If-modified-since: <date>헤더 라인을 포함하고 있다면, 그것이 조건부 GET 메세지다.
Cf.date는 같은 요청에 대한 직전 응답에 포함되어 있는Last-Modified날짜다.
- 서버: 브라우저에 캐시된 복사본이 최신인 경우 응답에 object가 포함되어 있지 않다.
HTTP/1.1 304 Not Modified Date: Mon, 22 April 2024 23:59:11 Server: Apache/1.3.0 (Unix) (empty object body)HTTP/1.0 304 Not Modified는 클라이언트에게 요청 object의 캐싱된 복사본을 사용하라는 것을 의미한다. 조건부 GET에 대한 응답으로 웹 서버가 여전히 응답 메시지를 보내지만 응답 메시지에 요청된 object를 포함하지 않음을 볼 수 있다. ⇒ object 전송 지연(또는 네트워크 리소스 사용)이 없다.
Foward Proxy
포워드 프록시란
포워드 프록시는 클라이언트 시스템 그룹 앞에 위치하는 서버다. 이러한 컴퓨터가 인터넷의 사이트 및 서비스에 요청하면 프록시 서버가 이러한 요청을 가로채고 중개자처럼 해당 클라이언트를 대신하여 웹 서버와 통신한다.
포워드 프록시 서버를 사용하면 서버는 실제 클라이언트를 인식하지 못하고 프록시를 클라이언트라고 생각한다.
Cf. 흔히 말하는 ‘프록시 서버’란 포워드 프록시 서버를 의미한다.
포워드 프록시를 사용하는 이유
포워드 프록시는 프라이빗 네트워크 데이터를 외부인으로부터 보호하고 익명화한다.
- 클라이언트 보안 — 일부 정부, 학교, 기타 조직에서는 방화벽을 사용하여 사용자에게 제한적인 인터넷 액세스 권한을 부여한다. 포워드 프록시 서버를 통해 사용자 그룹이 특정 사이트에 액세스하는 것을 차단하도록 설정할 수도 있다.
- 주 당국 또는 기관의 검색 제한 우회 — 포워드 프록시를 사용하여 위와 같은 액세스 제한을 우회할 수 있다. 사용자가 방문하는 사이트에 직접 연결하지 않고 프록시에 연결할 수 있으므로 이러한 제한을 피할 수 있다.
- 캐싱 — 프록시 서버는 해당 페이지 서버의 정보를 캐싱(임시보관)해둔다. 그래서 똑같이 해당 페이지에 접근하거나, 다른 클라이언트가 해당 페이지를 요청할 때 , 캐시된 정보(페이지)를 그대로 반환할 수 있고, 이는 서버의 부하를 줄이는 효과도 낼 수 있다. 포워드 프록시를 이용하면 프록시내 캐싱 된 페이지를 불러오기 때문에 훨씬 빠르게 조회할수 있다.
- 암호화 — 클라이언트의 요청은 포워드 프록시 서버를 통과할 때 암호화된다. 암호화된 요청은 다른 서버를 통과할 때 필요한 최소한의 정보만 갖게 되는데, 이는 클라이언트의 ip 를 (보안을 위해) 감춰주는 보안 효과를 내준다. 따라서 본 서버에서 IP 주소를 역추적해도 포워드 프록시 서버를 사용하면 정체를 파악하기 어렵게 된다. 프록시 서버의 IP 주소만 표시된다.
Use Cases
VPN
가상 프라이빗 네트워크(VPN)는 암호화를 프록시 서버와 결합하여 보다 안전한 통신 채널을 만든다. 기본 기술은 클라이언트 트래픽을 암호화하여 VPN 서버로 라우팅한다. 그러면 VPN 서버가 IP 주소를 추가로 익명화하여 타사 웹 사이트로 라우팅한다. 이러한 사용 사례에서는 VPN 서버를 데이터도 암호화하는 포워드 프록시 서버라고 생각하면 된다.
Reverse Proxy
리버스 프록시란
리버스 프록시는 하나 이상의 웹 서버 앞에 위치하여 클라이언트의 요청을 가로채는 서버다. 이것은 프록시가 클라이언트 앞에 위치하는 포워드 프록시와 다르다. 리버스 프록시를 사용하면 클라이언트가 웹 사이트의 원본(기점, origin) 서버에 요청을 보낼 때 리버스 프록시 서버가 네트워크 에지에서 해당 요청을 가로챈다. 그런 다음 리버스 프록시 서버가 원본 서버에 요청을 보내고 응답을 받는다.
요약하면 포워드 프록시는 클라이언트 앞에 위치하며 원본 서버가 해당 특정 클라이언트와 직접 통신하지 못하도록 하는 것이다. 반면에 리버스 프록시는 원본 서버 앞에 위치하며 어떤 클라이언트도 원본 서버와 직접 통신하지 못 하도록 한다.
리버스 프록시를 사용하는 이유
-
로드 밸런싱 — 매일 수백만 명의 사용자를 확보하는 인기 있는 웹 사이트에서는 단일 원본 서버로 들어오는 모든 사이트 트래픽을 처리하지 못할 수 있다. 대신, 사이트에서는 동일한 사이트에 대한 요청을 모두 처리하는 서로 다른 서버 풀에 분산될 수 있다. 이 경우 리버스 프록시는 단일 서버에 과부하가 걸리는 것을 방지하기 위해 들어오는 트래픽을 여러 서버에 고르게 분산하는 부하 분산 솔루션을 제공할 수 있다. 서버가 완전히 실패하는 경우 다른 서버가 트래픽을 처리하기 위해 나설 수 있다.
-
서버 보안 — 리버스 프록시를 사용하면 웹 사이트 또는 서비스에서 원본 서버의 IP 주소를 공개할 필요가 없다. 이로 인해 공격자가 DDoS 공격과 같은 표적 공격을 활용하기가 훨씬 더 어려워진다. 대신 공격자는 Cloudflare의 CDN과 같은 리버스 프록시만 대상으로 지정할 수 있다. 이는 사이버 공격을 방어하기 위해 더 엄격한 보안과 더 많은 자원을 갖게 된다.
-
캐싱 - 리버스 프록시도 콘텐츠를 캐시할 수 있으므로 성능이 향상된다. 예를 들어, 파리에 있는 사용자가 로스앤젤레스에 있는 웹 서버가 있는 리버스 프록시 웹 사이트를 방문하는 경우, 사용자는 실제로 파리에 있는 로컬 역방향 리버스 서버에 연결할 수 있다. 그러면 이 서버는 LA에 있는 원본 서버와 통신해야 한다. 프록시 서버는 그런 다음 응답 데이터를 캐시(또는 임시 저장)할 수 있다. 사이트를 탐색하는 파리의 후속 사용자는 파리의 역 프록시 서버에서 로컬로 캐시된 버전을 가져오므로 성능이 훨씬 빨라진다.
-
SSL 암호화 - 각 클라이언트에 대한 SSL(또는 TLS) 통신의 암호화 및 암호 해독은 원본 서버의 경우에 계산 비용이 많이 들 수 있다. 리버스 프록시는 들어오는 모든 요청을 해독하고 나가는 모든 응답을 암호화하여 원본 서버의 귀중한 리소스를 확보하도록 구성할 수 있다.
Use Cases
Load Balancer
Cf. 로드 밸런서는 다음 글에서 자세히 알아볼 수 있다.
CDN
CORS Proxy Server
프록시 서버를 사용하여, 서버에서 서버로 요청을 보낼 때는 CORS 에러가 발생하지 않는다는 것을 이용한다.
웹 애플리케이션이 리소스를 직접적으로 요청하는 대신, 프록시 서버를 사용하여 웹 애플리케이션에서 리소스로의 요청을 전달하면, 웹 애플리케이션이 리소스와 동일한 출처에서 요청을 보내는 것처럼 보이므로 CORS 에러를 방지할 수 있다.
- Nginx: reverse proxy 기능을 제공하고, CORS 우회를 위한 설정도 간편하게 수행할 수 있다.
- Apache: reverse proxy 기능을 제공한다. Nginx보다 설정이 다소 복잡할 수 있다. (https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html)
- HAProxy: 고성능 로드 밸런싱 및 프록시 서버다. CORS 우회 기능도 제공하지만, 설정이 다소 복잡할 수 있다. (https://www.haproxy.org/)
Cf. 10 Free to Use CORS Proxies | Nordic APIs |
Forward Proxy vs Reverse Proxy
| 기능 | Forward Proxy | Reverse Proxy |
|---|---|---|
| 위치 | 클라이언트 측 | 서버 측 |
| 감춰지는(대신 작동하는) 대상 | 클라이언트 | 웹 서버 |
| 요청 전달 대상 | 인터넷 | 적절한 웹 서버 |
| 사용 사례 | IP 숨기기, 콘텐츠 필터링, 캐싱 | 로드 밸런싱, 보안, 정적 콘텐츠 제공 |
Additional Resources
References
