[HTTP] 6장: 프록시

서정범·2024년 1월 30일

Proxy http 프락시

HTTP

목록 보기

11/13

웹 프록시(Web Proxy)는 중개자라고 불립니다.

여기서는 웹 프록시가 어떤 것인지와 어떤 역할을 수행하는지 알아보도록 하겠습니다.

자세한 내용을 살펴보기 전에 우선 핵심적인 내용들만 정리를 하고 들어가도록 하겠습니다.

프록시 서버(Proxy Server)는 클라이언트와 다른 서버 사이에서 중계자 역할을 하는 서버입니다.

중계자라는 것은 클라이언트 요청을 받아 해당 요청을 대신하여 원하는 서버로 전송하고, 그 서버의 응답을 다시 클라이언트에게 전달해주는 역할을 수행하기 때문입니다.

데이터의 흐름 제어도 수행을 하는데, 프록시 서버는 필요에 따라 요청이나 응답을 변경하거나 필터링할 수 있습니다.

주요 역할을 정리해보자면 다음과 같습니다.

캐싱(Caching)
보안(Security)
필터링(Filtering)
익명성(Anonymity)
로드 밸런싱(Load Balancing)

크게 보자면 종류는 이와 같습니다.

전달 프록시(Foward Proxy): 클라이언트와 서버 사이에서 동작하며, 클라이언트의 요청을 인터넷으로 전달합니다.
리버스 프록시(Reverse Proxy): 외부의 요청을 내부 네트워크의 서버로 전달하는 역할을 합니다. 주로 보안과 로드 밸런싱, 캐싱 등의 목적으로 사용됩니다.

1. 웹 중개자

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

여기서는 프록시의 종류를 사용하는 클라이언트의 수로 구분하여 나눠놨습니다.

공용 프록시: 여러 클라이언트들이 같이 사용하는 프록시로, 대부분의 프록시가 이와 같은 형태로 사용됩니다.
개인 프록시: 개인 전용 프록시로 그다지 흔하지는 않지만 꾸준히 사용되고 있습니다. 브라우저의 기능을 확장하거나 성능을 개선하거나 무료 ISP 서비스를 위한 광고를 운영하기 위해 작은 프록시를 사용자의 컴퓨터에서 직접 실행하는 보조 제품들이 예입니다.

프록시와 게이트웨이는 크게 차이가 있는 것 같지 않지만, 목적에서 차이가 존재합니다.

프록시 서버는 중계자 역할을 수행하지만, 게이트웨이 서버는 다른 네트워크 사이에서 통신을 가능하게 하는 역할을 수행합니다.

게이트웨이는 이러한 목적을 가지고, 프로토콜을 변환하거나 다른 네트워크 기술로 변환해주는 등의 작업을 수행합니다.

프록시 서버는 캐싱, 요청 필터링, 사용자 인증, 안전성 강화 등을 이용해서 성능 개선 및 사용자 경험 개선과 같은 목적을 통해 사용하고, 게이트웨이 서버는 통신의 다리 역할을 수행한다고 보면 됩니다.

2. 왜 프록시를 사용하는가?

위에서 언급했지만, 프록시의 사용 효과는 여러 가지 있습니다.

보안을 개선
성능 향상
비용 절약
네트워크 트래픽 감시 및 수정

책에서 언급되는 대표적인 예를 정리해보자면,

어린이 필터, 문서 접근 제어자, 보안 방화벽, 웹 캐시, 대리 프록시, 콘텐츠 라우터, 트랜스코더, 익명화 프록시 등을 언급했습니다.

몇 개만 내용을 정리해보자면,

문서 접근 제어자의 경우 프록시를 사용해서 각 사용자의 요청을 추적하고 제한하는 역할을 수행하도록 하는 프록시입니다.

콘텐츠 라우터는 사용자들에게 제공할 여러 서비스들을 구분하여 더 좋은 서비스를 신청한 사용자들에게는 요청에 가까운 캐시 서버로 라우팅 해주는 작업 등을 수행합니다.

트랜스 코더는 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정하여 전달하는 작업을 수행합니다.

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

마지막으로 익명화 프록시는 HTTP 메시지에서 신원을 식별할 수 있는 특성들을 적극적으로 제거함으로써 개인 정보 보호와 익명성 보장에 기여합니다.

3. 프록시는 어디에 있는가?

책에서는 프록시를 배치하는 몇 가지 방법에 대해서 언급하고 있습니다.

출구(Egress) 프록시
로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프록시를 로컬 네트워크의 출구에 박아 넣을 수 있습니다.
접근(입구) 프록시
고객으로부터의 모든 요청을 종합적으로 처리하기 위해 프록시는 ISP 접근 지점에 위치하기도 합니다.
대리 프록시
대리 프록시는 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청할 수 있습니다.
네트워크 교환 프록시
캐시를 이용해 인터넷 교차로의 혼잡을 완화하고, 트래픽 흐름을 감시하기 위해, 충분한 능력을 갖춘 프록시가 네트워크 사이의 인터넷 피어링 교환 지점들에 놓일 수 있습니다.

클라이언트와 서버 사이에 놓일 수 있는 프록시는 여러 개가 존재할 수 있으며 인바운드 프록시(부모)와 아웃바운드 프록시(자식)으로 구분될 수 있습니다.

인바운드 프록시: 서버에 가까운 쪽 프록시
아운바운드 프록시: 클라이언트에 가까운 쪽 프록시

자식 프록시가 선택할 수 있는 부모 프록시가 여러 개라면 다음과 같은 고려사항을 통해서 선택할 수 있을 것입니다.

