6장 프락시
6.1 웹 중개자
- 웹 프락시 서버는 클라이언트 입장에서 트랜잭션을 수행하는 중개인이다.
- 프락시는 클라이언트의 요청을 받게 되므로, 웹 서버처럼 요청과 커넥션을 적절히 다루고 응답을 돌려줘야 한다.
- 프락시는 요청을 서버로 보내기도 하므로, 요청을 보내고 응답을 받는 HTTP 클라이언트 처럼 동작해야 한다.
6.1.1. 개인프락시와 공유 프락시
공용 프락시
- 중앙 집중형 프락시를 관리하는 게 비용효율이 높고 쉽다. 여러 사용자들에게 공통된 요청에서 이득을 취하기 쉬우므로, 캐시 프락시 서버와 같은 프락시 서버는 사용자가 많을수록 효율이 좋다.
개인 프락시
- 하나의 클라이언트만을 위하므로 개인 전용 프락시는 흔하지 않다.
6.1.2 프락시 대 게이트웨이
프락시
- 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결한다.
- 클라이언트와 서버 양쪽 모두에게 HTTP로 통신한다.
게이트웨이
- 서로 다른 프로토콜을 사용한는 둘 이상의 애플리케이션을 연결한다.
- 클라이언트와는 HTTP로 서버와는 POP으로 서로 다른 프로토콜로 말하더라도 서로 간의 트랜잭션을 완료하도록 한다.
6.2 왜 프락시를 사용하는가?
보안을 개선하고, 성능을 높여주며, 비용을 절약한다.
모든 HTTP 트래픽을 보고 건드릴 수 있기 때문에, 유용한 웹 서비스를 구현하기 위해 트래픽을 감시하고 수정한다.
ex)
- 교육 콘텐츠에는 제한 없는 접근을 허용하면서 어린이에게 부적절한 사이트의 접근을 강제로 거부한다.
- 대기업이나 분산된 조직에서 관리되는 다양한 종류의 수많은 웹 서버들에 대한 접근 제어를 수시로 갱신 할 필요 없이, 중앙 프락시 서버에서 접근 제어를 설정할 수 있다.
- 바이러스를 제거하는 웹이나 이메일 프락시가 사용할 수 있는 트래픽을 세심하게 살펴볼 수 있는 훅을 제공한다.
- 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작할 수 있다.
6.3 프락시는 어디에 있는가?
6.3.1 프락시 서버 배치
출구 프락시
- 로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프락시를 로컬 네트워크의 출구에 넣을 수 있다.
접근(입구) 프락시
- 고객으로 부터의 모든 요청을 종합적으로 처리하기 위해 프락시는 ISP 접근 지점에 위치한다.
대리 프락시
- 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요 할 때만 웹 서버에게 자원을 요청할 수 있다.
네트워크 교환 프락시
- 캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시한다.
6.3.2 프락시 계층
- 프락시들이 연쇄적으로 구성되어있다.
- 프락시 서버들은 부모와 자식의 관계를 갖는다.
- 각각의 프락시 서버들의 여러가지 판단 근거에 의해 메시지를 다양하고 유동적으로 전송한다.
6.3.3 어떻게 프락시가 트래픽을 처리하는가
클라이언트 트래픽이 프락시로 가도록 만드는 방법이 네 가지 존재한다.
클라이언트를 수정한다
- 대부분의 브라우저들은 수동 또는 자동 프락시 설정을 지원한다. 클라이언트는 HTTP 요청을 프락시로 보낸다.
네트워크를 수정한다
- HTTP 트래픽을 지켜보고 가로채어 클라이언트 모르게 트래픽을 프락시로 보낸다.(인터셉트 프락시)
DNS 이름공간을 수정한다
- 웹 서버 앞에 위치하는 대리 프락시 서버는 웹 서버의 이름과 IP주소를 자신이 직접 사용한다.
웹 서버를 수정한다
- HTTP 리다이렉션 명령을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트 하도록 설장할 수 있다.
6.4 클라이언트 프락시 설정
많은 브라우저가 프락시를 설정하는 여러가지 방법을 제공한다.
- 각 브라우저의 설정 메뉴에서 프락시 사용에 대한 설정을 할 수 있다.
- PAC파일을 사용하면 프락시 설정을 상황에 맞게 자바스크립트 함수가 계산해서 적절한 프락시 서버를 선택한다.
- WPAD는 브라우저에게 알맞은 PAC 파일을 자동으로 찾아준다.
6.5 프락시 요청의 미묘한 특징들
6.5.1 프락시 URI는 서버 URI와 다르다
6.5.2 가상 호스팅에서 일어나는 같은 문제
스킴/호스트/포트번호 누락문제는 가상으로 호스팅 되는 웹 서버의 문제와 같은 문제다.
6.5.3 인터셉트 프락시는 부분 URI를 받는다
6.5.4 프락시는 프락시 요청과 서버 요청을 모두 다룰 수 있다
- 트래픽이 프락시 서버로 리다이렉트 될 수 잇는 여러가지 방법이 존재하기 때문에 다목적 프락시 서버는 요청 메시지의 와전한 URI와 부분 URI 모두 지원해야한다.
- 완전한 URI가 주어졌다면, 그것을 사용한다.
- 부분 URI 주어졌고 Host 헤더가 있다면, Host 헤더를 이용해 원 서버의 이름과 포트번호를 알아야한다.
- 부분 URI가 주어졌으나 Host 헤더가 없다면, 원 서버를 알아내야 한다.
6.5.5 전송 중 URI 변경
6.5.6 URI 클라이언트 자동확장과 호스트 명 분석
6.5.7 프락시 없는 URI 분석
6.5.8 명시적인 프락시를 사용할 때의 URI 분석
6.5.9 인터셉트 프락시를 이용한 URI 분석
6.6 메시지 추적
- 웹 요청시에 클라이언트에 서버로 향하는 도중에 둘 이상의 프락시를 거치는 것은 흔해졌다.
- 프락시가 흔해지면서, 서로 다른 스위치와 라우터를 넘나드는 IP 패킷의 흐름을 추적하는것 못지않게 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것이 중요하다.
6.6.1 Via 헤더
- 메시지가 지나는 각 중간 노드의 정보를 나열한다.
6.7 프락시 인증
- 프락시는 접근 제어 장치로서 제공될 수 있다.
- HTTP는 사용자가 유효한 접근 권한 자격을 프락시에 제출하지 않는 한 콘텐츠에 대한 요청을 차단하는 프락시 인증을 제공한다.
6.8 프락시 상호운용성
- 클라이언트, 서버, 프락시는 여러 버전으로 여러 벤더 회사에 의해 만들어진다.
- 제각각의 버그들이 생기므로 프락시 서버는 클라이언트와 서버를 중개해야 한다.
6.8.1 지원하지 않는 헤더와 메서드 다루기
- 프락시 서버는 넘어오는 헤더 필드들을 모두 이해하지 못할 수 있다.
- 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러개 있는 경우에는 그들의 상대적인 순서도 반드시 유지해야한다.
6.8.2 Options: 어떤 기능을 지원하는지 알아보기
HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지 알아볼 수 있게 해준다.
요청의 URI가 별표(*)라면, 요청은 서버 전체의 능력에 대해 묻는 것이 된다.
OPTIONS * HTTP/1.1URI가 실제 리소스라면, 특정 리소스에 대해 가능한 기능들을 묻는 것이다.
OPTIONS [http://bebiangel.github.io](http://bebiangel.github.io/index.html) HTTP/1.1static HTML file wouldn't accept a POST method.
6.8.3 Allow 헤더
요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다.
Allow: GET, HEAD, PUT클라이언트는 원 서버와 대화하는 다른 경로를 갖고 있을 수 있기 때문에, 프락시는 Allow 헤더 필드를 수정할 수 없다.