6장 프락시

6.1 웹 중개자

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

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

개인 프락시

• 대부분의 프락시는 공유된 프락시이다.
• 중앙 집중형 프락시를 관리하는 게 더 비용효율이 높고 쉽다

개인 프락시

• 흔하진 않지만 꾸준히 사용된다.
• 브라우저 기능을 확장하거나 성능 개선하거나 등 컴퓨터에서 직접 실행한다.

6.1.2 프락시 대 게이트웨이

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

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

• 프락시는 보안을 개선하고, 성능을 높여주며, 비용을 절약한다.

  어린이 필터

• 부적절한 사이트의 접근을 강제로 거부할 수 있다.

  문서 접근 제어자

• 각기 다른 조직에서 관리되는 다양한 종류의 수많은 웹 서버들에 대한 접근 제어를 중앙 프락시 서버에서 설정할 수 있다.

  보안 방화벽

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

  웹 캐시

• 프락시 캐시는 인기 있는 문서의 로컬 사본을 관리하고, 문서에 대한 요청이 오면 빠르게 제공하여 커뮤니케이션을 줄인다.

  대리 프락시(Surrogate)

• 진짜 웹 서버 요청을 받지만 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 한다.
• 콘텐츠 라우팅 기능과 결합되어 분산 네트워크를 만들기 위해 사용될 수도 있다.

  콘텐츠 라우터

• 콘텐츠 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작할 수 있다.

  트랜스 코더

• 콘텐츠를 클라이언트에게 전달하기 위해 본문 포맷을 수정할 수 있다.

  익명화 프락시

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

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

6.3.1 프락시 서버 배치

출구(Egress) 프락시

• 로컬네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해서 프락시를 로컬 네트워크의 출구에 박아 넣을 수 있다.

  접근(입구) 프락시

• ISP 접근 지점에 위치하여 사용자들의 다운로드 속도를 개선한다.
• ISP 지점은 인터넷 서비스 제공자(ISP)의 네트워크와 다른 네트워크가 연결되는 지점

  대리 프락시

• 네트워크 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여, 웹 서버로 향하는 모든 요청을 처리한다.

  네트워크 교환 프락시

• 캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시하기 위해, 네트워크 사이의 인터넷 피어링 교환 지점들에 놓일 수 있다.

6.3.2 프락시 계층

• 프락시 계층에서 프락시 서버들은 부모와 자식관계를 갖는다.
• 서버에 가까운 쪽(인바운드 프락시)를 부모라고 부르고, 클라이언트에 가까운 쪽(아웃바운드 프락시)를 자식이라고 부른다.

  프락시 계층 콘텐츠 라우팅

• 프락시 서버는 여러 가지 판단 근거에 의해 메시지를 다양하고 유동적인 프락시 서버와 원 서버들의 집합에게 보낼 수 있다.
• 부하 균형: 작업량 수준에 근거하여 부모를 고른다.
• 지리적 인접성에 근거한 라우팅: 원 서버의 지역을 담당하는 부모를 선택할 수 있다.
• 프로토콜/타입 라우팅: URI에 근거하여 다른 부모나 원 서버로 라우팅 할 수 있다.
• 유료 서비스 가입자를 위한 라우팅: 웹 서비스 운영자가 빠른 서비스를 위해 추가금을 지불했다면, 압축 엔진으로 라우팅 될 수 있다.

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

클라이언트를 수정한다.

• 많은 웹 클라이언트들은 수동 혹은 자동 프락시 설정을 지원한다.

  네트워크를 수정한다.

• 네트워크 인프라를 스위칭/라우팅 장치로 가로채어 클라이언트 모르게 트래픽을 보낸다.

  DNS 이름 공간을 수정한다.

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

  웹 서버를 수정한다.

• 몇몇 웹 서버는 HTTP 리다이렉션 명령(305 코드)을 클라이언트에게 돌려줘서 프락시로 리다이렉트 하도록 설정할 수 있다.

6.4 클라이언트 프락시 설정

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

• 브라우저에서 프락시의 호스트와 포트를 지정한다.
• 단 하나의 프락시 서버만 지정할 수 있고, 장애 시 대체 작동에 대한 지원이 없다.

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

• 프락시 자동 설정 파일은 프락시 설정에 대한 보다 동적인 해결책이다.
• 프락시 설정을 그때그때 상황에 맞게 계산해주는 작은 자바스크립트 프로그램이다.
• PAC 파일을 사요하려면, 자바스크립트의 PAC 파일의 URI를 브라우저에 설정해줘야 한다.

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

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

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

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

• 클라이언트가 웹 서버로 요청을 보낼 때, 요청줄은 스킴, 호스트, 포트번호가 없는 부분 URI를 가진다

  GET /index.html HTTP/1.0
  User-Agent: SuperBrowserv1.3

• 클라이언트가 프락시로 요청을 보낼땐 완전 URI를 갖는다.

  GET http://www.marys-antiques.com/index.html HTTP/1.0
  User-Agent: SuperBrowser v1.3

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

