[HTTP] Proxy (프락시)

Web Proxy Server

Web proxy server(이하 '웹 프락시 서버')는 중개자이다. 클라이언트와 서버 사이에 위치하여 그들 사이의 HTTP 메시지를 정리하는 중개인 역할을 한다. 클라이언트 입장에서 트잭잭션을 수행한다. 만약 웹 프락시 서버가 없다면, 클라이언트는 HTTP 서버와 직접 통신해야 하고, 있다면 웹 프락시 서버를 통해 통신하면 된다. 둘 다 트랜잭션을 완료하는 것이 클라이언트라는 점은 변하지 않지만, 프락시 서버가 제공하는 여러 서비스를 이용할 수 있게 된다. 

 

HTTP Proxy Server

HTTP 프락시 서버는 웹 서버이면서 웹 클라이언트이다. HTTP 요청을 받게 되므로, 반드시 웹 서버처럼 요청과 커넥션을 적절히 다루고 응답을 돌려줘야 한다. 동시에 요청을 서버로 요청을 보내기도 하므로 요청을 보내고 응답을 받는 올바른 HTTP 클라이언트처럼 동작해야 한다.

이미지 출처: http://www.ktword.co.kr/abbr_view.php?nav=2&m_temp1=1829&id=902

• 개인 프락시: 하나의 클라이언트만을 위한 프락시, 보통 클라이언트 컴퓨터에서 직접 실행되는 형태이다.
• 공용 프락시: 여러 클라이언트가 함께 사용, 대부분의 프락시는 공용. 중앙 집중형 프락시를 관리하는게 비용 효율이 높고 쉬우며, 여러 사용자들의 공통된 요청에서 이득을 취할 수 있다. 

Proxy vs Gateway

프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결하며, 클라이언트와 서버가 서로 다른 프로토콜로 통신하더라도 서로 간의 트랜잭션을 완료할 수 있도록 해 준다.

이미지 출처: https://www.slideserve.com/fancy/proxies-powerpoint-ppt-presentation

 하지만 실무에서는 프락시와 게이트웨이의 경계가 불분명하다. 왜냐하면 브라우저와 서버는 다른 버전의 HTTP를 구현하기 때문에, 프락시는 프로토콜을 변환하기도 한다. 그리고 상용 프락시 서버는 SSL 보안 프로토콜, FTP 접근 등 웹 기반 애플리케이션을 지원하기 위해 게이트웨이의 기능을 구현한다. 

 

Why proxy server is needed?

 프락시 서버는 실용적이고 유용한 서비스를 제공한다. 보안을 개선하고 성능을 높여주며, 비용을 절약하게 해준다. 그리고 프락시 서버는 모든 HTTP 트래픽을 모니터링할 수 있기 때문에, 부가적인 가치를 주는 여러 유용한 웹 서비스를 구현하기 위해 트래픽을 감시하고 수정할 수 있다.

이미지 출처: https://www.linode.com/community/questions/11167/antiddos-for-https-web-server-by-install-reverse-proxy-layer-7-firewall-filter

 위 그림에서 프락시의 역할이 잘 표현되어 있다. 필터링(제어)를 중앙 집권적으로 프락시에서 해결할 수 있다. 어린이 필터, 문서 접근 제어, 보안 방화벽, 웹 캐시, 대리 프락시(=리버스 프락시), 콘텐츠 라우터, 트랜스코더, 익명화 프락시 등에서 사용되곤 한다. 

 

프락시는 어디에 배치할까?

어떻게 사용할지에 따라서 프락시는 어디에든 배치할 수 있다.

 

프락시 계층

프락시 서버는 연쇄적으로 구성할 수 있으며, 이를 프락시 계층이라고 한다.

이미지 출처: https://www.geeksforgeeks.org/proxy-design-pattern/

 위 그림은 3단계 프락시 계층을 나타낸다. 클라이언트의 요청은 부모 프락시(서버에 가까운 프락시, 클라이언트에 가까운 프락시는 자식 프락시라고 한다.)를 통해 서버로 이동한다. 그리고 서버에서 받은 응답은 다시 부모 프락시(클라이언트에 가까운 프락시, 서버에 가까운 프락시는 자식 프락시)로 이동해서 전달된다. 그리고 위 그림에서 있는 프락시 구조를 "프락시 계층이 정적"이다고 표현한다. 

 물론 모든 프락시 계층이 정적이지는 않다. 예를 들어 유료 서비스를 만들고, 유료 구독자에게는 일반적인 프락시 서버를 통하는 게 아니라 대형 캐시(캐시 프락시)나 성능 개선을 위한 압축 엔진(압축 프락시)으로 라우팅 되게 하는 것이다. 동적 부모 라우팅 로직은 제품(설정 파일, 스크립트 언어, 동적으로 실행 가능한 플러그인 등)에 따라 다르게 구현된다.

 

어떻게 프락시는 트래픽을 처리할까?

클라이언트 트래픽이 프락시로 가도록 만드는 방법은 4가지가 있다. 

 

1. 프락시를 사용하도록 설정한 클라이언트(클라이언트를 수정)

대중적으로 사용되는 브라우저에는 수동 혹은 자동(PAC)으로 프락시 설정을 지원한다. 이때 클라이언트는 HTTP 요청을 바로(의도적으로) 원 서버가 아닌 프락시로 보낸다.

 

2. 트래픽을 가로채어 프락시로 리다이렉트 하는 네트워크(네트워크를 수정)

클라이언트를 알지도 못하고 간섭도 할 수 없는 상태라면 네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 조정한다. 이것을 인터셉트 프락시라고 한다.

 

3. 웹 서버를 위해 설치된 대리 프락시(DNS 이름 공간을 수정)
웹 서버 앞에 위치하는 프락시 서버인 대리 프락시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용한다. 따라서 모든 요청은 대리 프락시로 가게 된다. 

 

4. HTTP 요청을 프락시로 리다이렉트 하는 서버(웹 서버를 수정)

웹 서버에서 HTTP 리다이렉션 명령(305)을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트 하도록 설정한다.  리다이렉트를 받는 즉시 클라이언트는 프락시와의 트랜잭션을 시작한다.