6. Proxies

[학습목표]

• 웹 프락시 서버는 중개자

• 프락시와 게이트웨이 비교하고 프락시 어떻게 배치되는지?

• 트래픽이 어떻게 프락시 서버로 가게 되는지

• 브라우저에서 프락시 어떻게 사용하기 위한 설정

• 프락시 서버에 요청하는것과 서버 요청의 차이점, 프락시 서버가 브라우저의 요청을 어떻게 바꾸는지?

• via header, trace method 를 이용한 기록 방법?

• 각각의 다른 기능과 버전들을 지원하고 상호작용하는지 설명할 수 있다.

01) 웹 중개자

• 서버이면서 동시에 클라이언트여야한다.

• 따라서 HTTP 클라이언트, 서버 양쪽 규칙을 모두 주의깊게 따라야한다.

① 개인프락시 vs 공유프락시

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

• 공용 프락시

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

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

  • '캐시 프락시 서버'같은 몇몇 프락시 app은 여러 사용자들이 공통된 요청을 하면 이득을 취할수 있다.

• 개인 프락시

  • 흔치 않으나 꾸준히 사용됨. (클라이언트 컴퓨터에서 직접 실행되는 형태)

② Proxy vs GateWay

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

• gateway: 서로 다른 프로토콜을 사용하는 둘 이상을 연결 (마치 프로토콜 변환기 처럼 작동)

  실제로는 두 사이의 차이점이 모호하기는 한 것이 종종 프락시가 프로토콜 변환을 하기도 하고, 상용 프락시 서버는 SSL 보안 프로토콜, SOCKET 방화벽, FTP 접근, 웹 애플리케이션 지원을 위한 기능을 구현하기도 함. (8장 gateway 를 보고 다시 한번 생각해보도록)

2) Proxy 왜 사용 하는걸까?

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

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

EX)

• 어린이 필터

• 문서 접근 제어 (중앙 프락시 서버에서 접근제어)

• 보안 방화벽

• 웹캐시

• 대리프락시(=surrogate, reverse proxies, server accelerators): 느린 웹 서버 성능 개선

• 콘텐츠 라우터: 콘텐츠 종류에 따라 요청을 특정 서버로 유도, 사용자에게 제공할 여러 서비스 구현

• 트랜스코더: 적절한 형태로 변환(크기를 줄여주거나, 언어를 변환하거나, 화면별로 보기편하게 등등)

• 익명화 프록시: 발송자의 이메일주소, 보낸경로, 사용한 컴퓨터와 os 정보를 없애서 개인정보를 보호한다.

3) 프락시는 어디에 있는가?

어디에 있고, 언제 아키텍처상에 배치되는것인지 생각해보자.

① 프락시 서버 배치 [어떻게 배치하는가?]

• 어떻게 사용할지에 따라 어디서든 배치가 가능하다.

  • 출구(Egress) 프락시: 로컬네트워크과 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 로컬네트워크의 출구에 박아둔 프락시

  • 접근(입구) 프락시: 고객으로부터 모든 요청을 종합적으로 처리하기 위해 ISP 접근지점에 위치

  • 대리 프락시(=reverse proxies): 네트워크 가장 끝에 있는 웹서버들의 바로 앞에 위치하면서 웹서버로 향하는 모든 요청을 처리하고, 필요할때에만 웹서버에 자원요청을 함.웹 서버의 이름과 IP주소로 스스로를 가장하므로 모든 요청은 서버가 아닌 이 프락시로 감.

  • 네트워크 교환 프락시: 캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름 감시하기 위해 인터넷 피어링 교환 지점에 놓임

② 프락시 계층 (Hierarchies)

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

• 메세지는 최종적으로 원서버에 도착할때까지 프락시에서 프락시를 거쳐 이동한다.

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

• 위 그림은 정적은 프록시 계층이다. 모든 프락시 계층이 정적인 것은 아니다. (cf. figure 6-13)

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

• 동적 부모 선택 예: 부하 균형, 지리적 인접성에 근거, 프로토콜/타입 라우팅, 유료서비스 가입자 위한 라우팅

③ 프락시가 트래픽 처리를 어떻게 하는가.

• 클라이언트 트래픽이 프록시에 가도록 만드는 방법 4가지

  • 클라이언트 수정: 대부분의 클라이언트(브라우저)들은 수동 혹은 자동 프락시 설정을 지원한다.

  • 네트워크를 수정: 클라이언트를 알지도, 간섭할수도 없는 상태에서 네트워크 인프라를 가로채서(스위칭, 라우팅 장치) 웹 트래픽을 프록시로 가도록한다.

    (클라이언트 모르게 HTTP 트래픽을 가로채서 보낸다해서 인터셉트 프락시, 투명 프락시 라고도 한다.)

  • DNS 이름 공간 수정: 웹 서버 앞에 위치하는 프락시 서버인 대리프락시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용.(대리프락시, reverse proxies)

  • 웹서버 수정: 리다이렉트를 받는 즉시 클라이언트는 프락시와 트랜잭션을 시작한다.

4) 클라이언트 프락시 설정

현대 브라우저는 프락시 사용할 수 있도록 설정이 가능하고, 많은 브라우저가 프락시 설정하는 여러 방법을 제공.

① 수동 설정

• 프락시 사용을 명시적으로 설정

② 브라우저 기본설정

