6. 프락시

웹 프락시 서버는 중개자다.

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

 

1. 웹 중개자

 

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

 

• 프락시를 이용하면 프락시 서버가 제공하는 좋은 서비스를 이용할 수 있다.
• HTTP 프락시 서버는 웹 서버이기도 하고 웹 클라이언트이기도 하다.
• HTTP 프락시를 만든다면, HTTP 클라이언트와 HTTP 서버의 양쪽 규칙 모두를 주의 깊게 따라야 한다.

 

1. 개인 프락시와 공유 프락시

 

공용 프락시

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

 

개인 프락시

• 개인 전용 프락시는 그다지 흔하지는 않지만 꾸준히 사용되고 있다.

 

2. 프락시 대 게이트웨이

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

 

 

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

• 보안 개선
• 성능을 높여줌
• 비용 절약
• 부가적인 가치를 주는 여러 유용한 웹 서비스를 구현하기 위해 트래픽을 감시하고 수정할 수 있다.

 

프락시 사용 예시

어린이 필터

• 어린이들에게 교육 사이트 제공하면서 성인 콘텐츠를 차단하는 필터링 역할

 

문서 접근 제어자

• 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적을 하기 위해 사용
• 중앙 프락시 서버에서 접근을 제어

 

보안 방화벽

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

 

웹 캐시

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

 

대리 프락시

• 공용 콘텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용
• 콘텐츠 라우팅 기능과 결합되어 주문형 복제 콘텐츠의 분산 네트워크를 만들기 위해 사용

 

콘텐츠 라우터

• 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작
• 많은 흥미로운 서비스가 맞춤형 콘텐츠 라우팅 프락시를 이용해서 구성

 

트랜스코더

• 프락시 서버는 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있다.
• 데이터의 표현 방식을 자연스럽게 변환하는 것을 트랜스코딩이라고 부른다.
• 자신을 거쳐가는 파일의 크기를 압축하여 비싼 인터넷 커뮤니케이션을 줄일 수 있다.

 

익명화 프락시

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

 

 

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

1. 프락시 서버 배치

 

출구 프락시

• 로컬 네트워크의 출구에 위치시키는 프락시
• 방화벽 제공, 트래픽 성능 개선, 부적절한 콘텐츠 제한

 

접근(입구) 프락시

• 고객으로부터의 모든 요청을 종합적으로 처리하기 위해 ISP 접근 지점에 위치
• 사용자들의 다운로드 속도 개선
• 인터넷 대역폭 비용 개선

 

대리 프락시

• 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리
• 웹 서버에 보안 기능 추가
• 웹 서버 캐싱을 통한 성능 개선
• 프락시는 웹 서버의 이름과 IP주소로 변장

 

네트워크 교환 프락시

• 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시
• 네트워크 사이의 인터넷 피어링 교환 지점들에 위치

 

2. 프락시 계층

• 프락시 계층에서 프락시 서버들은 부모와 자식의 관계를 갖는다.
• 인바운드로 향하는 쪽이 부모가 된다.

 

프락시 계층 콘텐츠 라우팅

• 프락시 계층은 정적이나 반드시 정적일 필요는 없다.
• 부하 균형
  • 부모들의 작업량 수준에 근거하여 부모 프락시를 고른다
• 지리적 인접성에 근거한 라우팅
  • 원 서버의 지역을 담당하는 부모를 선택
• 프로토콜 / 타입 라우팅
  • URI에 근거하여 다른 부모나 원 서버로 라우팅
  • 특정 종류의 URI를 갖고 있는 요청의 경우 특별한 프락시 서버로 보내져 특별한 프로토콜로 처리될 수도 있다.
• 유료 서비스 가입자를 위한 라우팅
  • 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅

 

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

클라이언트 트래픽이 프락시로 가도록 만드는 방법

1. 클라이언트를 수정
   • 웹 클라이언트들을 수동 혹은 자동 프락시 설정을 지원
