참고 도서 : HTTP 완벽 가이드

Proxy

학습 목표

HTTP 프락시와 웹 게이트웨이 비교
프락시가 실제 네트워크에 어떻게 배치되어 있는지
트래픽이 어떻게 프락시 서버로 가게 되는지
브라우저에서 프락시를 사용하려면 어떻게 설정해야하는지
HTTP 프락시 요청이 서버 요청과 차이가 무엇인지, 프락시가 어떻게 브라우저의 동작을 바꾸는지
프락시 서버들을 통과하는 메시지의 경로 & via 헤더와 TRACE 메서드를 이용해 기록하는 방법
프락시에 기반한 HTTP 접근 제어
프락시가 클라이언트와 서버 사이에서 각각의 다른 기능과 버전 들을 지원하면서 상호작용할 수 있는 방법

웹 중개자

웹 프락시 서버는 클라이언트의 입장에서 트랜잭션을 수행하는 중개인이다. 웹 프락시가 없으면, 클라이언트는 HTTP 서버와 직접 이야기한다.

웹 프락시가 있으면 클라이언트는 HTTP 서버와 이야기하는 대신 자신의 입장에서 서버와 대화해주는 프락시와 이야기한다. 트랜잭션은 클라이언트가 완료한다.

HTTP 프락시 서버는 웹 서버이기도 하고 웹 클라이언트이기도 하다. 프락시는 HTTP 클라이언트의 요청을 받게 되어 웹 서버처럼 요청과 커넥션을 적절히 다루고 응답을 돌려주는 일을 한다. 또한 프락시는 서버에게 요청을 보내기도하여 이는 HTTP 클라이언트처럼 동작해야한다.

개인 프락시 & 공유 프락시

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

공용 프락시

대부분의 프락시는 공용 프락시이다. 중앙 집중형 프락시를 관리하는게 비용효율이 높다. 캐시 프락시 서버와 같은 프락시 애플리케이션은 프락시를 이용하는 사용자가 많을 수록 유리하다. 여러 사용자들의 공통된 요청에서 더욱 효율이 높기 때문이다.

개인 프락시

개인 프락시는 클라이언트 컴퓨터에서 직접 실행되는 형태로 꾸준히 사용되고 있다.

프락시 vs 게이트웨이

프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하지만, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다.

게이트웨이는 클라이언트와 서버가 서로 다른 프로토콜로 요청과 응답을 주고 받아도 서로간의 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 동작한다.

하지만 실질적으로 프락시와 게이트웨이의 차이점은 모호하다. 프락시는 어떤 기능엔 게이트웨이처럼 포로토콜 변환을 하기도 한다.

프락시를 왜 쓰는가

프락시 서버는 모든 HTTP 트래픽을 감시하고 수정할 수 있다.

어린이들에게 교육 사이트를 제공하면서 동시에 성인 콘텐츠를 차단하려는 목적으로 필터링 프락시를 사용할 수 있다.
문서 접근 제어자 : 프락시 서버는 많은 웹 서버들과 웹 리소스에 대해 클라이언트에 따라서 접근 제어 및 감사 추적을 위해 사용될 수 있다. -> 대기업 환경 등의 분산된 관료 조직
보안 방화벽 : 보안을 강화하기 위해 프락시 서버 사용. 프로토콜의 흐름을 한 지점에서 통제한다. 트래픽도 세심하게 살펴볼 수 있다.
웹 캐시 : 프락시 캐시는 인기 있는 문서의 로컬 사본을 관리하고, 해당 문서에 대한 요청이 오면 빠르게 제공하므로 속도를 높여준다.
대리 프락시 : 진짜 웹 서버 요청을 받지만, 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 의사소통을 한다. 느린 웹 서버의 성능을 개선하기 위해 사용된다. 콘텐츠 라우팅 기능과 결합되어 분산 네트워크를 만들기 위해 사용될 수 있다.
콘텐츠 라우터 : 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작할 수 있다.
트랜스코더 : 데이터 표현 방식을 자연스럽게 변환하는 프락시 서버를 말한다. 이미지 크기를 줄이거나 텍스트 파일을 압축시키거나 문서를 외국어 문서로 변환시키는 등이 가능하다.
익명화 프락시 : HTTP 메시지에서 신원을 식별할 수 있는 특성들(IP주소, From 헤더, Referer 헤더, 쿠키, URI 세션 아이디)을 적극적으로 제거함으로써 개인 정보 보호와 익명성 보장에 기여한다.

프락시는 어디에 있는가?

어떻게 프락시가 네트워크에 배치되는지
어떻게 프락시의 연쇄가 계층을 이루는지
어떻게 트래픽이 올바르게 프락시를 찾아가는지

프락시 서버 배치

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

