[HTTP] 06. 프락시

프록시에는 여러 클라이언트와 연결되는 ‘공유 프록시’와 하나의 클라이언트만을 다루는 ‘개인 프록시’로 나눠진다. 두 프록시는 사용자의 실제 IP 정보를 숨기거나, 개인정보를 외부에 노출하는 것을 방지하는 목적으로 사용되며, 보안과 관련된 기능을 제공하는 목적으로 사용된다는 점에서 동일하다. 하지만, ‘공유 프록시’는 불특정 다수에게 연결될 수 있으며, ‘개인 프록시’는 클라이언트의 컴퓨터에서 직접 실행시키는 방식으로 사용될 수 있다는 점에서 다르다.

6.1.2 프록시 대 게이트웨이

엄밀하게 말하면, 프록시는 같은 프로토콜을 사용하는 둘 이상의 어플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다는 점에서 다르다. 하지만, 실제로는 프록시와 게이트웨이의 차이점은 모호하다. 프록시는 HTTP의 서로 다른 버전을 연결해주기 위해 프로토콜 변환기의 동작을 수행하기도 하며, SSL 보안 프로토콜, FTP 접근 등의 게이트웨이 기능을 지원한다. 아래 이미지는 프록시와 게이트웨이의 차이점을 나타낸 이미지이다. (그러나 현실세계에서의 구현체는 두 개념이 모호하다)

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

프록시는 보안 개선, 성능 향상, 비용 절약, 트래픽 감시 및 수정 등의 기능을 수행한다.

어린이 필터 : 성인 컨텐츠와 같이 어린이에게 부적절한 컨텐츠에 대한 접근을 제한한다.

문서 접근 제어자 : 많은 웹 서버들과 웹 리소스에 대한 접근 제어 전략을 구현하고 감사 추적을 하기 위해 사용될 수 있다. → 금융 회사를 예로 들자면, 인터넷PC에서 특정 웹 서버에 대해서만 통신할 수 있게 제한하거나, 내부망PC에서 외부로 문서를 전송할 때, 외부 서버 접근을 거부하거나 권한(ex. 비밀번호)을 요구하는 것이 있다.

보안 방화벽 : 보안을 강화하기 위해 프록시 서버를 사용할 수 있다. 프록시 서버는 조직 내부와 통신하는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제한다.
웹 캐시 : 원 서버의 컨텐츠를 캐싱하여 클라이언트에게 제공한다.
대리 프록시(리버스 프록시) : 웹 서버인 것처럼 위장하여, 진짜 웹 서버 요청을 받지만 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 한다.

콘텐츠 라우터 : 프록시 서버는 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작할 수 있다. 예를 들어 사용자나 콘텐츠 제공자가 더 높은 성능을 위해 돈을 지불했다면, 콘텐츠 라우터는 가까운 복제 캐시 서버로 요청을 전달할 것이고, 그렇지 않은 경우 원 서버로 요청을 전달할 것이다.
트랜스 코더 : 콘텐츠를 클라이언트에게 전달하기 전에 본문 포멧을 수정할 수 있다. 이와 같이 데이터의 표현 방식을 자연스럽게 변환하는 것을 트랜스코딩이라고 부른다. 예를 들어 한글로 된 HTML 문서를 스페인어를 사용하는 클라이언트에게 맞춰 스페인어로 변역한 HTML 문서를 전달하는 것이 있다.

익명화 프록시 : HTTP 메시지에서 신원을 식별할 수 있는 특성들(ex. 클라이언트 IP 주소, From 헤더, Referer 헤더, 쿠키, URI 세션 아이디)을 제거함으로써 개인 정보 보호와 익명성 보장에 기여할 수 있다.

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

6.3.1 프록시 서버 배치(→ 물리적 위치)

출구(Egress) 프록시(a) : LAN과 WAN을 연결하는 지점에 설치된다. 방화벽, 인터넷 요금 절약, 인터넷 트래픽의 성능 개선, 컨텐츠 필터링 등과 같은 기능을 적용할 수 있다.
접근(입구) 프록시(b) : 고객으로부터의 모든 요청을 종합적으로 처리하기 위해 ISP(Internet Service Provider, ex. KT, SK브로드밴드, LG U+) 접근 지점에 위치하기도 한다. 다운로드 속도 개선 & 인터넷 대역폭 비용 감소를 위해 캐시 프록시로써 사용되곤 한다.
대리 프록시(reverse proxy)(c) : 웹 서버 바로 앞에 위치하는 프록시이다. 보안, 캐시 등의 기능을 부여할 수 있다. 대리 프록시는 일반적으로 웹 서버의 이름과 IP 주소로 스스로를 가장하기 때문에, 모든 요청은 서버가 아닌 이 프록시로 가게 된다.
네트워크 교환 프록시(d) : 네트워크와 네트워크 사이에서 트래픽 혼잡을 완화하고 트래픽을 감시하는 목적으로 사용될 수 있다.

