Proxy(프락시)

클라이언트와 서버 사이에 위치하여 중개해주는 역할

웹 중개자

클라이언트는 HTTP 서버와 직접 통신해야 하지만, 프락시를 통해 통신할 수 있다. 프락시는 서버이기도 하면서 클라이언트 역할을 수행하여 클라이언트의 요청을 서버에 전달하고, 서버의 응답을 클라이언트에 전달한다.

공유 프락시 / 개인 프락시

프락시는 하나의 클라이언트가 독점적으로 사용하는 개인 프락시와 여러 클라이언트가 공유하는 공유 프락시로 나뉜다.

공유 프락시 (Shared Proxy)

대부분의 프락시에 해당하며, 중앙 집중형 프락시를 관리하는게 더 비용 효율이 좋다. 캐시 프락시와 같은 몇몇 프락시 애플리케이션은 이용자 수가 많을 수록 효율이 좋다.(공통된 요청에서 이득을 얻을 수 있음)

개인 프락시 (Private Proxy)

흔하지 않은 방식이며, 개인 프락시를 사용하는 이유는 보안이나 익명성을 위해서이다.

프락시 vs 게이트웨이

  • 프락시: 같은 프로토콜을 사용하는 둘 이상의 애플리케이션 사이에서 중개하는 역할

  • 게이트웨이: 다른 프로토콜을 사용하는 둘 이상의 애플리케이션 사이에서 중개하는 역할, 서로 다른 프로토콜을 사용하더라도 서로 간의 트랜잭션을 완료할 수 있도록 프로토콜 변환기처럼 동작

프락시의 효과와 종류

보안 개선 / 성능 향상 / 비용 절약 등 다양한 효과를 얻을 수 있으며 그 예로 아래와 같은 것들이 있다.

  • 어린이 필터: 어린이가 인터넷을 사용할 때 부적절한 사이트를 방문하지 못하도록 막아준다.

  • 문서 접근 제어자: 특정 사용자(권한이 없는)가 특정 문서에 접근할 수 없도록 막아준다.

  • 보안 방화벽: 요청한 트래픽에 대해 필터링을 수행하여 악성 트래픽을 차단한다.

  • 웹 캐시: 자주 사용되는 리소스를 캐시하여 빠르게 응답할 수 있도록 한다.

  • 콘텐츠 라우터: 사용자들에게 제공할 여러 서비스를 구현하는데 사용된다. 예를 들어, 사용자나 콘텐츠 제공자가 더 높은 성능을 위해 돈을 지불하면 더 빠른 서버로 연결해준다.

  • 트랜스코더: 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 변환해준다.

  • 익명화 프락시: HTTP 메시지에서 신원을 식별할 수 있는 특성(IP 주소 / 쿠키 / URI 세션 아이디 / Referer 헤더 등)을 제거한다.

프락시 배치(위치)

프락시는 어떻게 목적에 따라서 어디에든 배치할 수 있으며 어디에든 배치할 수 있다.

  • 출구(Egress) 프락시

    • 로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 사용

    • 내부망 밖의 악의적인 요청을 차단하거나, 내부망의 트래픽을 외부로 전달하기 전에 필터링을 수행

  • 접근(입구) 프락시

    • 클라이언트로부터 모든 요청을 종합적으로 처리하기 위해 사용

    • 사용자들의 다운로드 속도를 개선하거나, 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용해 콘텐츠를 캐싱

  • 대리 프락시

    • 네트워크의 가장 끝에 있는 웹- 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고, 필요한 경우에만 웹 서버에 요청을 전달

    • 웹 서버에 보안 기능을 추가하거나 웹 서버 캐시를 느린 웹 서버 앞에 놓아 성능을 향상시키는 등의 목적으로 사용

  • 네트워크 교환 프락시

    • 캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시하기 위해, 충분한 처리 능력을 갖춘 프락시가 네트워크 사이의 중간에 위치

프락시 계층

