[HTTP 완벽 가이드] 6장 : 프락시

이 장에서 다룰 내용

• HTTP 프락시와 웹 게이트웨이 비교
• 프락시가 실제 네트워크에 어떻게 배치되어 있는지
• 트래픽이 어떻게 프락시 서버로 가게 되는지
• 브라우저에서 프락시를 사용하려면 어떻게 설정해야 하는지
• HTTP 프락시 요청이 서버 요청과 어떻게 다른지
• 메시지의 경로를 Via 헤더와 TRACE 메서드를 이용해 기록하는 방법
• 프락시에 기반한 HTTP 접근 제어

1 웹 중개자

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

프락시는 서버이면서 동시에 클라이언트 입장을 수행한다

 

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

공용 프락시

• 여러 클라이언트가 함께 사용하는 프락시
• 대부분의 프락시에서 사용한다

개인 프락시

• 하나의 클라이언트만을 위한 프락시
• 흔하진 않지만 클라이언트 컴퓨터에서 직접 실행되는 형태로 사용된다

 

1.2 프락시 대 게이트웨이

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

 

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

프락시는 트래픽을 감시하고 수정할 수 있다

 

어린이 필터

• 어린이를 보호하기 위한 필터링 프락시

  • 초등학교 어린이들에게 교육 사이트를 제공하면서 동시에 성인 콘텐츠를 차단

문서 접근 제어자

• 중앙화된 문서 접근 제어

  • 클라이언트1은 제약 없이 서버의 뉴스 페이지에 접근 가능하나, 클라이언트 2는 서버B에 접근하기 전에 비밀번호를 입력해야한다

• 대기업 환경이나 분산된 관료 조직에서 유용

보안 방화벽

• 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제
• 트래픽을 세심히 살펴볼 수 있는 후크를 제공

웹 캐시

• 인기 있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공

대리 프락시

• 리버스 프락시, 서버 가속기라고 불린다
• 웹서버 요청을 받지만 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 알아내기 위해 다른 서버와 커뮤니케이션을 시작

콘텐츠 라우터

• 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도

  • 사용자가 필터링 서비스에 가입했다면 요청이 필터링 프락시를 통과하도록 구성

트랜스코더

• 프락시 서버는 콘텐츠를 클라이언트에게 전달하기전에 본문 포맷을 수정할 수 있다

  • 스페인어를 이용하는 사용자에게 한국어 문서를 스페인어로 변환한다

  • 핸드폰의 작은 화면에서도 볼 수 있도록 단순한 텍스트로 변환한다

익명화 프락시

• 익명화된 메시지는 공통 식별 정보 헤더를 포함하지 않는다

---

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

3.1 프락시 서버 배치

출구(Egress) 프락시

• 로컬 네트워크의 출구에 위치
• 회사 밖의 악의적인 해커들을 막는 방화벽 제공
• 인터넷 요금을 절약하고 인터넷 트래픽의 성능을 개선
• 부적절한 콘텐츠를 브라우징하는 것을 막기 위해

접근(입구) 프락시

• ISP 접근 지점에 위치
• 사용자들의 다운로드 속도 개선
• 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용

대리 프락시

• 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치
• 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원 요청
• 웹 서버의 이름과 IP주소로 스스로를 가장하기 때문에 모든 요청은 프락시로 감

네트워크 교환 프락시

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

 

3.2 프락시 계층

• 프락시는 프락시 계층이라고 불리는 연쇄를 구성할 수 있다
• 프락시 서버는 여러 가지 판단 근거에 의해 메시지를 다양하고 유동적은 프락시 서버와 원 서버들의 집합에게 보낼 수 있다
• 동적 부모 선택의 예 :

 

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

클라이언트를 수정한다

• 웹 클라이언트(ex.구글 크롬)는 수동 혹은 자동으로 프락시 설정을 지원한다
• 클라이언트가 프락시를 사용하도록 설정되어 있다면, 클라이언트는 HTTP요청을 바로 프락시로 보낸다

네트워크를 수정한다

• 클라이언트는 모르는 상태에서 네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 조정한다
• 스위칭 장치와 라우팅 장치를 필요로 한다
• 인터셉트 프락시, 투명 프락시라고 부른다

DNS 이름공간을 수정한다

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

웹 서버를 수정한다

• HTTP 리다이렉션 명령을 클라이언트에 돌려주면, 클라이언트의 요청을 프락시로 리다이렉트 하도록 설정한다

---

4 클라이언트 프락시 설정

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

• 구글 크롬에서는 설정 > 고급 설정 표시 > 프록시 설정 변경... 에서 프록시를 설정할 수 있다
• 다른 브라우저 역시 방법은 다르지만 아이디어는 같다.

 

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

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

 

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

• 자동발견 프로토콜 WPAD는 브라우저에게 알맞은 PAC파일을 자동으로 찾아주는 알고리즘
• PAC URI를 찾기 위해 WPAD를 사용한다
• 주어진 URI에서 PAC파일을 가져온다
• 프락시 서버를 알아내기 위해 PAC파일을 실행한다
• 알아낸 프락시 서버를 이용해서 요청을 처리한다

 

---

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

5.1 프락시 URI는 서버 URI와 다르다

• 클라이언트가 프락시를 사용하지 않도록 설정되어 있다면, 부분 URI를 보낸다
• 클라이언트가 프락시를 사용하도록 설정되어 있다면, 완전한 URI를 보낸다

 

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

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

 

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

