웹 프록시 서버는 일종의 중개자이다. 프록시는 클라이언트와 서버 사이에 위치하여 그 사이의 HTTP메시지를 정리한다.

중개자

클라이언트 입장에서 웹 프록시 서버는 트랜잭션을 수행하는 중개인이다. 웹 프록시 서버가 없다면 클라이언트는 웹 서버와 직접 이야기 해야 하지만, 프록시 서버가 있다면, 서버와 상호작용하는 프록시와 상호작용하게 된다.

HTTP 프록시 서버는 웹 서버이자 웹 클라이언트이기도 하다, 프록시는 서버 입장에서는 프록시와 상호작용하게 되기 때문에 웹 클라이언트 처럼 동작해야 한다.

프록시는 클라이언트가 독점적으로 사용할 수도 있고, 여러 클라이언트가 공유할 수도 있다.

캐시 프록시 서버와 같은 몇몇 프록시 서버는 여러 사용자들의 공통된 요청에서 이득을 취할 수 있기 때문에, 이용하는 이용자가 많을수록 유리하다.

프록시 vs 게이트웨이

프록시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다. 게이트 웨이는 서로 다른 프로토콜로 말하더라도, 서로 간의 트랜잭션을 완료 할 수 있도록 도와주는 프로토콜 변환기처럼 동작한다.

하지만 실질적으로 프록시와 게이트웨이의 차이점은 모호한데, 브라우저와 서버는 다른 버전의 HTTP를 구현하기 때문에 프록시가 때때로 프로토콜 변환을 하기도 한다.

프록시를 사용하는 이유

프록시는 모든 HTTP를 감시하고 수정할 수 있기 때문에 보안을 개선하고, 성능을 높여주며, 비용을 절약하기 위해 사용한다.

접근 제어자

프록시는 웹 서버들과 웹 리소스에 대한 접근 제어 전략을 구현하고 추적하기 위해 사용될 수 있다.

보안 방화벽

프록시 서버는 조직 안에 들어오거나 나가는 응용레벨 프로토콜의 흐름을 네트워크 한 지점에서 통제한다. 또한 바이러스를 제거하는 웹이나 이메일 프록시가 사용할 수 있는 트래픽을 세심히 살펴볼 수 있는 훅을 제공한다.

웹 캐시

프록시 캐시는 인기 있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공하여, 커뮤니케이션을 줄인다.

대리 프록시(surrogate)

어떤 프록시들은 웹 서버인것처럼 위장한다. 리버스 프록시라고도 불리며 이 프록시들은 웹 서버 요청을 받지만, 웹 서버와는 달리 컨텐츠의 위치를 찾기 위해 다른 서버와 커뮤니케이션을 한다.

대리 프록시는 공용 컨텐츠에 대한 느린 웹 서버의 성능을 개선 하기위해 사용될수 있으며, 서버 가속기라고도 불리고 OTT의 분산 네트워크를 구현하기 위해 사용 될 수 있다.

트랜스코더

프록시 서버는 컨텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있다.

데이터의 표현 방식을 자연스럽게 변환하는 것을 트랜스코딩이라고 한다.

트랜스코딩 프록시는 크기를 줄이기 위해 gif이미지를 jpg이미지로 변환하거나, 이미지의 크기를 줄이거나, 색 강도를 줄일 수도 있다. 텍스트나 문서를 압축하거나, 문서를 외국어 문서로 변환하는것도 가능하다(국제화)

익명화 프록시

HTTP메시지에서 IP주소, From헤더, Referer헤더, 쿠키와 같은 특성들을 제거함으로써 개인정보 보호와 익명성을 보장하는 프록시를 익명화 프록시라고 한다.

익명화 프록시는 개인정보를 보호하기 위해 사용자의 메시지를 여러 방식으로 변경한다.

• User-Agent 헤더에서 사용자의 컴퓨터와 OS의 종류를 제거한다.
• 사용자의 이메일 주소를 보호하기 위해 From헤더를 제거한다.
• 어떤 사이트를 거쳐서 방문했는지 알기 어렵게 하기 위해 Referer헤더를 제거한다.
• 프로필과 신원 정보를 없애기 위해 쿠키를 제거한다.

Where?

출구 프록시