2. 네트워크를 수정
   
   •  
   • HTTP 트래픽을 지켜보고 가로채어 클라이언트 모르게 트래픽을 프락시로 보내는 스위칭 장치와 라우팅 장치를 필요(인터셉트 프락시)
3. DNS 이름 공간을 수정
   • 웹 서버의 이름과 IP주소를 자신이 직접 사용
   • DNS 이름 테이블을 수동으로 편집하거나 사용할 적절한 프락시나 서버를 계산해주는 특별한 동적 DNS 서버를 이용해서 조정될 수 있다.
4. 웹서버를 수정
   • 클라이언트의 요청을 프락시로 리다이렉트 하도록 설정

 

 

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

 

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

• 많은 웹 클라이언트가 프락시를 수동으로 설정할 수 있도록 하고 있다.
• 구글 크롬과 마이크로소프트 인터넷 익스플로러 둘 모두 간편하게 프락시 설정을 할 수 있도록 지원

 

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

• 프락시 설정을 그때그때 상황에 맞게 계산해주는 작은 자바스크립트 프로그램
• 문서에 접근할 때마다, 자바스크립트 함수가 적절한 프락시 서버를 선택
• PAC 파일은 일반적으로 .pac 확장자를 가지며 MIME 타입은 application/x-ns-proxy-autoconfig’이다.
• 각 PAC 파일은 반드시 URI에 접근할 때 사용할 적절한 프락시 서버를 계산해주는 FindProxyForUrl(url host)라는 함수를 정의해야 한다.

 

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

• 여러 발견 메커니즘들의 상승 전략을 이용해 브라우저에게 알맞은 PAC 파일을 자동으로 찾아주는 알고리즘
• WPAD 프로토콜이 구현된 클라이언트가 하게 될 일
  • PAC URI 찾기 위해 WPAD를 사용
  • 주어진 URI에서 PAC 파일을 가져온다
  • 프락시 서버를 알아내기 위해 PAC 파일을 실행
  • 알아낸 프락시 서버를 이용해서 요청을 처리
• WPAD는 성공할 때까지 각 기법을 하나씩 시도

 

 

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

 

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

• 클라이언트가 프락시 대신 서버로 요청을 보내면 요청의 URI가 달라진다.
  • 웹 서버 : 스킴, 호스트, 포트번호가 없는 URI
  • 프락시 : 완전한 URI
• 옛날에는 프락시라는 개념이 없어서 웹 서버와 직접 통신했기 때문에 상대 URI만 있었다.

 

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

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

 

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

• 클라이언트는 자신이 프락시와 대화하고 있음을 항상 알고 있는 것은 아니다.
  -> 몇몇 프락시는 클라이언트에게는 보이지 않을 수 있기 때문
• 비록 클라이언트가 프락시를 사용한다고 설정되어 있지 않더라도, 클라이언트의 트래픽은 여전히 대리 프락시나 인터셉트 프락시를 지날 수 있다.

 

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

• 다목적 프락시 서버는 요청 메시지의 완전한 URl와 부분 URl를 모두 지원해야 한다.
• 프락시는 명시적인 프락시 요청에 대해서는 완전한 URl를 사용하고 아니면 부분 URl를 사용해야 하며， 웹 서버 요청의 경우에는 가상 Host 헤더를 사용해야 한다.

완전한 URI와 부분 URI를 사용하는 규칙

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

 

5. 전송 중 URI 변경

• 무해해 보이는 사소한 URI 변경이라도 다운스트림 서버와 상호운용성 문제를 일으킬 수 있으므로 조심해야 함
• URI에서 기본 HTTP 포트를 명시적인 :80’로 변경하는 것이나 잘못 사용한 예약된 글자를 올바르게 이스케이프 하여 교체하는 것과 같은 무해해 보이는 변형이라 할지라도, 상호운용성 문제를 일으킬 수 있다.
• 일반적으로 프락시 서버는 가능한 한 관대하도록 애써야 한다.
• 유일한 예외는 빈 경로를 ’로 교체하는 것뿐이다.

 

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