메시지를 최종적으로 원 서버에 도착할 때까지 프락시를 거쳐가는 과정을 프락시 계층이라고 한다. 프락시 계층에서 프락시 서버들은 부모와 자식 관계를 가지며, 다음번 인바운드 프락시(서버에 가까운 쪽)를 부모 프락시라고 하며, 이전번 아웃바운드 프락시(클라이언트에 가까운 쪽)를 자식 프락시라고 한다.

클라이언트 -- 자식 프락시 --부모 프락시 -- 원 서버

위와 같이 정적으로 프락시 계층을 구성하는 것이 아니라, 동적으로 프락시 계층을 구성할 수도 있다.

           캐시 프락시
               |
               |
클라이언트 -- 접근 프락시 -- 원 서버
               |
               |
           압축 프락시 -- 원 서버              

프락시의 트래픽 처리 방식

클라이언트는 보통 웹 서버와 직접 대화하는 방식으로 요청 메시지를 보내고 응답 메시지를 받는다. 여기서 HTTP 트래픽이 프락시로 향하는 길을 찾아내는 방법에는 네 가지 방법이 존재한다.

1. 클라이언트 수정

구글 크롬과 같은 브라우저를 포함한 웹 클라이언트들은 수동 혹은 자동 프록시 설정을 지원한다. 만약 클라이언트가 프락시를 사용하도록 설정되어 있다면, 요청을 프락시로 보낸다.

클라이언트 -- 프락시 -- 원 서버

2. 네트워크 수정

클라이언트는 알지도 못하고 간섭도 할 수 없는 상태에서, 네트워크 인프라를 가로채서 웹 트래픽을 프락시로 보내도록 설정할 수 있다.

클라이언트 -- 라우터   원 서버
            |
            |   
           프락시

3. DNS 이름 공간 수정

웹 서버 앞에 위치하는 대리 프락시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용하기 하는데, 때문에 모든 요청은 서버 대신 대리 프락시로 가게 된다.

클라이언트 -- 프락시 - 원 서버

4. 웹 서버 수정

HTTP 리다이렉션 명령(305 코드)을 사용하여 클라이언트가 프락시로 요청을 보내도록 유도할 수 있다.

클라이언트 -- 원 서버 -- 프락시

클라이언트의 프락시 설정

최근 거의 모든 브라우저는 프락시를 사용하도록 설정할 수 있는 기능을 제공한다.

  • 수동 설정: 프락시를 사용하겠다고 명시적으로 설정

  • 브라우저 기본 설정: 브라우저 벤더나 배포자는 브라우저(혹은 다른 웹 클라이언트)를 소비자에게 전달하기 전에 프락시를 미리 설정

  • 프락시 자동 설정(Proxy Auto-Configuration, PAC): 자바스크립트 프락시 자동 설정(PAC)에 대한 URI를 제공하여, 클라이언트는 프락시를 써야 하는지, 어떤 프락시를 써야 하는지를 결정

  • Web Proxy Auto-Discovery Protocol(WPAD): 대부분의 브라우저는 자동설정 파일을 다운받을 수 있는 설정 서버를 자동으로 찾아주는 웹 프락시 자동 발견 프로토콜(WPAD)를 제공한다.

메시지 추적

현재 웹 요청이 클라이언트에서 서버로 향하는 도중 둘 이상의 프락시를 거치는 경우는 흔한 일이다. 때문에 웹 서버는 클라이언트가 보낸 요청이 어떤 프락시를 거쳐서 왔는지 아는 것은 필요한 정보가 되었다.

Via 헤더

요청 메시지와 응답 메시지 모두 지나는 각 중간 노드(프락시나 게이트웨이)의 정보를 나열하여 어떠한 경로를 통해 메시지가 전달되었는지 추적할 수 있도록 해준다.

Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

프락시에서는 요청을 보내기 전에 자신을 가리키는 유일한 문자열을 Via 헤더에 삽입해야 하며 라우팅 루프를 탐지하기 위해 이 문자열이 들어온 요청에 존재하는지 검사해야 한다.

참고자료

Last updated