6장 프락시

웹 중개자

프락시 서버는 클라이언트 입장에서 트랜잭션을 수행하는 중개인이다.
클라이언트와 서버가 직접 통신하는 대신에 프락시 서버가 그들 사이에 위치하여 통신을 중개한다.
따라서 프락시 서버는 웹 서버이기도하고 웹 클라이언트이기도 하다.

개인 프락시와 공유 프락시

개인 프락시
하나의 클라이언트만을 위한 프락시를 개인 프락시라고한다.
공용 프락시
여러 클라이언트를 위한 프락시를 공용 프락시라고 한다.

프락시 대 게이트웨이

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

게이트 웨이의 대표적인 예시가 HTTP/POP 게이트웨이이다.
웹 트랜잭션을 적절한 POP 트랜잭션으로 변환하고, 사용자가 이메일을 HTTP를 통해 읽을 수 있게 해준다.

왜 프락시를 사용하는가?

프락시 서버는 보안을 개션하고, 성능을 높여주며, 비용을 절약한다.
프락시 서버는 모든 HTTP 트래픽을 들여다보고 건드릴 수 있기에, 부가적인 가치를 주는 여러 유용한 웹 서비스를 구현하기 위해 트래픽을 감시하고 수정할 수 있다.

어린이 필터
어린이 필터는 웹 트래픽을 감시하고, 웹 페이지를 분석하여 어린이가 볼 수 없는 웹 페이지를 차단한다.

문서 접근 제어자
프락시 서버가 웹 서버들과 리소스에 대한 접근 제어 전략을 구현하기 위해 사용할 수 있다.

보안 방화벽
보안을 강화하여 웹 서버를 보호하기 위해 사용할 수 있다.
조직 안으로 들어오거나 나가는 모든 HTTP 트래픽을 프락시 서버를 통해 통과하도록 하여, 조직 안의 모든 HTTP 트래픽을 감시하고 네트워크의 한 지점에서 제어할 수 있다.

웹 캐시
프락시 서버는 자주 찾는 웹 페이지를 캐시하여 웹 서버의 응답 시간을 줄여준다.

대리 프락시 웹 서버인 것처럼 위장하여 진짜 웹 서버 요청을 받지만 실제로는 다른 서버에 요청을 전달하는 프락시 서버를 대리 프락시라고 한다.
웹 서버의 성능을 개선하기 위해 사용할 수 있다. 이를 서버 가속기라고 부른다.

콘텐츠 라우터
트래픽 조건과 콘텐츠 종류에 따라 요청을 특정 웹 서버로 유도하는 것을 콘텐츠 라우터라고 한다.
예를 들어 사용자가 비용을 지불하고 높은 성능을 제공하는 웹 서버로 연결되도록 할 수 있다.
또한 맞춤형 컨텐츠를 제공하기 위해 사용할 수 있다.

트랜스코더
콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정하는 것처럼 데이터의 표현방식을 자연스레 바꾸는 것을 트랜스코딩이라고 한다.
예를 들어 GIF를 JPEG로 변환하거나, 영어를 프랑스어로 번역하는 것이다.

익명화 프락시
HTTP 메시지를 익명으로 만들기 위해 사용할 수 있다.
익명화 프락시는 클라이언트의 IP 주소를 제거하고, 쿠키를 제거하고, 리퍼러 헤더를 제거하여 클라이언트의 신원을 숨긴다.

프락시는 어디에 있는가?

프락시 서버 배치

출구(Egress) 프락시
로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프락시를 로컬 네트워크의 출구에 배치할 수 있다.
또한 해커들을 막기 위해 로컬 네트워크의 출구에 프락시를 배치할 수 있다.
필터링 출구 프락시를 이용할 수도 있다.

접근,입구(Ingress) 프락시
ISP 접근 지점에 위치시켜 고객의 모든 요청을 종합적으로 처리할 수 있다.
ISP는 캐시프락시같은 것을 사용해 많이 찾는 문서의 사본을 저장한다.

대리 프락시
네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청할 수 있다.
웹서버에 보안 기능을 추가하거나 캐시 서버를 느린 웹 서버앞에 놓음으로 성능을 개선할 수 있다.
모든 요청이 이 프락시로 가게 된다.

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

프락시 계층

프락시들을 연쇄로 구성하면 프락시 계층이 된다.

프락시 계층 콘텐츠 라우팅

프락시는 상황에 맞게 콘텐츠를 라우팅할 수 있다.

부하 균형
자식 프락시는 부하를 분산시키기 위해 부모의 작업량에 따라 부모 프락시를 고른다.

지리적 인접성에 근거한 라우팅
자식 프락시는 지리적으로 가장 가까운 부모 프락시를 고른다.