출구 프락시 : 로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프락시를 로컬 네트워크의 출구에 놓을 수 있다.
접근 프락시 : 클라이언트로부터 모든 요청을 처리하기 위해 프락시는 ISP 접근 지점에 위치하기도 한다.
대리 프락시 : 리버스 프락시라고도 하는 대리 프락시는 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청할 수 있다. 또한 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버 앞에 놓아 성능을 개선시킬 수도 있다. 리버스 프락시는 웹 서버의 이름과 IP주소로 스스로를 가장하기 때문에 모든 요청이 이 프락시로 가게 된다.
네트워크 교환 프락시 : 캐시를 이용해 인터넷 교차 혼잡을 완화하기 위해(트래픽 흐름 감지) 프락시가 네트워크 사이의 인터넷 피어링 교환 지점들에 놓일 수 있다.

프락시 계층

프락시들은 프락시 계층이라고 불리는 연쇄를 구성할 수 있다. 프락시 계층에서 프락시 서버들은 부모와 자식의 관계를 갖는다. 서버에 가까운 쪽(인바운드 프락시)을 부모라고 부르고 아웃바운드 프락시인 클라이언트에 가까운 쪽을 자식이라고 부른다.

프락시 계층은 정적이지만 어떤 경우에는 유동적으로 요청이 처리될 수 있다.

어떻게 프락시가 트래픽을 처리하는가

클라이언트는 보통 웹 서버와 직접 대화하기 때문에, 어떻게 HTTP 트래픽이 프락시로 향하는 길을 찾아내는지 알아야한다. 이는 네 가지 방법이 있다.

클라이언트 수정 : 수동 혹은 자동 프락시 설정 지원 -> 클라이언트가 프락시 사용시 HTTP 요청을 프락시로 보내게 한다.
네트워크 수정 : 클라이언트는 모르는 상태에서 네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 조정한다. 이를 인터셉트 프락시라고 한다.
DNS 이름공간 수정 : 웹 서버 앞에 위치하는 리버스 프락시는 웹 서버의 이름과 IP주소를 자신이 직접 사용한다. 이는 DNS 이름 테이블을 수동으로 편집하거나 사용할 프락시나 서버를 계산해주는 특별한 동적 DNS 서버를 이용해서 조정될 수 있다.
웹 서버 수정 : 웹 서버는 HTTP 리다이렉션 명령을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트하도록 설정할 수 있다.

클라이언트 프락시 설정

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

수동 프락시 설정은 단순하지만 반면에 유연하지 못하다. 이는 또한 큰 조직에서는 관리 문제를 야기한다. 프락시 자동 설정 파일은 프락시 설정에 대한 보다 동적인 해결책이다. 이는 프락시 설정을 그때그때 상황에 맞게 계산해주는 작은 자바스크립트 프로그램이다. 문서에 접근할 때마다 자바스크립트 함수가 적절한 프락시 서버를 선택한다.

PAC 파일을 사용하려면 URI 브라우저에 설정해야한다. 일반적으로 .pac확장자를 가지며 MIME 타입은 application/x-ns-proxy-autoconfig이다.

WPAD 프락시 발견 (웹 프락시 자동 발견 프로토콜)

WPAD는 여러 발견 메커니즘들의 상승 전략을 이용해 브라우저에게 알맞은 PAC파일을 자동으로 찾아주는 알고리즘이다. WPAD 프로토콜이 구현된 클라이언트가 하게 될 일은 다음과 같다.

PAC URI를 찾기 위해 WPAD를 사용한다.
주어진 URI에서 PAC파일을 가져온다.
프락시 서버를 알아내기 위해 PAC 파일을 실행한다.
알아낸 프락시 서버를 이용해서 요청을 처리한다.

WPAD는 올바른 PAC파일을 알아내기 위해 일련의 리소스 발견 기법을 사용한다.

동적 호스트 발견 규약 (DHCP)
서비스 위치 규약(SLP)
DNS 잘 알려진 호스트 명
DNS SRV 레코드
DNS TXT 레코드 안의 서비스 URI

프락시 요청 특징

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

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

웹 서버와 웹 프락시 메시지의 문법은 서로 같지만, 클라이언트가 프락시 대신 서버로 요청을 보내면 요청의 URI가 달라진다.

클라이언트가 웹 서버로 요청을 보낼 때, 요청줄은 스키마, 호스트, 포트번호가 없는 부분 URI를 가진다.

GET /index.html HTTP/1.0
User-Agent: SuperBrowser v1.3

클라이언트가 프락시로 요청을 보낼 때, 요청줄은 완전한 URI를 갖는다.

GET http://www.example.com/index.html HTTP/1.0
User-Agent: SuperBrowser v1.3

왜 이럴까? 원래 HTTP 설계에서 클라이언트는 단일 서버와 직접 대화했다. 가상 호스팅이나 프락시에 대한 대비도 없었다. 단일 서버는 자신의 호스트 명과 포트번호를 알고 있으므로, 클라이언트는 불필요한 정보 발송을 피하기 위해 스키마와 호스트 부분이 없는 URI 부분만 보냈다.