• 프락시의 '스킴/호스트/포트번호 누락' 문제는 가상으로 호스팅 되는 웹 서버가 직면한 것과 같은 문제다.
• 명시적인 프락시는 완전한 URI를 갖도록 하여서 문제를 해결하였다.
• 가상으로 호스팅 되는 웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더를 요구한다.

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

• 대리 프락시는 원 서버를 대신하는 프락시다.
• 인ㅌ셉트 프락시는 네트워크 흐름에서 클라이언트에서 서버로 가는 트래픽을 가로채 캐시된 응답을 돌려주는 등의 일을 하는 프락시 서버다.

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

• 다목적 프락시
• 완전 URI가 주어지면 그대로 사용한다.
• 부분 URI 가 주어지고, Host 헤더가 있다면 이를 이용해 서버 이름과 포트 번호를 알아낸다.
• 부분 URI 가 주어지고, Host 헤더가 없다면 원 서버를 알아내야 한다.
  • 대리 프락시이면 프락시에 실제 서버 주소/포트 번호가 설정되어 있을 수 있다.
  • 인터셉트 프락시가 가로챘던 트래픽을 받았고, 인터셉트 프록시가 원 IP 주소와 포트번호를 사용할 수 있도록 했다면 그 IP주소와 포트 번호를 사용한다.
  • 모두 실패하면 에러 메시지를 반환한다.

6.5.5 전송 중 URI 변경

• 요청 URI의 변경에 매우 신경을 써야 한다.
• 일반적으로 프락시는 가능한 관대하도록 애쓰고, 상호 운용성에 문제가 생길 수 있으므로 주의해야한다.

6.5.6 URI 클라이언트 자동확장과 호스트명 분석

• 프락시의 존재 여부에 따라 요청 URI를 다르게 분석한다.
• 프락시가 없으면 사용자가 타이핑한 URI 를 가지고 그에 대응하는 IP 주소를 찾는다.
• 호스트가 발견되지 않으면 확장 기능을 통해 호스트를 발견하려고 노력한다.

6.5.7 프락시 없는 URI 분석

• 입력 키워드에 스킴 http://, 포트 80, 경로 '/'로 간주하여 URI 를 분석한다.

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

• 명시적인 프락시를 사용하면 브라우저는 확장 기능을 사용할 수 없다.
• 브라우저에 키워드를 입력하면 기본 스킴과 경로를 추가하지만 호스트명은 그대로 남겨둔다.

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

• 클라이언트 입장에서 인터셉트 프락시는 존재하지 않는 것이기 때문에, 명시적 프락시와 다르게 행동한다.
• DNS가 성공할 때까지 호스트 명을 자동확장하는 브라우저를 사용할 때, 동작은 프락시가 아닌 서버와 차이가 없다.
• 그러나 서버 커넥션이 만들어진 이후, 프락시가 일부 죽은 서버를 제외와 연결이 맺어졌을 때, 프락시는 호스트 헤더에 호스트 명을 다시 분석하든, IP 주소에 대한 역방향 DNS 룩업을 해서든 다른 IP 주소를 시도해야 한다.

6.6 메시지 추적

6.6.1 Via 헤더

• 메시지가 지나는 각 중간 노드의 정보를 나열한다.
• Via 헤더 필드는 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 응답하는 과정에서 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다.

Via 문법

• 쉼표로 구분된 경유지의 목록이다.
• Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

  Server 헤더와 Via 헤더

• Server 응답 헤더 필드는 원 서버에 의해 사용되는 소프트웨어를 알려준다.
• Server 헤더를 수정해서는 안된다.

6.6.2 TRACE 메서드

• 프락시 네트워크를 쉽게 진단하기 위해 TRACE 메서드를 사용해 흐름을 디버깅할 수 있다.

  Max-Forwards

• TRACE와 OPTIONS 요청의 프락시 홉 갯수를 제한하기 위해 사용한다.
• 프락시 연쇄 테스트를 하거나 연쇄 중간의 특정 프락시 서버들의 효과를 체크할 때 유용하다.

6.7 프락시 인증

• 407 Proxy Authorization Required 상태 코드를 클라이언트가 응답으로 받으면, 사용자는 요구되는 자격을 수집한다.
• 자격을 획득하면, Proxy-Authorization 헤더 필드에 담아서 요청을 보낸다.

6.8 프락시 상호운용성

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

• 프락시는 모든 헤더 필드를 이해하지 못할 수도 있다. 그러나 반드시 그대로 전달해야 하며, 상대적인 순서도 유지해야 한다.

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

• 서로 다른 기능 수준의 서버와 프락시가 더 쉽게 상호작용할 수 있도록 클라이언트는 OPTIONS 로 서버 능력을 알아낼 수 있다.

  6.8.3 Allow 헤더

• 요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다.
• Allow 헤더는 새 리소스가 지원했으면 하는 메서드를 추천하기 위해 요청헤더로 사용될 수 있다.