• 브라우저 벤더나 배포자는 브라우저(or 다른 web client)를 소비자에 전달하기 전에 프락시 설정을 미리 해둘 수 있다.

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

• 수동 설정은 단순하나, 유연하지 못하고 모든 콘텐츠를 위해서 단 하나의 프락시 서버만 지정이 가능하다.

  따라서 큰 조직에서 관리문제와 장애시 대체 작동에 대한 지원도 없다.

• PAC는, 프락시 설정에 대한 동적인 해결책인데 설정을 상황에 맞게 계산하는 js 프로그램이기 때문. 문서 접근시 js 의 함수가 적절한 프락시 서버를 선택한다.

• js PAC 파일의 URI를 브라우저에서 설정해야한다. 브라우저는 URI로부터 PAC 파일을 가져와서 매 접근마다 적절한 프락시 서버를 계산하기 위해 js 이용한다. (확장자 .pac)

• FindProxyForUrl(url, host) 함수 정의. MIME type application/x-ns-proxy-autoconfig

④ WPAD 프락시 발견

• 대부분의 브라우저에서 자동설정 파일을 다운 받을 수 있는 '설정 서버'를 자동으로 찾아주는 프로토콜을 제공

• WPAD: Web Proxy Auto Discovery Protocol

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

• 올바른 PAC 파일을 알아내기 위해 리소스 발견 기법을 사용.

5) 프락시 요청의 미묘한 특징

① 프락시 (요청) URI vs 서버 URI

• 클라이언트가 웹 서버로 요청을 보낼때: [스킴, 호스트, 포트번호] 가 없는 부분 url을 가진다.

• 클라이언트가 프락시로 요청을 보낼때: 완전한 url 을 갖는다.

• 왜?

  • 기존 HTTP 설계에서 클라이언트는 단일 서버와 직접 대화 했었고, 호스트명과 포트번호를 알고 있었으므로 불필요한 정보를 보내지 않기 위해 부분 url만 보냈었는데 프락시나 가상호스팅이 생기면서 부분 url이 문제가 생겼다. 목적지 서버와 커넥션을 위해 서버 이름이 필요했고, FTP리소스 이외 스킴과 연결을 위해 URI의 스킴도 알아야했기 때문에 프록시 서버에는 완전한 URI를 요청한다.

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

• 문제 해결을 위해서

  • 명시적인 프락시는 요청 메세지가 완전한 URI를 가지도록 해서 해결했고

  • [스킴, 호스트, 포트번호] 누락문제는 가상호스트되는 웹 서버가 직면한 문제와 같은 문제가 있다.

  • 가상 호스팅되는 웹 서버는 호스트와, 포트에 대한 정보를 담은 host header를 요구한다.

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

• 클라이언트가 HTTP 를 올바로 구현했다면 명시적으로 설정된 프락시에게는 완전한 URI를 보낸다.

• 일부 문제는 해결되나, 클라이언트는 항상 프록시와 대화하는 것을 알아채는것이 아니기 때문에 클라이언트는 자신이 웹서버와 대화하고 있다 생각하고 완전한 URI를 보내지않는다.

④ 프락시는 프락시요청, 서버 요청 모두 다룰수 있다.

• 트래픽이 프록시로 리다이렉트하는 여러 방법이 존재하기 때문에, 다목적 프록시 서버는 완전한 URI와 부분 URI를 모두 지원해야한다.

• 완전 URI 와 부분 URI 사용규칙 (p167참조)

⑤ 전송 중 URI 변경

• 무해해보이는 사소한 URI 변경이라도 다운스트림 서버와 상호운용성 문제를 예방하기위해 신경써야한다.

• 일반적으로 프록시 서버는 가능한 관대하도록 애써야한다.

⑥~⑨ (uri 분석 방법 상세 설명 참조 6.5.6 ~ 6.5.8)

6) 메시지 추적

① Via 헤더

• 메시지가 지나는 각 중간 노드(프락시 or 게이트웨이)의 정보를 나열한다.

• 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고, 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기위해 사용된다.

• 네트워크의 라우팅 루프를 탐지하기 위해 사용

• 쉼표로 구분된 경유지(waypoint)의 목록

② Trace Method

홉에서 홉으로 절달될때마다 메시지의 내용이 어떻게 변하는지 편리하게 관찰할 방법이 필요햐다.

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

7) 프락시 인증

접근 제어 장치로서 제공이 될 수 있다.

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

8) 프락시 상호운용성

클라이언트, 서버, 프락시는 HTTP 명세의 여러 버전에 대해 여러 벤더에 의해 만들어진다.

그들이 지원하는 여러 기능을 지원하고 각각 다른 버그를 가지고 있다.

프락시 서버는 서로 다른 프로토콜을 구현했을 수도 있고 이상한 동작을 할 수도 있는 클라이언트와 서버를 중개해야한다.

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

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

• options: 어떤 기능을 지원하는지 알아보기

• allow 헤더: 요청 uri에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드 열거

[용어 정리]

• 트래픽(Traffic): 서버와 스위치 등 네트워크 장치에서 일정시간 내에 흐르는 데이터의 양

• ISP(Internet Service Provider): 개인, 기업체에 인터넷 접속 서비스, 웹사이트 구축 및 웹호스팅등을 제공하는 회사(국내에 KT, SK 브로드밴드, LG U+)