프락시

6. 프락시

웹 프락시 서버는 중개자

프락시는 클라이언트와 서버 사이에 위치하여 그들 사이의 HTTP 메시지를 정리하는 중개인

6.1 웹 중개자

웹 프락시 서버는 클라이언트의 입장에서 트랜잭션을 수행하는 중개인

HTTP 프락시 서버는 웹 서버이기도 하고 웹 클라이언트이기도 함

프락시는 HTTP 클라이언트의 요청을 받게 되므로, 반드시 웹 서버처럼 요청과 커넥견을 적절히 다루고 응답을 돌려줘야 함

동시에 프락시는 요청을 서버로 보내기도 하므로, HTTTP 클라이언트처럼 동작해야 한다

6.1.1 개인 프락시와 공유 프락시

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

공용 프락시

대부분의 프락시는 공용이며 공유된 프락시

중앙 집중형 프락시를 관리하는 게 더 비용효울이 높고 쉽다.

개인 프락시

거의 X

6.1.2 프락시 대 게이트웨이

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

게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결

게이트웨이는 클라이언트와 서버가 서로 다른 프로토콜을 말하더라고 서로 간의 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 작동

실질적으로 프락시와 게이트웨이의 차이점은 모호함

6.2 왜 프락시를 사용하는가?

프락시 서버는 실용적이고 유용한 것이라면 무슨 일이든 한다.(보안 개선, 성능 향상, 비용 절약)

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

어린이 필터

부적절한 사이트 접근 제한

문서 접근 제어자

접근 제어 설정 가능

보안 방화벽

조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네크워크의 한 지점에서 통제

또한, 바이러스를 제거하는 웹이나 이메일 프락시가 사용할 수 있는, 트래픽을 세심히 살펴볼 수 있는 후크(hook) 제공

웹 캐시

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

대리 프락시

진짜 웹 서버 요청을 받지만 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션 시작

대리 프락시는 공용 콘텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용 가능(서버 가속기)

대리 프락시는 또한 콘텐츠 라우팅 기능과 결합되어 주문형 복제 콘텐츠의 분산 네트워크를 만들기 위해 사용 가능

콘텐츠 라우터

프락시 서버는 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작 가능

콘텐츠 라우터는 또한 사용자들에게 제공할 여러 서비스를 구현하는데 사용 가능

트랜스코더

프락시 서버는 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷 수정 가능

데이터의 표현 방식을 자연스럽게 변환하는 것 -> 트랜스코딩

ex. 이미지 변환, 문서 번역 등

익명화 프락시(Annonymizer)

HTTP 메시지에서 신원을 식별할 수 있는 특성들을 제가하여 개인 정보 보호와 익명성 보장에 기여함

6.3 프락시는 어디에 있는가?

6.3.1 프락시 서버 배치

출구(Egress) 프락시

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

ex. 필터링, 트래픽 제어, 방화벽

접근(입구) 프락시

고객으로부터의 모든 요청을 종합적으로 처리하기 위해 프락시는 ISP 접근 지점에 위치하기도 함

다운로드 속도 개선, 비용 줄이기 위한 캐시 프락시

대리 프락시

네트워키의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원 요청 가능

웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로써 성능 개선 가능

네트워크 교환 프락시

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

6.3.2 프락시 계층

프락시들은 프락시 계층이라고 불리는 연쇄를 구성할 수 있다.

프락시 계층에서 프락시 서버들은 부모와 자식의 관계를 갖는다

다음번 인바운드 프락시(서버에 가까운 쪽)를 부모라고 부르고 다음번 아웃바운드 프락시(클라이언트 가까운 쪽)는 자식이라고 부른다.

프락시 계층 콘텐츠 라우팅

프락시 서버는 여러 가지 판단 근거에 의해 메시지를 다양하고 유동적인 프락시 서버와 우너 서버들의 집합에게 보낼 수 있다.

부하 균형

자식 프락시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거하여 부모 프락시를 고른다

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

자식 프락시는 원 서버의 지역을 담당하는 부모를 선택할 수도 있다.

프로토콜/타입 라우팅

어떤 자식 프락시는 URL에 근거하여 다른 부모나 원 서버로 라우팅할 수 있다.

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

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

클라이언트를 수정

대부분의 브라우저를 포함한 많은 웹 클라이언트들은 수동 혹은 자동 프락시 설정을 지원

만약 클라이언트가 프락시를 사용하도록 설정되어 있다면, 클라이언트는 HTTP 요청을 바로 그리고 의도적으로 원 서버가 아닌 프락시로 보낸다

네트워크를 수정

네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 저장 가능 -> 인터셉트 프락시

DNS 이름공간 수정

웹 서버 앞에 위치하는 프락시 서버인 대리 프락시는 웹 서버의 이름과 IP를 자신이 직접 사용

웹 서버 수정

몇몇 웹 서버는 HTTP 리다이렉션 명령을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트하도록 설정 가능

6.4 클라이언트 프락시 설정

수동 설정

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

브라우저 기본 설정

브라우저를 소비자에게 전달하기 전에 프락시를 미리 설정 가능

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

자바스크립트 프락시 자동 설정(PAC) 파일에 대한 URI를 제공 가능

WPAD 프락시 발견

대부분의 브라우저는 자동설정 파일을 다운받을 수 있는 ‘설정 서버’를 자동으로 찾아주는, 웹 프락시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol, WPAD)

6.4.1 클라이언트 프락시 설정: 수동

많은 웹 클라이언트가 프락시를 수동으로 설정할 수 있도록 하고 있다.