로컬 네트워크와 인터넷 사이를 오가는 트래픽을 제어하기 위해 프록시를 로컬 네트워크 출구에 넣을 수 있다.

입구 프록시

고객츠로부터 모든 요청을 종합적으로 처리하기 위해 ISP접근지점에 위치시킨다. 사용자들의 다운로드 속도를 개선하고 대역폭 비용을 줄이기 위해 캐시 프록시를 사용한다.

대리 프록시

리버스 프록시라고도 불리는 대시프록시는 웹서버 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때 웹 서버에게 자원을 요청할 수 있다. 웹 서버에 보안 기능을 추가하거나 다른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로서 성능을 개선 할 수 있다.

네트워크 교환 프록시

캐시를 이용해 네트워크 교차로의 혼잡을 완화하고 트래픽 흐름을 감시하는 네트워크 교환 프록시는 네트워크와 네트워크 사이 네트워크 피어링 교환 지점들에 놓일 수 있다.

프록시 계층

프록시들은 프록시 계층이라고 불리는 연쇄를 구성할 수 있다. 메시지는 최종적으로 서버에 도착할 때 까지 프록시와 프록시를 거쳐 이동한다.

프록시 계층에서 프록시 서버들은 부모 자식 관계를 갖는데 서버에 가까운 쪽인 인바운드 프록시를 부모라고 부르고 클라이언트에 가까운 쪽인 아웃바운드 프록시를 자식이라고 한다.

프록시 계층 컨텐츠 라우팅

프록시 계층은 정적으로 고정되어 있는 것이 아니고 여러가지 판단 근거에 의해 메시지를 다양하고 유동적인 프록시 서버와 원 서버들의 집합에게 보낼 수 있다.

동적 부모 선택

• 로드 밸런싱 자식 프록시는 부하를 분산하기 위해 부모들의 작업량 수준에 근거하여 부모 프록시를 고른다.
  
• 지리적 인접성에 근거한 라우팅 자식 프록시는 원 서버의 지역을 담당하는 부모를 선택할 수 있다.
  
• 프로토콜/타입 라우팅 어떤 자식 프록시는 URI에 근거하여 다른 부모나 원 서버로 라우팅 할 수 있다.
  

어떻게 프록시가 트래픽을 처리할까?

클라이언트 트래픽이 프록시로 가는 방법에는 네가지 방법이 있다.

• 클라이언트를 수정한다.
  어떤 웹 클라이언트들은 수동/자동 프록시 설정을 지원하는데 프록시를 사용하도록 설정되어 있다면, 클라이언트는 HTTP요청을 의도적으로 원 서버가 아닌 프록시로 보낸다.
  
• 네트워크를 수정한다 클라이언트는 알지 못하는 상태에서 네트워크 인프라를 가로채서 프록시로 가도록 조정하는 기법을 사용한다. 스위칭 장치와 라우팅 장치를 필요로 하는데, 이 기법을 인터셉트 프록시, 투명 프록시라고 한다.
  

• DNS 이름공간을 수정한다
  리버스 프록시는 DNS 이름공간을 편집하거나 동적 DNS를 사용하여 웹 서버의 이름과 IP주로를 자신이 직접 사용하고 모든 요청을 받는다.
  
• 웹 서버를 수정한다 어떤 웹 서버는 HTTP 리디렉션 명령(305)을 사용하여 클라이언트에게 반환하여 클라이언트의 요청을 프록시로 리디렉트할도록 설정할 수 있다.
  

프록시 요청

프록시 URI는 서버 URI와 다르다

클라이언트가 프록시 대신 서버로 요청을 보낼때 요청의 URI가 달라진다.

클라이언트가 웹 서버로 요청을 보낼때는 스킴, 호스트명, 포트번호가 없는 부분 URI를 사용한다.

GET /index.html HTTP/1.0

그러나 클라이언트가 프록시로 요청을 보낼 때는 완전한 URI를 사용해야한다

GET http://www.marys-antiques.com/index.html HTTP/1.0