부하 균형
지리적 인접성에 근거한 라우팅
프로토콜/타입 라우팅
유료 서비스 가입자를 위한 라우팅

이렇게 프록시가 다른 프록시를 선택하는 방식은 살펴보았습니다.

프록시를 적절히 배치를 했다고 해도, 프록시가 사용되도록 설정되어 있지 않다면 클라이언트 요청은 프록시를 거쳐가지 않을 것입니다.

프록시를 사용하도록 설정하는 방법에는 다음 4가지 방식을 언급 해놓았습니다.

클라이언트를 수정한다.
네트워크를 수정한다.
DNS 이름강간을 수정한다.
웹 서버를 수정한다.

4. 클라이언트 프록시 설정

이 부분은 간단하게만 정리하도록 하겠습니다.

클라이언트가 프록시를 사용하도록 설정하는 방법에는 여러 가지가 있습니다.

수동 설정
프록시를 사용하겠다고 명시적으로 설정
브라우저 기본 설정
브라우저 벤더나 배포자는 브라우저를 소비자에게 전달하기 전에 프록시를 미리 설정
프록시 자동 설정(Proxy auto-configuration, PAC)
자바스크립트 프록시 자동 설정(PAC) 파일에 대한 URI를 제공할 수 있습니다. 클라이언트는 프록시를 써야 하는지, 만약 그렇다면 어떤 프로시 서버를 써야 하는지 판단하기 위해 그 자바스크립트 파일을 가져와서 실행합니다.
WPAD 프록시 발견
대부분의 브라우저는 자동설정 파일을 다운받을 수 있는 '설정 서버'를 자동으로 찾아주는, 웹 프록시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol, WPAD)을 제공합니다.

수동 방식은 간단하지만 여러가지 단점을 가지고 있습니다.

프록시 단 하나 지정
장애시 대체 로직 X
관리 문제
설정 변경 어려움

따라서, 동적인 해결책으로 프록시 자동 설정(PAC) 파일을 사용하여 상홍에 맞게 계산해줍니다.

WPAD는 브라우저는 URI로부터 PAC 파일을 가져와서 실행하기 때문에 이 동작을 수행하기 위해 사용됩니다. WPAD는 올바른 PAC 파일을 알아내기 위해 일련의 리소스 발견 기법을 사용합니다.

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

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

여기서는 URI와 관련하여 프록시를 사용했을 때와 사용하지 않았을 때 어떠한 차이가 존재하는지 설명하고 있습니다.

위에서 언급했던 것과 같이 사용자가 프록시 서버를 사용하는 방식으로 4가지가 존재하는 것을 확인했습니다.

일반적으로 클라이언트가 서버로 요청을 보낼 때의 요청 메시지의 URI를 확인해보면, 상대 주소로 되어 있는 경우가 많습니다.

이렇게 사용이 가능한 이유는 Connection 기반의 통신을 통하여 Layer 4의 IP 주소를 통해서 패킷이 전송되고 Layer 7에서 별도의 라우팅 작업을 수행할 필요가 없기 때문입니다.

하지만, 프록시 서버는 Layer 7에서 동작하는 라우팅 기능 및 필요 동작을 수행하기 때문에 전체 주소(절대 주소)를 요구합니다.

이와 같은 비슷한 예시로, 가상 호스팅에서 도메인을 구분하기 위해서 Host헤더를 사용하는 것을 확인할 수 있었습니다.

물론, 프록시를 원할하게 사용하기 위해서 무조건 절대 주소를 사용해야 되는 것은 아닙니다. 인터셉트 프록시의 경우, 클라이언트가 웹 서버로 보내는 요청을 도중에 가로채서 작업을 수행하기 때문에 이 경우 요청은 상대 주소로 되어 있을 것입니다.

완전 URI와 부분 URI를 사용하는 규칙은 다음과 같습니다.

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

앞 장에서 'URI 확장'에 대해서 언급했었는데, 클라이언트는 부분적인 URI를 입력하여 성공적으로 호스트 명을 확장했고 그 요청을 보낼 때 그것을 인터셉트 프록시가 가로챌 수 있습니다.

이러한 경우에 해당 서버의 상태를 프록시 서버가 관리하고 있고, 요청을 적절하게 수행할 수 있는 서버로 해당 요청을 전달하는 기능을 수행할 수 있습니다.

6. 메시지 추적

여기서는 메시지를 추적하기 위해서 제공하는 방법에 대해서 언급하고 있습니다.

Via 헤더 필드
Trace 메서드

Via 헤더 필드는 메시지가 지나는 각 중간 노드(프록시나 게이트웨이)의 정보를 나열합니다.

Via 헤더 필드의 문법은 쉼표로 구분된 경유지(waypoint)의 목록이고, 이것은 자신을 가리키는 유일한(unique) 문자열이 경유지로 담기게 됩니다.

해당 필드를 사용하여 이전까지 지나온 중계자들이 어떤 버전을 다룰 수 있는지 알 수 있고, 프로토콜 변환이 일어났는지 확인할 수 있습니다.

Trace 메서드는 요청 메시지를 프록시의 연쇄를 따라가마녀서 어떤 프록시를 지나가고 어떻게 각 프록시가 요청 메시지를 수정하는지 관찰/추적할 수 있도록 해줍니다.

Trace는 프록시의 흐름을 디버깅 하는데 매우 유용합니다.

TRACE와 OPTIONS 요청의 프록시 홉의 수를 제한하기 위해 Max-Forwards 헤더를 사용할 수 있는데, 이는 전달되는 메시지가 무한 루프에 빠지지 않는지 프록시 연쇄를 테스트 하거나 연쇄 중간의 특정 프록시 서버들의 효과를 체크할 때 유용합니다.