6.4.2 클라이언트 프락시 설정: PAC 파일

수동 프락시 설정은 단순하지만 반면에 유연하지 못하다

프락시 자동 설정 파일은 프락시 설정에 대한 보다 동적인 해결책

프락시 실정을 그떄그때 상황에 맞게 계산해주는 작은 자바스크립트 프로그램

PAC 파일을 사용하려면, 자바스크립트 PAC 파일의 URI를 브라우저에 설정해야 한다

6.4.3 클라이언트 프락시 설정:WPAD

WPAD는 여러 발견 메커니즘들의 상승 전략을 이용해 브라우저에게 알맞은 PAC 파일을 자동으로 찾아주는 알고리즘

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

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

6.5.1 프락시 URL는 서버 URL와 다르다

클라이언트가 프락시 대신 서버로 요청을 보내면 요청의 URL가 달라짐

프락시는 목적지 서버와 커넥션을 맺여야 하기 때문에, 서버의 이름을 알 필요가 있음

서버로는 부분 URI, 프락시로는 완전한 URI를 보냄

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

프락시의 ‘스킴/호스트/포트번호 누락’ 문제는 가상으로 호스팅 되는 웹 서버가 직면한 것과 같은 문제

가상으로 호스팅 되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유

이 문제들은 비슷함에도 불구하고, 다른 방법으로 해결됨

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

6.5.3 인터셉트 프락시는 부분 URI를 받는다

대리 프락시나 인터셉트 프락시에너는 완전한 URI를 보내지 않음

6.5.4 프락시는 프락시 요청과 서버 요청을 모두 다룰 수 있다

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

6.5.5 전송 중 URL 변경

프락시 서버는 요청 URI의 변경에 매우 신경 써야 함 -> 문제를 일으킬 수 있음

6.5.6 URI 클라이언트 자동확장과 호스트 명 분석(Hostname Resolution)

브라우저는 프락시의 존재 여부에 따라 요청 URI를 다르게 분석

6.5.7 프락시 없는 URI 분석(URI Resolution)

브라우저는 유효한 호스트 명이 발견될 때까지 다양한 호스트 명의 가능성들을 검색

6.5.8 명시적인 프락시를 사용할 때의 URI 분석

몇몇 프락시는 브라우저의 편리한 서비시를 할 수 있다면 최대한 흉내 내려고 함

6.5.9 인터셉트 프락시를 이용한 URI 분석

6.6 메시지 추적

6.6.1 Via 헤더

Via 헤더 필드는 메시지가 지나는 각 중간 노드의 정보를 나열

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

Via 문법

Via 헤더 필드는 쉼표로 구분된 경유지의 목록

각 경유지는 개별 프락시 서버나 게이트웨이 홉을 나타내며 그들 중간 노드의 프로토콜과 주소에 대한 정보를 담고 있다.

• 프로토콜 이름
• 프로토콜 버전
• 노드 이름
• 노드 코멘트

Via 요청과 응답 경로

요청 메시지와 응답 메시지 모두 프락시를 지나므로 둘 모두 Via 헤더를 가짐

Via와 게이트웨이

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

Via 헤더는 이러한 프로토콜 변환을 기록하므로 HTTP 애플리케이션은 프락시 연쇄에서 프로토콜 능력과 변환이 있었는지를 알아챌 수 있다.

Server 헤더와 Via 헤더

Server 응답 헤더 필디는 원 서버에 의해 사용되는 소프트웨어를 알려줌

Via가 개인정보 보호와 보안에 미치는 영향

Via를 통한 정보가 악의적인 집단에 이용될 수 있음

축약 가능

6.6.2 TRACE 메서드

HTTP/1.1의 TRACE 메서드는 요청 메시지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고 어떻게 각 프락시가 요청 메시지를 수정하는지 관찰/추적할 수 있도록 해준다

Max-Forwards

일반적으로 TRACE 메시지는 중간에 프락시들이 몇 개나 있든 신경 쓰지 않고 목적지 서버로의 모든 경로를 여행

개수를 제한하기 위해 Max-Forwards 헤더 사용 가능

6.7 프락시 인증

프락시는 접근 제어 장치로서 제공 가능

• 제한된 콘텐츠에 대한 요청이 프락시 서버에 도착했을 때, 프락시 서버는 접근 자격을 요구하는 407 상태 코드를 어떻게 그러한 자격을 제출할 수 있는지 설명해주는 Proxy-Authenticate 헤더 필드와 함께 반환할 수 있다.
• 클라이언트는 407 응답을 받게 되면, 로컬 데이터베이스를 확인해서든 사용자에게 물어봐서든 요구되는 자격을 수집
• 자격을 획득하면, 클라이언트는 요구되는 자격을 Proxy-Authorization 헤더 필드에 담아서 요청을 다시 보낸다
• 자격이 유효하다면, 프락시는 원 요청을 연쇄를 따라 통과시킨다.

6.8 프락시 상호운용성

6.8.1 지원하지 않는 헤더와 메소드 다루기

프락시는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러 개 있는 경우에는 그들의 상대적인 순서도 반드시 유지해야 한다.

비슷하게, 만약 프락시가 어떤 메서드와 친숙하지 않다면, 가능한 한 그 메시지를 다음 홉으로 전달하려 시도해야 한다

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

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

6.8.3 Allow 헤더

Allow 엔터티 헤더 필드는, 요청 URI에 으해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거

Allow: GET, HEAD, PUT

참조

1. HTTP 완벽 가이드