이는 프락시가 부상하면서 문제가 되었다. 프락시는 목적지 서버와 커넥션을 맺어야하므로, 그 서버의 이름을 알아야했다. 그리고 프락시 기반 게이트웨이는 FTP 리소스나 그 외의 스키마와 연결하기 위해 URI 스키마를 알아야했다. HTTP/1.0은 프락시 요청의 경우 완전한 URI를 요구하는 것으로 해결했지만, 서버 요청의 부분 URI는 여전히 남아있다.

클라이언트가 프락시를 사용하지 않도록 설정되어 있다면, 부분 URI를 보낸다.
클라이언트가 프락시를 사용하도록 설정되어 있다면, 완전한 URI를 보낸다.

가상 호스팅에서 일어나는 문제

프락시의 스키마/호스트/포트번호 누락 문제는 가상으로 호스팅되는 웹 서버가 직면한 것과 같은 문제이다. 가상으로 호스팅 되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유한다.

명시적인 프락시는 요청 메시지가 완전한 URI를 갖도록 함으로써 이 문제를 해결했다.
가상으로 호스팅 되는 웹 서버는 호스트와 포트에 대한 정보가 담겨있는 Host 헤더를 요구한다.

메시지 추적

프락시가 점점 흔해지면서, 서로 다른 스위치와 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것 못지 않게 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다.

Via 헤더

Via 헤더 필드는 메시지가 지나는 중간 노드(프락시 & 게이트웨이)의 정보를 나열한다. 메시지가 또 다른 노드를 지날 때마다 중간 노드는 Via 목록의 끝에 추가되어야 한다.

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

위의 Via 헤더 메시지는 두 개의 프락시를 지나갔음을 뜻한다.

Via와 게이트웨이

몇몇 프락시는 서버에게 비 HTTP 프로토콜을 사용할 수 있는 게이트웨이 기능을 제공한다.

아래는 클라이언트가 프락시로 보낸 HTTP 요청 메시지이다.

GET ftp://http-guide.com/pub/welcome.txt HTTP/1.0

아래는 게이트웨이(프락시)가 요청을 받아 FTP서버와 FTP프로토콜을 이용해 원하는 객체를 받아오고, 응답한 메시지이다.

HTTP/1.0 200 OK
Date: Sun, 11 Nov 2001 21:10:59 GMT
Via: FTP/1.0 proxy.irenes-isp.net (Traffic-Server/5.0.1-17882 [cMsf])
Last-modified: Sun, 11 Nov 2001 21:05:24 GMT
Content-type: text/plain

Hi there. This is an FTP Server

TRACE 메서드

프락시 서버는 메시지가 전달될때 메시지를 바꿀 수 있다. 헤더가 추가, 변경, 삭제될 수 있고, 본문이 다른 형식으로 변환될 수 있따. 프락시가 점점 복잡해지고 많은 벤더가 프락시 제품을 배치하면서, 상호운용성 문제가 증가한다.

프락시 네트워크를 쉽게 진단하기 위해, 우리는 HTTP 프락시 네트워크를 통해 홉에서 홉으로 전달될 때마다 메시지의 내용이 어떻게 변하는지 관찰해야한다.

HTTP/1.1의 TRACE 메서드는 요청 메시지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고 어떻게 각 프락시가 요청 메시지를 수정하는지 관찰/추적할 수 있도록 해준다. TRACE는 프락시 흐름을 디버깅하는데 매우 유용하다.

프락시 인증

프락지는 접근 제어 장치로도 제공될 수 있다. HTTP는 사용자가 유효한 접근 권한 자격을 프락시에 제출하지 않는 한 콘텐츠에 대한 요청을 차단하는 프락시 인증이라는 메커니즘을 정의하고 있다.

제한된 콘텐츠에 대한 요청이 프락시 서버에 도착했을 떄, 프락시 서버는 접근 자격을 요구하는 407 Proxy Authorization Required 상태 코드를 반환한다.
클라이언트는 이럴 받으면, 요구되는 자격을 수집한다.
자격을 획득하면 클라이언트는 요구되는 자격을 Proxy-Authorization 헤더 필드에 답아서 요청을 다시 보낸다.
자격이 유효하면, 프락시는 원 요청을 연쇄를 따라 통과시킨다.

프락시 상호운용성

OPTIONS 어떤 기능을 지원하는지 알아보기

HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지 클라이언트가 알아볼 수 있게 해준다.

OPTIONS * HTTP/1.1

위 요청은 서버 전체의 능력에 대해 묻는 것이다.

Allow 헤더

Allow 헤더는 새 리소스가 지원했으면 하는 메서드를 추천하기 위해 요청 헤더로 사용될 수 있다.