• 호스트가 발견되지 않는다면, 많은 브라우저들은 시용자가 호스트 명의 짧은 약어를 타이핑한 것으로 보고 자동화된 호스트 명의 ‘확장’을 제공하고자 다음과 같이 몇 가지 시도를 한다
  • 'www.'접두사와 '. com' 접미사를 붙인다.
  • 해석할 수 없는 URI를 서드파티 사이트로 넘기기
  • 대부분의 시스템에서 DNS는 사용자가 호스트 명의 앞부분만 입 격하면 자동으로 도메인을 검색하도록 설정

 

7. 프락이 없는 URI 분석(URI Resolution)

 

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

• 브라우저의 URI가 프락시를 그냥 지나쳐버리기 때문에 명시적 프락시를 사용한다면 편리한 확장을 사용할 수 없다.
• URI 자동확장이나 접미사 추가 같은 브라우저의 편리한 서비스를 할 수 있다면 최대한 흉내 내려고 시도

 

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

• 단계에서 사용자는 브라우저의 URI 위치 창에 'oreilly ’라고 타이핑한다.
• 단계 2a에서 브라우저는 호스트 oreil1 ’를 DNS를 통해 찾아보지만, 단계 2b에서 DNS 서버는 실패하고 그 호스트는 알 수 없다고 응답한다.
• 단계 3a에서 브라우저는 oreilly’를 '. www.oreilly.com’으로 변환하는 자동확장을 한다. 단계 3b에서 브라우저는 DNS를 통해 호스트 www.oreilly.com’를 찾아본 다. 이때, 단계 3c에서 DNS 서버는 성공하고 IP 주소를 브라우저에게 반환한다.
• 단계 4a에서 클라이언트는 이미 성공적으로 호스트 명을 분석하였고 IP 주소의 목록을 갖고 있다. 일반적으로, 클라이언트는 성공할 때까지 모든 IP 주소에 대해 접속을 시도하지만, 어떤 IP 주소들은 죽은 것일 수 있다. 그러나 인터셉트 프락 시와 함께라면, 첫 번째 접속 시도는 원 서버가 아닌 프락시 서버에 의해 종료된다. 클라이언트는 성공적으로 웹 서버와 대화했다고 믿지만, 웹 서버는 살아있지도 않았을 것이다.
• 프락시가 최종적으로 진짜 원 서버와 상호작용할 준비가 되었을 때(단계 5b), 프 락시는 그 IP 주소가 실제로는 다운된 서버를 가리키고 있음을 알게 될 것이다. 브라우저에서 제공하는 것과 동등한 수준의 장애 허용(fault tolerance)을 제공하 기 위해서, 프락시는 호스트 헤더에 들어 있는 호스트 명을 다시 분석하든 아니면 IP 주소에 대한 역방향 DNS 룩업을 해서든 다른 IP 주소를 시도해야 한다. 

 

 

6. 메시지 추적

• 오늘날 웹 요청이 클라이언트에서 서버를 향하는 도중에 둘 이상의 프락시를 지나는 것은 드문 일이 아니다.
  • 많은 회사들이 보안과 비용 절감을 위해 인터넷 접속 시 캐시 프락시 서버를 사용
  • ISP들이 성능 개선과 기능 구현을 위해 프락시 캐시를 사용
  • 프락시는 여러 벤더에 의해 개발

 

1. Via 헤더

• Via 헤더 필드는 메시지가 지나는 각 중간 노드(프락시나 게이트웨이)의 정보를 나열
• 메시지가 다른 노드를 지날 때마다, 중간 노드는 Via 목록의 끝에 추가되어야 한다.
• Via 헤더 필드는 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용
• 네트워크의 라우팅 루프를 탐지하기 위해 사용

 

Via 문법

• Via 헤더 필드는 쉼표로 구분된 경유지(waypoint)의 목록
• 각 경유지는 개별 프락시 서버나 게이트웨이 홉을 나타낸다.
• ex) Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

프로토콜 이름

