프락시

프락시란?

• 클라이언트와 서버 사이에 존재
• 클라 <-> 서버 사이의 HTTP 메시지를 정리하는 중개인처럼 동작

웹 중개자

프락시 서버는 클라이언트 입장엥서 트랜잭션을 수행하는 중개인이다. 트랜잭션을 완료하는 것이 클라이언트라는 점은 변하지 않지만, 프락시 서버가 제공하는 좋은 서비스를 이용하게 된다.
클라이언트 입장에서 프락시는 서버이며, 서버 입장에서는 프락시는 클라이언트이다. 즉, 프락시는 서버이면서 동시에 클라이언트이다.

개인 프락시와 공유 프락시

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

공용 프락시

대부분의 프락시는 공용 프락시라고 한다. 공용 프락시가 여러 면에서 이점이 많다. 중앙 집중형 프락시를 관리하는게 더 비용효율이 높다. 또한 캐시 프락시 서버와 같은 몇몇 프락시 애플리케이션은 여러 사용자들의 공통된 요청에서 이득을 취할 수 있다.

개인 프락시

그다지 흔한 형태는 아니지만, 꾸준히 사용되고 있다. 주로 클라이언트 컴퓨터에서 직접 실행되는 형태라고 하는데, 브라우저의 기능을 확장하거나 성능을 개선하거나, 무료 ISP 서비스를 위한 광고를 운영하기 위해 작은 프락시를 사용자 컴퓨터에서 직접 실행한다.

실질적인 예시로 무엇이 있는지는 아직 잘 모르겠다...

프락시 vs 게이트웨이

프락시

• 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결

게이트웨이

• 다른 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결
• 프로토콜이 달라도 서로 트랜잭션을 완료할 수 있도록 프로토콜 변환

실질적으로 프락시와 게이트웨이의 차이점은 모호하다. 브라우저와 서버는 다른 버전의 HTTP를 구현하기 때문에 프락시는 때때로 약간의 프로토콜 변환을 하기도 한다.
또한, 상용 프락시 서버는 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근, 웹 기반 애플리케이션 지원을 위한 게이트웨이 기능을 구현한다.

프락시를 사용하는 이유

프락시는 유용하고 실용적인 것이라면 무엇이든 한다.

• 보안 개선
• 성능 향상
• 비용 절약

또한 모든 HTTP 트래픽을 들여다 보고 건드릴 수 있기 때문에 부가적인 가치를 주는 여러 유용한 웹 서비스 구현을 위해 트래픽을 감시하고 수정할 수 있다.

프락시를 이용한 대표적인 서비스이다.

• 어린이 필터 (유해 콘텐츠 필터)
• 문서 접근 제어자 (사내 파일 보안)
• 보안 방화벽
• 웹 캐시
• 대리 프락시(Surrogate/리버스 프락시)
• 콘텐츠 라우터
  • 인터넷 트래픽 조건과 콘텐츠 종류에 따라 요청을 특정 웹 서버로 유도
  • 사용자에게 비용을 더 받아 사용자의 요청을 더 가까운 복제 캐시로 전달.
  • 비용을 지불하지 않은 사용자의 요청은 멀리 있는 프락시에 보낼 수 있다.
• 트랜스코더
  • 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정
  • 데이터 표현 방식을 자연스럽게 변환하는 것을 트랜스코딩이라고 한다.
• 익명화 프락시(Anonymizer)
  • 신원 식별할 수 있는 특성(IP 주소, From헤더, Referer헤더, 쿠키, URI 세션 ID 등)을 제거
  • 개인정보 보호 및 익명성 보장에 기여

프락시는 어디에 있는가?

프락시 서버 배치

프락시 서버는 어떻게 사용될 것인가에 따라 다르게 배치할 수 있다.
아래는 몇 가지 방법들이다.

출구(Egress) 프락시

프락시를 로컬 네트워크의 출구에 박아 넣을 수 있다.
로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위함

• 회사에서 인터넷 요금 절약 및 인터넷 트래픽 성능 개선을 위해 사용할 수 있다.
• 회사에서 회사 밖의 악의적인 해커들을 막는 방화멱을 제공할 수 있다.
• 학교에서 아이들이 부적절한 콘텐츠를 브라우징하는 것을 막을 수 있다.

접근(입구) 프락시

고객으로부터의 모든 요청을 종합적으로 처리하기 위해 ISP 접근 지점에 위치하기도 한다.
ISP는 사용자들의 다운로드 속도를 개선하고, 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용해 많이 찾는 문서의 사본을 저장한다.

대리 프락시(리버스 프락시)

네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치
웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에 자원 요청
모든 요청을 서버로 바로 가지 않고 이 프락시로 가게 된다.

네트워크 교환 프락시

캐시를 이용해 인터넷 교차로의 혼잡을 완화한다.
트래픽 흐름을 감시하기 위해 충분한 처리 능력을 갖춘 프락시가 네트워크 사이의 인터넷 피어링 교환 지점들에 놓일 수 잇다.

이러한 프락시들은 보통 인터넷 대역폭이 매우 비싼 곳(특히 유럽)에 배치된다. (2002년 기준)