원래 HTTP설계에서는 클라이언트는 단일 원 서버와 대화한다. 그렇기 때문에 불필요한 정보 발송을 피하기 위해 스킴과 호스트, 포트번호가 없는 부분 URI만 보내지만, 프록시는 목적지 서버와 커넥션을 맺어야 하기 때문에 서버의 이름을 알 필요과 있고, 프록시 기반 게이트웨이는 스킴과 연결하기 위해 URI의 스킴을 알 필요가 있다.

그렇기 때문에 서버로는 부분 URI를 보내고 프록시로는 완전한 URI를 보내야한다.

가상호스팅 관련

가상 호스팅중인 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유한다. 요청 하나가 부분 URI로 오게 되면 웹 서버는 그 요청이 접근하고자 하는 웹사이트의 호스트 명을 알 필요가 있다.

다만 이때는 완전한 URI를 요구하는 것이 아니라 호스트와 포트에 대한 정보가 담겨 있는 Host헤더를 요구한다.

인터셉트 프록시는 부분 URI를 받는다.

투명 프록시라고도 불리는 인터셉트 프록시는 클라이언트는 인지하지 못하고 요청을 보내게 되므로 부분 URI를 보낼 수 있다.

프록시는 프록시 요청과 서버 요청을 모두 다룰 수 있다.

트래픽이 프록시 서버로 리다이렉트 될 수 있는 여러가지 방법이 존재하기 때문에 다목적 프록시 서버는 요청 미시지의 완전한 URI, 부분 URI를 둘다 지원 해야한다.프록시는 명시적인 프록시 요청의 경우에는 완전한 URI를 사용하고 아니면 부분 URI를 사용해야 하며, 웹 서버 요청의 경우에는 가상 Host 헤더를 사용해야 한다.

• 완전 URI가 있다면 그것을 사용한다.
• 부분 URI가 있고 Host 헤더가 있다면, Host헤더를 사용해 원 서버의 이름과 포트 번호를 알아낸다.
• 부분 URI가 주어졌으나 Host헤더가 없다면, 다음의 방법으로 원 서버를 알아내야 한다.
  • 대리 프록시라면, 프록시에 원 서버의 주소와 포트번호가 설정되있다.
  • 이전에 어떤 인터셉터 프록시가 가로챘던 트래픽을 받았고, 그 인터셉터 프록시가 원 IP주소와 포트번호를 사용할 수 있도록 해두었다면, 그 IP주소와 포트 번호를 사용할 수 있다.
  • 위의 경우들이 아니라면 충분한 정보를 갖고 있지 못한 것이므로 반드시 에러메시지를 반환 해야 한다.

메시지 추적

웹 요청이 둘 이상의 프록시를 지가는 것은 드문일이 아니고 오늘날에는 많은 기업들이 캐시 프록시 서버를 사용한다. 때문에 서로 다른 스위치와 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것 못지않게 프록시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아 낼 수 있어야 한다.

Via헤더

Via헤더는 메시지가 지나는 중 간 노드들의 정보를 나열한다. Via헤더는 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 모내고 읃답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다.

Via와 게이트웨이

어떤 프록시는 비 HTTP 프로토콜을 사용할 수 있는 게이트웨이 기능을 제공한다.Via헤더는 프로토콜 변환또한 기록하므로 HTTP 애플리케이션은 프록시 연쇄에서 프로토콜 능력과 변환이 있었는지 알아챌 수 있다.

TRACE 메서드

TRACE메서드는 요청 메시지가 프록시 체인을 따라가면서 어떤 프록시를 지나고 각 프록시가 요청 메시지를 수정하는지 추적 할 수 있다.

TRACE요청이 서버에 도착했을때, 서버는 요청 메시지를 HTTP 응답 메시지의 본문에 포함시켜 송신자에게 그대로 돌려보낸다.

MAX-Forwards

TRACE메시지는 목적지 서버로 이동하면서 프록시들이 몇개나 있든 신경쓰지 않는다. 단, Max-Forwards헤더를 사용하면 앞으로 몇번 더 다음 hop으로 전달 될 수 있는지 말해주는 말해준다. Max-Fowards값이 0보다 크다면 전달될 메시지의 Max-Forwards는 1감소된 값으로 갱신되어야 하며, 만약 값이 0이라면 수신자는 자신이 원 서버가 아니라 할지라도 TRACE 메시지를 더 이상 전달하지 말고 반드시 클라이언트에게 돌려줘야 한다.