Proxy

웹 중재자

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

개인 프록시와 공유 프록시

개인 프록시

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

공유 프록시

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

프록시 대 게이트 웨이

프록시

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

게이트웨이

• 서로 다른 프로토콜을 사용하는 둘 이상을 연결

프록시의 사용 목적

• 트래픽을 감시, 수정

어린이 필터

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

문서 접근 제어자

• 중앙화된 접근 제어

보안 방화벽

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

웹 캐시

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

대리 프록시

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

콘텐츠 라우터

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

트랜스코더

• 프록시 서버는 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있다.
• 핸드폰의 작은 화면에서도 볼 수 있도록 단순한 텍스트로 변환

익명화 프록시

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

프록시의 위치

프록시 서버 배치

출구 프록시 (Egress proxy)

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

접근 프록시

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

대리 프록시

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

네트워크 겨환 프록시

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

프록시 계층

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

프록시의 트래픽 처리 원리

클라이언트를 수정

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

네트워크를 수정

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

DNS 이름 공간을 수정

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

웹 서버를 수정

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

클라이언트 프록시 설정

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

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

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

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

클라이언트 프록시 설정: WPAD

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

프록시 요청의 미묘한 특징들

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

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

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

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

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

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

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

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

전송 중 URI 변경

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

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

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

프록시 없는 URI 분석

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

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

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

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

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

메시지 추적

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

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가 개인정보 보호와 보안에 미치는 영향

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

TRACE 메서드

• 프록시 서버는 메시지가 전달될 때 메시지를 바꿀 수 있다.
• 프록시 벤더들도 무수히 많아서, http 프록시 네트워크를 통해 hop by hop으로 전달될때마다 메시지의 내용이 어떻게 변하는지 편리하게 관찰할 방법이 필요하다.

프록시 인증

• 프록시는 접근 제어 장치로서 제공될 수 있다.
• 그러기 위해서 어떤 컨텐츠에 대한 요청을 차단하는 프록시 인증 매커니즘을 정의하고 있다.

프록시 상호운용성

• 클라이언트/서버/프록시는 http 명세의 여러버전에 대해서 여러 벤더에 의해 만들어진다.
• 프록시 서버는 서로 다른 프로토콜을 구현했을 수도 있고 골치아프게 이상한 동작을 할 수도 있는 클라이언트과 서버 사이를 중개해야한다.

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

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

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

• 클라이언트는 OPTIONS를 이용해서 서버의 능력을 먼저 알아낼 수 있다.
• 요청에 성공한다면 OPTIONS 메서드는 서버에서 지원하거나 지정한 리소스에 대해서
  가능한 선택적인 기능들을 서술하는 여러 헤더 필드를 포함한 200응답을 반환한다.
• 어떤 메서드가 지원되는지 서술하는 Allow 헤더하나뿐이다. 

Allow 헤더

• Allow 헤더는 요청 URI에 의해 식별되는 자원에 대해서 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다.