프락시 계층

프락시들은 계층이라고 불리는 연쇄를 구성할 수 있다. 프락시 계층에서 메시지는 최종적으로 원 서버에 도착할 때까지 프락시와 프락시를 거쳐 이동한다.
클라이언트 쪽에 가까운(아웃 바운드) 프락시는 서버 쪽에 가까운(인바운드) 프록시의 자식이 되면서 부모-자식의 관계를 가지게 된다.

하지만 항상 정적인 관계를 가지는 것은 아니다. 프락시는 여러 근거에 의해 메시지를 다양하고 유동적인 프락시 서버와 원 서버들의 집합에게 보여줄 수 있다.

• 앞서 콘텐츠 라우터와 같은 프락시의 예시와 같이 돈을 더 지불한 고객의 요청은 가까운 캐시 프락시로 보내고, 돈을 지불하지 않은 고객의 요청은 그와는 다른 프락시로 보낼 수 있다.
• 요청이 특정 종류의 이미지에 대한 것인 경우, 접근 프락시는 그 요청을 특화된 압축 프락시에게 보내어 프락시가 이미지를 압축하여 보내게 한다.

동적 부모 선택의 몇 가지 예시이다.

부하 균형

지리적 인접성에 근거한 라우팅

프로토콜/타입 라우팅

유료 서비스 가입자를 위한 라우팅

프락시가 트래픽을 처리하는 방법

클라이언트는 보통 웹 서버와 직접 대화하기 때문에 먼저 어떻게 HTTP 트래픽이 프락시로 향하는 길을 찾아내는지 설명할 필요가 있다.
클라이언트 트래픽이 프락시로 가도록 만드는 방법에는 네 가지가 있다.

클라이언트를 수정한다

보통 크롬이나 MS의 브라우저에는 수동/자동으로 프락시를 설정할 수 있다. 만약 클라이언트에서 프락시를 사용하도록 되어있다면 클라이언트는 HTTP 요청을 원 서버가 아닌 프락시로 보낸다.

네트워크를 수정한다

클라이언트 모르게 네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 조정하는 몇 가지 기법이 있다.
이 기법은 보통 HTTP 트래픽을 지켜보고 가로채어 보낼 수 있는 스위칭 장치와 라우팅 장치를 필요로 한다. 이러한 것들을 인터셉트 프락시라고 부른다.

DNS를 수정한다

웹 서버 앞에 위치하는 서버의 대리 프락시는 웹 서버의 IP주소와 이름을 자신이 사용한다. 그래서 웹 서버로의 요청은 서버로 직접 가는 것이 아니라 대리 프락시로 가게 된다. 이는 DNS 이름 테이블을 수동으로 편집하거나 사용할 프락시나 서버를 계산해주는 특별한 동적 DNS 서버를 이용해 조정될 수 있다.

웹 서버를 수정한다

몇몇 웹 서버는 HTTP 리다이렉션 명령(305)을 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트 하도록 설정할 수 있다.

클라이언트 프락시 설정

수동 설정

• 브라우저 설정에서 프락시의 호스트와 포트를 지정한다

브라우저 기본 설정

프락시 자동 설정(Proxy auto-configuration, PAC)

• 수동 설정은 유연성이 부족하다.PAC는 보다 동적인 해결책인데, 프락시 설정을 자바스크립트 프로그램을 통해 자동으로 설정한다.
• 자바스크립트 PAC 파일의 URI를 브라우저에 설정하면 매 접근마다 적절한 로직을 통해 자동으로 프락시를 설정한다.
• 프락시 사용 필요 여부, 어떤 프락시를 써야하는지 판단할 수 있다.

WPAD

• 웹 프락시 자동 발견 프로토콜
• 브라우저에 알맞은 PAC파일을 자동으로 찾아주는 알고리즘
• WPAD 프로토콜이 구현된 클라이언트가 하는 일
  • PAC URI를 찾기 위해 WPAD를 사용한다
  • 주어진 URI에서 PAC파일을 가져온다.
  • 프락시 서버를알아내기 위해 PAC파일을 실행한다
  • 알아낸 프락시 서버를 이용해서 요청을 처리한다
• WPAD 프로토콜을 이용해 올바른 PAC 파일을 알아내기 위해 여러 리소스 발견 기법을 이용한다. 성공할 때 까지 다음의 순서대로 시도한다.
  • 동적 호스트 발견 규약 (DHCP)
  • 서비스 위치 규약 (ISP)
  • DNS 잘 알려진 호스트 명
  • DNS SRV 레코드
  • DNS TXT 레코드 안의 서비스 URI

프락시 요청의 미묘한 특징들

프락시 서버의 미묘하고 오해하기 쉬운 측면들에 대해서 설명한다.

• 프락시 요청의 URI는 서버 요청과 어떻게 다른가
• 인터셉트 프락시와 리버스 프락시는 어떻게 서버 호스트 정보를 알아내기 어렵게 만드는가
• URI 수정에 대한 규칙
• 프락시는 브라우저의 똑똑한 URI 자동완성이나 호스트 명 확장 기능에 어떻게 영향을 주는가