프로토콜/타입 라우팅
자식 프락시는 URI에 근거하여 다른 부모나 원 서버로 라우팅한다.
특정 종류의 URI인 경우 특별한 프락시 서버로 보내 특별한 프로토콜로 처리한다.

유료 서비스 가입자를 위한 라우팅
자식 프락시는 유료 서비스 가입자를 위해 특별한 부모 프락시를 고른다.

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

클라이언트 트래픽이 프락시로 가도록 하는 방법 네가지

  • 클라이언트를 수정
    • 브라우저들이 수동 혹은 자동 프락시 설정을 지원하기에 클라이언트는 의도적으로 HTTP요청을 프락시로 보낼 수 있다.
  • 네트워크를 수정
    • 클라이언트도 모르게 네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 조정한다.
    • 스위칭 장치와 라우터를 사용하여 프락시로 가도록 할 수 있다. 인터셉트 프락시라고 부른다.
  • DNS 이름공간을 수정한다.
    • 서버 앞에 대리 프락시가 웹 서버의 이름과 IP주소를 자신이 직접 사용한다.
  • 웹 서버를 수정한다.
    • HTTP 리다이렉션을 클라이언트에게 보내서 클라이언트가 프락시로 가도록 한다.

클라이언트 프라시 설정

  • 수동 설정 : 프락시를 사용한다고 명시적 설정
  • 브라우저 기본 설정 : 브라우저 벤더나 배포자는 브라우저를 소비자에게 전달하기 전에 프락시를 미리 설정할 수 있다.
  • 프락시 자동 설정(Proxy Auto-Configuration, PAC) : 자동으로 프락시를 설정하는 방법
  • 웹 프락시 자동 발견(Web Proxy Auto-Discovery, WPAD) : 자동으로 프락시를 설정하는 방법

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

브라우저 설정에서 프록시 설정을 변경한다.
몇몇 ISP는 프락시 서버로 리다이렉트 시키는 맞춤형 운영체제를 구입한다.

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

프락시 자동설정 파일(PAC)은 자동으로 프락시를 설정하는 방법이다.
PAC 파일은 자바스크립트로 작성되며, 브라우저는 PAC 파일을 실행하여 프락시를 설정한다.
.pac 확장자를 가진다.
FindProxyForURL(url, host) 함수를 정의해야 한다.

FindProxyForURL 반환 값 설명
DIRECT 프락시를 사용하지 않는다.
PROXY host:port 지정한 프락시 서버를 사용한다.
SOCKS host:port SOCKS 프락시 서버를 사용한다. 
function FindProxyForURL(url, host) {
    if (shExpMatch(url, "http://www.example.com/*")) {
        return "PROXY proxy.example.com:8080";
    }
    if (shExpMatch(url, "http://www.example.org/*")) {
        return "PROXY proxy.example.org:8080";
    }
    return "DIRECT";
}

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

웹 프락시 자동발견 프로토콜은 여러 발견 메커니즘들의 상승 전략을 이용해 브라우저에게 알맞은 PAC파일을 자동으로 찾아주는 알고리즘이다.

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

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

서버와 프락시 메시지의 문법은 같지만 한가지 예외가 있다.

  • 클라이언트가 웹 서버로 요청보낼때 요청줄

GET /index.html HTTP/1.1
User-Agent: Mozilla/4.0

  • 클라이언트가 프락시로 요청보낼때 요청줄

GET http://www.example.com/index.html HTTP/1.1
User-Agent: Mozilla/4.0

부분 URI이냐 완전한 URI이냐 차이이다.

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

가상으로 호스팅 되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유한다.
/index.html로 요청이 오면 가상으로 호스팅되는 웹 서버는 요청이 접근하고자하는 host명을 알 필요가 있다.
이에 따라 가상으로 호스팅 되는 웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더를 요구한다.

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

클라이언트 입장에서는 대리 프락시와 인터셉트 프락시의 존재 여부를 알 수 없다.
부분 URI를 통해 보내도 대리 프락시나 인터셉트 프락시는 클라이언트 모르게 웹 서버와 대화하고 있다고 가정한다.

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

전송 중 URI 변경

URI는 프락시를 통과할 때마다 변경될 수 있다.
하지만 사소한 URI 변경이라도 다운스트림 서버와 상호 운용성에 문제를 일으킬 수 있다.
특히 인터셉트 프락시는 URI를 전달할 때 절대 경로를 고쳐 쓰는 것을 금지한다. 유일한 예외는 빈 경로를 /로 교체하는 것이다.

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