• 중개자가 받은 프로토콜
• 프로토콜이 HTTP라면 프로토콜 이름은 없어도 된다.
• 프로토콜 이름은 버전 앞에 “/"로 구분되어 붙는다.
• 비 HTTP 프로토콜은 게이트웨이가 다른 프로토콜(HTTPS， FTP 등)을 위해 HTTP 요청에 접속할 때 발생할 수 있다.

프로토콜 버전

• 수신한 메시지의 버전
• HTTP의 경우, 표준 버전 번호('1.0', '1,1'등)가 사용

노드 이름

• 중개자의 호스트와 포트 번호
• 정보 보호를 이유로 진짜 호스트 명을 밝히고 싶지 않을 때 가명으로 대체할 수 있다.

노드 코멘트

• 중개자 노드를 서술하는 선택적인 코멘트
• 장치에서 일어난 이벤트에 대한 진단 정보를 포함하는데도 코멘트 필드를 사용

Via 요청과 응답 경로

• 요청 메시지와 응답 메시지 모두 프락시를 지나므로 둘 모두 Via 헤더를 가진다.
• 응답의 Via 헤더는 거의 언제나 요청의 Via 헤더와 반대

Via와 게이트웨이

• 몇몇 프락시는 서버에게 비 HTTP 프로토콜을 사용할 수 있는 게이트웨이 기능을 제공
• Via 헤더는 프로토콜 변환을 기록하므로 HTTP 애플리케이션은 프락시 연쇄에서 프로토콜 능력과 변환이 있었는지를 알아챌 수 있다.

Server 헤더와 Via 헤더

• Server 응답 헤더 필드는 원서버에 의해 사용되는 소프트웨어를 알려준다.
  • Server: Apache/l.3.14 (Unix) PHP/4. Ø. 4
  • Server: Netscape-Enterprise/4.1
  • Server: Microsoft-IIS/5. Ø
• 응답 메시지가 프락시를 통과할 때 프락시는 Server 헤더를 수정해서는 안 된다.
• 프락시는 Via 항목을 추가해야 한다.

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

• 프락시 서버가 네트워크 방화벽의 일부인 경우 프락시는 방화벽 뒤에 숨어있는 호스트의 이름과 포트를 전달해서는 안 된다.
• Via 노드 이름 전달이 가능하지 않다면, 보안 경계선의 일부분인 프락시는 호스트 명을 그 호스트에 대한 적당한 가명으로 교체해야 한다.

 

2. TRACE 메서드

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

Max-Forwards

• 요청의 프락시 홉(hop) 개수를 제한하기 위해 사용
• 전달되는 메시지가 무한 루프에 빠지지 않는지 프락시 연쇄를 테스트하거나 연쇄 중간의 특정 프락시 서버들의 효과를 체크할 때 유용
• Max-Forwards 요청 헤더 필드는 이 요청 메시지가 몇 번 더 다음 흡으로 전달될 수 있는지 말해주는 정수 하나를 담고 있다.

 

 

7. 프락시 인증

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

 

 

8. 프락시 상호운용성

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

• 프락시는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 한다.
• 같은 이름의 헤더 필드가 여러 개 있는 경우에는 그들의 상대적인 순서도 반드시 유지해야 한다.
• 프락시가 어떤 메서드 와 친숙하지 않다면, 가능한 한 그 메시지를 다음 흡으로 전달하려 시도해야 한다.

 

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

• HTIP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지 클라이언트가 알아볼 수 있게 해 준다.
• 서로 다른 기능 수준의 서버와 프락시가 더 쉽게 상호작용할 수 있도록 클라이언트는 OPTIONS를 이용해 서버의 능력을 먼저 알아낼 수 있다.

 

3. Allow 헤더

• 요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드(요청 URI가 *인 경우)를 열거한다
• Allow 헤더는 새 리소스가 지원했으면 하는 메서드를 추천하기 위해 요청 헤더로 사용될 수 있다.
  => 서버는 추천받은 메서드를 모두 자원해야 할 의무는 없으며, 그 요청에 대한 응답에는 실제로 지원하는 메서드들을 열거하는 Allow 헤더를 포함시켜야 한다.