6.3.2 프록시 계층

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

프록시 계층에서 프록시들은 부모와 자식의 관계를 갖는다. 특정 프록시를 기준으로 인바운드로 들어온 프록시는 ’부모 프록시’라고 말하고, 아웃바운드로 연결될 프록시는 ‘자식 프록시’라고 말한다.

다만, 프록시 계층은 정적이여야 하는 것은 아니다. 상황에 따라 변경될 수 있다. 위 그림의 프록시 계층은 정적이지만, 동적 부모 선택이 가능하다. 예를 들어 다음의 상황이 있다.

동적 부모 선택

부하 균형 : 자식 프록시는 부하를 분산하기 위해 현재 부모 프록시들의 작업량 수준을 파악하고, 그에 따라 부모 프록시를 선택할 수 있다.
지리적 인접성에 근거한 라우팅 : 원 서버의 지역을 담당하는 부모 프록시를 선택할 수 있다.
프로토콜/타입 라우팅 : 특정 종류의 URI를 갖고 있는 요청일 경우, 해당 URI(or 프로토콜)를 처리하는 부모 프록시를 선택할 수 있다.
유료 서비스 가입자를 위한 라우팅 : 웹 서비스 운영자가 빠른 서비스를 위해 추가금을 지불한 경우, 원 서버가 아닌 캐싱 서버나 압축 서버로 라우팅될 수 있다.

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

클라이언트 트래픽이 프록시로 가도록 만드는 방법은 다음 네 가지가 있다.

클라이언트를 수정 : 만약 클라이언트가 프록시를 사용하도록 설정되어 있다면, 원 서버가 아닌 프록시로 요청을 보낸다.
네트워크를 수정 : 클라이언트가 알지도 간섭하지도 못하는 상태에서, 네트워크 인프라를 가로채서 웹 트래픽을 프록시로 가도록 조정하는 방법이다. 일반적으로, HTTP 트래픽을 감지하다가 가로채는 스위칭 장치 or 라우팅 장치를 필요로 한다. 이를 인터셉터(or 투명) 프록시라고 말한다.
DNS 이름공간을 수정 : 웹 서버 앞에 위치하는 대리 프록시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용한다. DNS 이름 테이블을 수동으로 편집하거나, 동적 DNS 서버를 이용해서 조정될 수 있다.
웹 서버를 수정 : 웹 서버는 HTTP 리다이렉션 명령(응답 코드 305)을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프록시로 리다이렉트 하도록 설정할 수 있다. 리다이렉트를 받는 즉시 클라이언트는 프록시와 트랜잭션을 시작한다.

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

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

웹 서버와 웹 프록시 메시지의 문법은 서로 같지만, 한 가지 예외가 있다. 클라이언트가 프록시 대신 서버로 요청을 보내면 요청의 URI가 달라진다. 클라이언트가 단일 서버와 통신한다고 판다하고 URI에 프로토콜, 호스트명 등을 제외하고 메시지를 전송할 수 있다. 반면, 프록시 서버는 반드시 전체 URI를 메시지에 담아 전송해야 한다. 이 때문에, 클라이언트가 부분 URI만 가지고 메시지를 전송하는 경우에 대비해야 한다. (현재는 서버인지 프록시인지와 상관없이 대부분 전체 URI를 사용한다고는 하지만, 실제로는 어떠한지 확인이 필요해보인다.)

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

가상으로 호스팅되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유한다. 만약 부분 URI를 담은 요청이 들어온다면, 가상으로 호스팅되는 웹 서버는 요청이 접근하고자하는 웹 사이트의 호스트 명을 알 필요가 있다. 이를 위한 방법은 아래와 같다.

명시적인 프록시는 요청 메시지가 완전한 URI를 갖도록 한다.
가상 호스팅되는 웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더를 요구한다.

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

클라이언트는 자신이 프록시와 대화하고 있음을 항상 알고 있는 것은 아니다. 클라이언트가 프록시와 통신하고 있음을 몰라, 부분 URI를 담은 메시지를 전송할 경우, 인터셉터 프록시가 이를 받게 될 수 있다.( → 인터셉터 프록시는 부분 URI와 본인이 알고 있는 웹 서버 정보를 조합하여 전체 URI를 얻어내야 될 것이다.)

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

프록시 서버는 완전한 URI(프록시 요청)와 부분 URI(서버 요청)을 모두 다룰 수 있어야 한다. 클라이언트에서 명시적인 프록시 설정이 되있으면 완전한 URI를 요청할 것이며, 그렇지 않다면 부분 URI를 요청할 것이다. 완전 URI와 부분 URI를 다루는 규칙은 아래와 같다.