브라우저는 프락시 존재 여부에 따라 요청 URI를 다르게 분석한다.
프락시가 없다면 URI를 호스트 명과 포트로 분석한다.
호스트명이 발견되면 그에 대응하는 IP주소들을 연결될 때까지 시도한다.
호스트가 발견되지 않으면 URL확장을 시도한다.

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

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

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

명시적인 프락시가 있는 경우 브라우저는 부분 호스트 명을 자동확장하지 않는다.

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

브라우저가 자동 확장하는 것은 서버와 직접 통신하는 것과 인터셉트 프락시를 이용하는 것에 별 차이가 없으나 인터셉트 프락시를 사용하는 브라우저는 죽은 IP주소를 탐지할 수 없다.

메시지 추적

메시지 추적은 클라이언트와 서버가 프락시를 통해 어떻게 통신하는지 알아보는 것이다.

Via 헤더

Via 헤더는 메시지가 프락시를 통과할 때마다 추가된다.
다음 Via 문자열은 메시지가 두 개의 프락시를 자나갔음을 말해준다.
via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

Via 헤더는 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 모든 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다.
또한 네트워크 라우팅 루프를 탐지하기 위해 Via헤더를 사용할 수 있다.

프락시는 요청을 보내기 전에 자신의 이름을 Via 헤더에 추가한다.
네트워크에 라우팅 루프가 있는지 탐지하기 위해 이문자열이 들어온 요청에 있는지 검사해야 한다.

Via 문법

쉼표로 구분된 경유지의 목록이다.

Via = “Via” “:” ( waypoint ) [ “,” ( waypoint )… ]
waypoint = ( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name “/” ] protocol-version
received-by = ( host [ “:” port ] ) | pseudonym

  • 프로토콜 이름
  • 프로토콜 버전
  • 노드 이름
  • 노드 코멘트

Via 요청과 응답 경로

Via 헤더는 요청과 응답 모두에 사용된다.
응답 Via헤더는 요청 Via 헤더와 반대 순서로 나열된다.

Via와 게이트웨이

몇몇 프락시는 서버에게 비 HTTP 프로토콜을 전달하기 위해 게이트웨이로 동작한다.
Via 헤더는 프로토콜 변환을 기록하므로 프락시 연쇄에서 프로토콜 능력과 변환이 있었는지를 알아챌 수 있다.

Via: FTP/1.0 proxy.irens-isp.net (Traffic-Server/5.0.1-17882 [cMs f ])

선택적인 코멘트에서는 프락시 서버의 브랜드, 버전 번호, 몇가지 벤더 진단 정보를 포함한다.

Server 헤더와 Via 헤더

Server 헤더는 원 서버를 위해 존재한다.
프락시를 통과할 때 프락시는 Server 헤더를 수정해서는 안된다. 오로지 Via 헤더만 수정해야 한다.

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

Via 문자열 안에 정확한 호스트 이름을 포함시키면 프락시가 네트워크 방화벽의 일부인 경우 네트워크 방화벽의 내부 구조를 공개하게 된다.
따라서 보안 경계선 일부분인 프락시는 호스트를 적당한 가명으로 바꿔야 한다.
하지만 실제 이름을 알기 어렵게 되었다고 하더라도 Via 경유지 항목을 유지하려고 노력해야한다.
이에 따라 Via는 일련의 경유지 항목들을 하나로 합칠 수 있다.

Via: 1.0 foo, 1.1 devirus.company.com, 1.1 acess-logger.company.com
-> Via: 1.0 foo, 1.1 concealed-stuff

Trace 메서드

프락시 서버는 메시지가 전달될 때 메시지를 바꿀 수 있다.
HTTP 프락시 네트워크를 통해 전달될 때마다 메시지의 내용이 어떻게 변하는지 관찰 하기 위해 Trace 메서드를 사용할 수 있다.

Trace 메서드는 서버가 메시지를 받으면 전체 요청 메시지를 HTTP 응답 메시지의 본문에 담아서 보낸다.
Trace 응답의 Content-Type은 message/http이다. 상태는 200 OK이다.

Max-Forwards

Max-Forwards 요청 헤더는 Trace 메서드가 프락시를 통과할 때마다 감소한다.
메시지의 전달 횟수를 제한하는데 쓰인다.
Max-Forwards 헤더가 0이 되면 Trace 메시지는 더 이상 전달하지 말고 반드시 클라이언트에게 돌려줘야 한다.

프락시 인증

접근제어장치로 프락시를 이용할 수 있다.
HTTP는 사용자가 유효한 접근 권한 자격을 프락시에게 제출하지 않으면 요청을 차단하는 메커니즘을 정의한다.

  • 407 Proxy Authentication Required : 프락시가 클라이언트에게 인증을 요구한다.
  • Proxy-Authenticate : 프락시가 인증 방법을 클라이언트에게 알려준다.
  • Proxy-Authorization : 클라이언트가 프락시에게 인증 정보를 보낸다.