• 대리 프락시는 원 서버의 호스트 명과 아이피 주소를 사용해 원 서버를 대신하는 프록시 서버다
• 인터셉트 프락시는 네트워크의 흐름에서 클라이언트에서 서버로 가는 트래픽을 가로채 캐시된 응답을 돌려주는 등의 일을 하는 프락시 서버다. 인터셉트 프락시는 클라이언트에서 서버로 가는 트래픽을 가로채기 때문에, 웹 서버로 보내는 부분 URI를 얻게 될 것이다

 

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

• 트래픽이 프락시 서버로 리다이렉트 될 수 있는 여러 가지 방법이 존재하기 때문에, 다목적 프락시 서버는 요청 메시지의 완전한 URI와 부분 URI를 모두 지원해야 한다

 

5.5 전송 중 URI 변경

• 프락시 서버는 요청 URI의 변경에 매우 신경을 써야 한다. 무해해 보이는 사소한 URI변경이라도 다운스트림 서버와 상호운용성 문제를 일으킬 수 있다

 

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

• 호스트명이 발견되지 않으면, 많은 브라우저들은 사용자가 호스트 명의 짧은 약어를 타이핑한 것으로보고 자동화된 호스트명의 '확장'을 제공하고자 몇가지 시도를 한다

 

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

• 브라우저는 명시적은 프락시가 존재하지 않는 경우 부분 호스트 명을 자동으로 확장한다

 

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

• 명시적인 프락시를 사용한다면, 브라우저는 편리한 확장들 중 어느 것도 더이상 수행할 수 없다

 

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

• 인터셉트 프락시를 사용하고 있는 브라우저는 죽은 서버의 IP 주소를 탐지할 수 있다

---

6 메시지 추적

프락시는 여러 벤더에 의해 개발된다.

서로 다른 스위치와 라우터를 넘나드는 IP패킷의 흐름을 추적하는 것 못지않게 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다

 

6.1 Via 헤더

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

• via 헤더 필드는 메시지가 지나는 각 중간 노드(프락시나 게이트웨이)의 정보를 나열한다. 메시지가 또 다른 노드를 지날 때마다, 중간 노드는 Via 목록의 끝에 반드시 추가되어야 한다.
• 다음의 Via 문자열은 메시지가 두 개의 프락시를 지나갔음을 말해준다. 이 문자열에 따르면 첫 번째 프락시는 HTTP/1.1 프로토콜을 구현했으며 proxy-62.irenes-isp.net라 불리고, 두 번째 프락시는 HTTP/1.0을 구현했고 cache.joes-hardware.com로 불린다.
• Via헤더 필드는 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다

Via 문법

• 프로토콜 이름 : 중개자가 받은 프로토콜. 만약 프로토콜이 HTTP라면 프로토콜 이름은 없어도 된다
• 프로토콜 버전 : 수신한 메시지의 버전. 버전의 포맷은 프로토콜에 달려있다
• 노드 이름 : 중개자의 호스트와 포트 번호
• 노드 코멘트 : 중가재 노드를 서술하는 선택적인 코멘트

Via요청과 응답 경로

• 응답 Via는 보통 요청 Via의 반대다

Via와 게이트웨이

• HTTP/FTP 게이트웨이는 받은 프로토콜에 대한 로그를 남기면서 Via헤더를 생성한다

Server헤더와 Via헤더

• 응답 메시지가 프락시를 통과할 때, 프락시는 Server 헤더를 수정해서는 안 된다
• 서버 응답 헤더 필드는 원 서버에 의해 사용되는 소프트웨어를 알려준다

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

• 여러 경유지들이 모두 같은 조직의 통제하에 있고, 호스트가 이미 가명으로 교체되지 않은 이상 그들에 대한 항목을 합쳐서는 안 된다

6.2 TRACE 메서드

Max-Forwards

• 전달되는 메시지가 무한 루프에 빠지지 않는지 프락시 연쇄를 테스트하거나 연쇄 중간의 특정 프락시가 무한 루프에 빠지지 않는지 프락시 연쇄를 테스트하거나 연쇄 중간의 특정 프락시 서버들의 효과를 체크할 떄 유용하다
• OPTIONS메시지의 전달 횟수도 제한한다

---

7 프락시 인증

프락시는 콘텐츠에 대한 접근을 통제하기 위해 인증을 구현할 수 있다

 

8 프락시 상호운용성

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

한 메시지에 같은 필드 이름을 가진 메시지 헤더 필드가 여러 개 존재할 수 있지만, 이들은 쉼표로 구분된 목록으로 동등하게 결합될 수 있어야 한다. 결합 후에도 정보의 손실이 없어야 한다. 이 결합된 필드 값들을 해석할 때 같은 이름을 가진 헤더 필드들의 순서가 영향을 미치기 때문에 프락시는 메시지를 전달할 때 같은 이름의 필드 값들의 상대적은 순서를 바꿀 수 없다

 

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

• HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지(예를 들면 지원하는 메서드) 클라이언트(혹은 프락시)가 알아볼수 있게 해준다.
• OPTIONS 요청의 URI가 다움과 같이 별표(*)라면, 요청은 서버 전체의 능력에 대해 묻는 것이 된다
• URI가 실제 리소스라면, OPTIONS 요청은 특정 리소스에 대해 가능한 기능들을 묻는 것이다.

 

8.3 Allow 헤더

• Allow 엔터티 헤더 필드는, 요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다
• 새 리소스가 지원했으면 하는 메서드를 추천하기 위해 요청 헤더로 사용될 수 있다.
• 서버에서는 추천 받은 메서드를 모두 지원해야 할 의무는 없다
• 프락시가 지정된 모든 메서드를 이해할 수 없다고 해도, 프락시는 Allow헤더 필드를 수정 할 수 없다.

---

출처 : 데이빗 골리 외 4인, HTTP 완벽 가이드 :웹은 어떻게 동작하는가, 이응준 , 정상일 옮김, 인사이트, 2014