완전한 URI가 주어졌다면, 그것을 사용한다.
부분 URI가 주어지고, Host 헤더가 있다면, 이를 이용해 완전 URI를 도출한다.
부분 URI가 주어졌으나, Host 헤더가 없다면, 프록시에 등록되있는 원 서버의 정보를 통해 완전 URI를 도출한다.
부분 URI가 주어졌으나, Host 헤더가 없고, 프록시에서 원 서버의 정보를 얻을 수 없다면, 프록시는 클라이언트에게 오류 메시지를 전송해야 한다.

6.6 메시지 추적

네트워크 상에 프록시가 많아짐에 따라, IP 패킷을 추적하는 것 이외에, 프록시를 넘나드는 메시지의 흐름을 추적하고 문제를 찾아내는 것도 필요한 일이 되었다.

6.6.1 Via 헤더

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

Via : 1.1 proxy-62.isp.net, 1.0 cache.test.com

위 내용은 HTTP/1.1을 구현하는 “proxy-62.isp.net”에 해당하는 프록시를 거쳤으며, HTTP/1.0을 구현한 “cache.test.com”이라는 프록시를 거쳤음을 의미한다. Via 헤더에 담긴 내용은 메시지 전달을 추적하고, 메시지 루프를 진단하고, HTTP 트랜잭션에 관여하는 노드들이 HTTP 프로토콜을 다루는 능력을 알아보기 위해 사용된다.

프록시 서버의 입장에서, 전달받은 메시지의 Via 헤더에 자신의 포함되있는지를 확인하여 네트워크 루핑을 탐지할 수 있다.

Server 헤더와 Via 헤더

Server 응답 헤더 필드는 원 서버에 의해 사용되는 소프트웨어를 알려준다. 프록시는 Server헤더를 수정해서는 안되며, 프록시 서버의 정보는 Via 헤더에 담겨져야 한다.

Server : Apache/1.3.14 (Unix) PHP/4.0.4
Server : Microsoft-IIS/5.0

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

Via에 담긴 호스트명이 정확한 호스트명임을 보장해주지는 않는다. 예를 들어 프록시 서버가 네트워크 방화벽의 일부인 경우 프록시는 방화벽 뒤에 숨어있는 호스트의 이름과 포트를 전달해서는 안 된다. 방화벽 뒤의 네트워크 아키텍처에 대한 정보가 악의적인 집단에 의해 이용될 수 있기 때문이다.

프록시는 Via에 가명을 넣거나, 일련의 호스트명들을 하나의 가명으로 변환하여 지정할 수도 있다.

6.6.2 TRACE 메서드

(널리 구현되있지 않기 때문에 패스한다.)

6.7 프락시 인증

프록시는 접근 제어 장치로서 제공될 수 있다. HTTP는 사용자가 유효한 접근 권한 자격을 프록시에 제출하지 않는 한 콘텐츠에 대한 요청을 차단하는 프록시 인증이라는 매커니즘을 정의하고 있다. 프록시 인증 과정은 다음과 같다.(다만, 인증에 참여하는 프록시가 프록시 연쇄상에 여러 개 있을 때는 일반적으로 잘 동작하지 않는다.)

제한된 컨텐츠에 대한 요청이 프록시 서버에 도착하면, 프록시는 접근 자격을 요구하는 407 Proxy Authorization Required 상태 코드와 자격 제출 방법 설명인 Proxy-Authenticate 헤더 필드를 함께, 클라이언트에게 응답한다.
클라이언트는 프록시 서버에 알려준 사항을 통해 자격을 획득하고, Proxy-Authorization 헤더 필드에 담아 프록시 서버에 요청한다.
프록시 서버는 자격이 유효하다면 요청을 다음 홉으로 전달한다.

6.8 프락시 상호운용성

프록시 마다 지원하는 기능이 다르고 각각 다른 버그를 담고 있다. 이러한 상호운용성의 문제를 해결하기 위해 여러 방법이 존재한다.

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

지원하지 않는 헤더나 메서드를 만날 경우 → 수정이나 어떠한 처리를 하지 않고, 있는 그대로 다음 홉으로 전달한다.

프록시 서버는 메시지에 담긴 헤더들 중 이해하지 못하는 헤더를 직면할 수 있다. 이 경우, 반드시 있는 그대로 다음 홉에 전달해야 한다. 이러한 이유는 프록시가 네트워크 상에서 생존하기 위함일 수 있다.

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

HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지(예를 들면 지원하는 메서드) 클라이언트(혹은 프락시)가 알아볼 수 있게 해준다.( → CORS와 관련한 사항을 확인할때 사용하는 것 같다.)

'CS > 네트워크' 카테고리의 다른 글

[HTTP] 07. 캐시 (2) (2)	2024.01.08
[HTTP] 07. 캐시 (1) (0)	2024.01.07
[HTTP] 05. 웹 서버 (2)	2024.01.05
[HTTP] 04. 커넥션 관리 (2)	2024.01.05
[HTTP] 03. HTTP 메시지 (0)	2024.01.02

Waltz for programming

[HTTP] 06. 프락시