프락시 상호운용성

클라이언트, 서버, 프락시는 HTTP 명세의 여러 버전에 대해 여러 벤더에 의해 만들어지기 때문에 제각각 다른 버그를 가진다.
프락시 서버는 클라이언트와 서버 사이에서 중개자 역할을 하기 때문에 HTTP 상호운용성을 위해 중요한 역할을 한다.

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

프락시는 넘어오는 헤더 필드를 모두 이해하지 못할 수 있다.
프락시는 자신이 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 한다.
같은 이름의 헤더 필드가 여러 개 인 경우 순서도 반드시 유지해야한다.

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

  • 요청 OPTIONS * HTTP/1.1
  • 응답 Allow: GET, HEAD, PUT, OPTIONS

서버의 능력에 대해 클라이언트가 먼저 알아 낼 수 있다.

Allow 헤더

Allow 헤더는 서버가 지원하는 메서드를 클라이언트에게 알려준다.
만약 프락시가 지정된 모든 메서드를 이해할 수 없다고 해도 프락시는 ALlow 헤더를 그대로 전달해야 한다.
왜냐하면 클라이언트는 원 서버와 대화하는 다른 경로를 갖고 있을 수도 있기 때문이다.

문제

  1. 프락시 서버가 웹 서버의 성능을 개선하기 위해 어떤 역할을 할 수 있을까요?

    • 대리 프락시는 웹 서버인 것처럼 위장하여 클라이언트의 진짜 웹 서버 요청을 받지만, 실제로는 다른 서버에 요청을 전달하는 프락시 서버입니다. 대리 프락시는 웹 서버의 성능을 향상시키기 위해 사용될 수 있습니다. 특히 서버 가속기로서 동작하여 웹 서버에 대한 요청을 최적화하고 성능을 개선하는 데 사용됩니다.대리 프락시는 웹 서버인 것처럼 위장하여 클라이언트의 진짜 웹 서버 요청을 받지만, 실제로는 다른 서버에 요청을 전달하는 프락시 서버입니다. 대리 프락시는 웹 서버의 성능을 향상시키기 위해 사용될 수 있습니다. 특히 서버 가속기로서 동작하여 웹 서버에 대한 요청을 최적화하고 성능을 개선하는 데 사용됩니다.
    • 프락시 서버는 자주 찾는 웹 페이지를 캐시하여 웹 서버의 응답 시간을 줄입니다. 클라이언트가 동일한 콘텐츠를 요청할 때 프락시는 캐시에서 해당 페이지를 제공하므로 웹 서버에 새로운 요청을 보내지 않아도 됩니다. 이로써 불필요한 트래픽을 감소시키고 전반적인 성능을 향상시킵니다.

  2. Trace 메서드를 사용하여 어떻게 메시지의 내용이 관찰될 수 있을까요?

    • Trace 메서드는 서버가 메시지를 받으면 전체 요청 메시지를 HTTP 응답 메시지의 본문에 담아서 클라이언트에게 전송합니다. 이를 통해 HTTP 프락시 네트워크를 통해 전달될 때 메시지의 내용이 어떻게 변하는지를 관찰할 수 있습니다.

  3. 프락시 서버의 Via 헤더가 개인정보 보호와 보안에 미치는 영향은 무엇인가요?

    • Via 헤더에 정확한 호스트 이름을 포함하면 프락시가 네트워크 방화벽의 일부인 경우 내부 구조를 공개할 수 있습니다. 따라서 보안 경계선인 프락시는 호스트를 가명으로 바꿔야 하며, Via는 적절한 가명으로 변경되어야 합니다.
  4. 콘텐츠 라우터의 역할은 무엇이며, 어떤 상황에서 유용할까요?
    • 콘텐츠 라우터는 트래픽 조건과 콘텐츠 종류에 따라 요청을 특정 웹 서버로 유도하는 역할을 합니다. 이를 통해 사용자가 비용을 지불하고 높은 성능을 제공하는 웹 서버로 연결되도록 할 수 있습니다. 또한 맞춤형 컨텐츠를 제공하거나 특정 서버에 트래픽을 집중시키는 데 사용될 수 있습니다.

  5. 익명화 프락시는 어떤 목적으로 사용되며, 어떻게 클라이언트의 신원을 숨깁니까?

    • 익명화 프락시는 HTTP 메시지를 익명으로 만들기 위해 사용됩니다. 익명화 프락시는 클라이언트의 IP 주소를 제거하고, 쿠키를 제거하고, 리퍼러 헤더를 제거하여 클라이언트의 신원을 숨깁니다.

results matching ""

    No results matching ""