01_Web02. HTTP

프록시

프록시

, ,
목차

1. 프록시란?

  • 웹 프록시 서버는 클라의 입장에서 트랜젝션을 수행하는 중개인이다.
    1. HTTP 프록시 서버는 웹 서버이기도 하고, 웹 클라이기도 하다.

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

개인 프록시

  • 하나의 클라만을 위한 프록시
  • 어떤 브라우저 보조 제품들은 몇몇 ISP 서비스와 마찬가지로 브라우저의 기능을 확장하거나 성능을 개선하거나, 무료 ISP 서비스를 위한 공고들을 운영하기 위해 작은 프록시를 사용자의 컴퓨터에서 직접 실행한다.

    ISP: Internet Service Provider (KT, SKT, LG+)

공유 프록시

  • 여러 클라가 함께 사용하는 프록시
  • 대부부의 프록시는 공유 프록시다.

1.2 Proxy vs Gateway

  • 프록시: 같은 프로토콜을 사용하는 둘 이상의 앱을 연결
  • 게이트웨이: 서로 다른 프로토콜을 사용하는 둘 이상을 연결
    프로토콜 변환기처럼 동작한다.
    • ex) HTTP/POP 게이트웨이: 이메일 서버와의 통신

2. 왜 사용할까?

  • 보안을 개선하고
  • 성능을 높여주며
  • 비용을 절약한다.
  • 부가적인 가치를 주는 여러 유용한 웹서비스를 구현하기 위해 트래픽을 감시하고 수정한다.

2.1 주 사용 케이스

  1. 어린이 필터: 성인 콘텐츠 차단용 필터링 프락시
  2. 문서 접근 제어자: 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사추적을 하기 위해.
  3. 보안 방화벽: 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제한다.
  4. 웹 캐시: 인기 있는 문서의 로컬 사본을 관리하고, 해당 문서에 대한 요청이 오면 빠르게 제공하여, 느리고 비싼 인터넷 커뮤니케이션을 줄인다.
  5. 대리 프락시(Surrogate)
  • 웹 서버인 것처럼 위장한다.
  • 공용 콘텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용될 수 있다.

    서버 가속기라고 불린다.

  • 콘텐츠 라우팅 기능과 결합되어, 주문형 복제 콘텐츠의 분산 네트워크를 만들기 위해 사용될 수 있다.
  1. 콘텐츠 라우터
  • 인터넷 트래픽 조건과 콘텐츠의 종류에 따라, 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작할 수 있다.
  • 사용자들에게 제공할 여러 서비스를 구현하는데 사용할 수 있다.

    사용자가 필터링 서비스에 가입했다면, HTTP 요청이 필터링 프락시를 통과하도록 할 수 있다.

  1. 트랜스 코드
  • 콘텐츠를 클라에게 보내기 전에, 본문 포맷을 수정할 수 있다.

    트랜스 코딩: 데이터의 표현방식을 변환하는 것

  • 사례: gif 이미지 => jpg / 이미지의 크기 줄이기 / 텍스트 파일 압축 / 외국어 문서로 변환하기 / …
  1. 익명화 프락시 Anonymizer
    1. HTTP 메세지에서 신원을 식별할 수 있는 특성들을 제거 => 개인 정보보호와 익명성 보장에 기여한다.
    • User-Agent 헤더에서 OS종류 / From헤더 / Referer헤더(출처) / Cookie(프로필과 신원정보) 등을 제거한다.

3. 어디에 둘까?

  • 어떻게 프락시가 네트워크에 배치되는가
  • 어떻게 프락시의 연쇄가 계층을 이루는가

3.1 프락시 서버 배치

  1. 출구 프락시 Egress
  • 로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프락시를 로컬 네트워크의 출구에 박아 넣을 수 있다.
  • 해킹 방지 방화벽 제공을 위해 / 인터넷 트래픽 성능 개선 / 필터링 출구 프락시
  1. 접근(입구) 프락시
  • 고객으로부터의 모든 요청을 종합적으로 처리하기 위해 ISP 접근 지점에 위치
  1. 대리 프락시 (=리버스 프락시)
  • 네트워크의 가장 끝에 있는 웹서버들의 바로 앞에 위치, 웹 서버로 향하는 모든 요청을 처리하고, 필요할 때만 웹 서버에게 자원을 요청할 수 있다.
  • 보안 기능을 추가
  • 성능 개선용: 빠른 웹서버 캐시를 느린 웹 서버 앞에 놓는다.
  1. 네트워크 교환 프락시
  • 캐시를 이용해 인터넷 교차로의 혼잡을 완화하고, 트래픽 흐름을 감시하기 위해,
    충분한 처리 능력을 갖춘 프락시가 네트워크 사이의 인터넷 피어링 교환 지점들에 놓일 수 있다.

3.2 프락시 계층

  • 부모관계: 인바운드 프락시 방향 쪽의 프락시를 부모, 아웃바운드 프록시 방향 쪽을 자식으로 본다.

3.2.1 프락시 계층 콘텐츠 라우팅

  • 프록시 서버는 여러 가지 판단 근거에 의해 메세지를 다양하고 유동적인 프록시 서버와 원 서버들의 집합에게 보낼 수 있다.

동적 부모 선택의 몇 가지 사례

  1. 부하 균형: 자식 프록시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거하여 부모 프록시를 고른다.
  2. 지리적 인접성에 근거한 라우팅: 자식 프록시는 원 서버의 지역을 담당하는 부모를 선택할 수 있다.
  3. 프로토콜/타입 라우팅: URI에 근거하여 다른 부모나 원서버로 라우팅 할 수 있다.
  4. 유료 서비스 가입자를 위한 라우팅: 사용자가 빠른 서비스를 위해 추가금을 지불했다면, 성능 개선을 위한 압축 엔진으로 라우팅 될 수 있다.

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

  • 어떻게 HTTP 트래픽이 프록시로 향하는 길을 찾아내는지 알아보자.

클라 트래픽이 프록시로 가도록 만드는 방법 4가지

  1. 클라이언트를 수정한다.
  2. 네트워크를 수정한다.: 클라가 컨트롤할 수 없다면, 네트워크 인프라를 가로채서 웹 트래픽을 프록시로 가도록 조장하는 방법.

    인터셉트 프록시 (= transparent proxy): HTTP 트래픽을 지켜보고 가로채어 클라 모르게 트래픽을 프록시로 보내는 스위칭 장치와, 라우팅 장치가 필요.

  3. DNS namespace를 수정한다.
  • 대리 프록시는 웹 서버의 이름과 IP주소를 자신이 직접 허용한다.
  • DNS 이른 테이블을 수동으로 편집하거나,
    사용할 적절한 프록시나 서버를 계산해주는 특별한 동적 DNS 서버를 이용해서 조정 가능하다.
  1. 웹 서버를 수정한다.
    1. HTTP 리다이렉션 명령을 클라에게 돌려줌으로써, 클라의 요청을 프록시로 리다이렉트 하도록 설정할 수 있다.
  • 리다이렉트를 받는 즉시, 클라는 프록시와의 트랜잭션을 시작한다.

4. 클라에서 프록시 설정 방법

4.1 수동

  • 단 하나의 프록시 서버만 지정가능하다.
  • 장애시 대체 작동에 대한 지원이 없다.
  • 관리 문제를 야기한다.

4.2 클라 프록시 설정

PAC 파일

  • 프록시 자동 설정 파일은 프록시 설정에 대한 보다 동적인 해결책이다.
  • 문서에 접근할 때마다, 자바스크립트 함수가 적절한 프록시 서버를 선택한다.

자바스크립트 PAC 파일의 URI를 브라우저에 설정해야 한다.

  • 브라우저는 URI로부터 PAC파일을 가져와서 매 접근마다 적절한 프록시 서버를 계산하기 위해 실행한다.
  • 확장자: .pac
  • MIME타입: application/x-ns-proxy-autoconfig
  • FindProxyForURL(url, host) 함수를 정의해야 한다.
    1
    FindProxyForURL(url, host): "DIRECT" | `PROXY ${host}:${port}` | `SOCKS ${host}:${port}`
    1
    2
    3
    4
    5
    function FindProxyForURL(url, host) {
      if(url.substring(0,5) == 'http:') return "PROXY http-proxy.mydomain.com:8080"
      else if(url.substring(0,4) == 'ftp:') return "PROXY ftp-proxy.mydomain.com:8080"
      else return "DIRECT"
    }

MDN PAC 파일 참고자료

WPAD 파일

웹 프록시 자동 발견 프로토콜 Web Proxy Auto-Discovery Protocol

  • 브라우저에게 알맞은 PAC 파일을 자동으로 찾아주는 알고리즘이다.
  • WPAD 프로토콜이 구현된 클라가 하게 될 일은
    1. PAC URI를 찾기 위해 WPAD를 사용한다.
    2. 주어진 URI에서 PAC파일을 가져온다.
    3. 프록시 서버를 알아내기 위해 PAC파일을 실행한다.
    4. 알아낸 프록시 서버를 이용해서 요청을 처리한다.
  • WPAD는 성공할 때까지 각 기법을 하나씩 시도해본다. (20장에서 자세히..)
    1. 동적 호스트 발견 규약 DHCP (Dynamic Host Configuration Protocol)
    2. 서비스 위치 규약 [SLP]
    3. DNS 잘 알려진 호스트 명
    4. DNS SRV 레코드
    5. DNS TXT 레코드 안의 서비스 URI

5. 프록시 요청의 특이사항 6가지

  1. 프록시 URI는 서버 URI와 다르다.
  2. 가상 호스팅에서 일어나는 같은 문제
  3. 인터셉트 프록시는 부분 URI를 받는다
  4. 프록시는 프록시 요청과 서버 요청을 모두 다룰 수 있다.
  5. 전송 중 URI 변경
  6. 인터셉트 프록시를 이용한 URI 분석

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

  • 웹 서버와 웹 프록시 메세지의 문법은 간다.
  • 요청 URI가 달라진다.
    1
    2
    3
    4
    5
    6
    7
    클라 => 서버
    GET /index.html HTTP/1.0
    User-Agent: SuperBrowserv1.3

    클라 => 프록시
    GET http://www.mary.com/index.html HTTP/1.0
    User-Agent: SuperBrowserv1.3
  • 애초에 단일 서버 기준으로 메세지 설계가 되었었다.
  • 프록시가 부상하면서 부분 URI는 문제가 되었고, 프록시 기반 게이트웨이는 URI 스킴을 알 필요가 있었기 때문에 부분URI가 아닌 전체 URI를 보낸다.

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

  • 명시적인 프록시는 요청 메세지가 완전한 URI를 갖도록 함
  • 가상 호스팅 웹 서버는 Host 헤더를 요구한다.

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

  • 클라는 자신이 프록시와 대화하고 있음을 항상 알고 있지 않다.
  • 몇몇 프록시는 클라에게는 보이지 않을 수 있다. (대리 프록시, 인터셉트 프록시)
  • 때문에 보통 완전 URI를 보내지만, 위의 프록시들에게는 부분URI를 보내게된다.

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

  • 다목적 프록시 서버는 요청 메세지에 완전URI와 부분URI를 모두 지원해야한다.
  • 프록시
    => 프록시로 요청시, 완전 URI
    => 웹서버로 요청시, Host 헤더

5.5 전송 중 URI 변경

프록시 서버는 요청 URI의 변경에 엄격해서는 안된다.
사이드 이펙트를 일으킬 수 있다.

6. 메세지 추적

  • 오늘날 웹 요청의 상당수가 프락시를 지나간다.
    = 동시에 성능상의 이유로 세계 곳곳에 흩어져 있는 대리 캐시 저장고에 콘텐츠를 복제해두는 방식이 흔해지고있다.
  • 프락시는 여러 벤더에 의해 개발된다.
  • 프락시가 점점 흔해지면서, 프락시를 넘나드는 메세지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다.

6.1 Via 헤더

    1. HTTP헤더 필드의 Via는 메세지가 지나는 각 중간 노드(Proxy or GateWay)의 정보를 나열한다.
  • 노드를 지날때마다, 중간노드는 Via 목록의 끝에 반드시 추가되어야 한다.
  • Via헤더 필드는 메세지의 전달을 추적하고, 메세지 루프를 진단하고, 요청을 보내고, 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메세지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다.
1
Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com
  1. HTTP 1.1 프로토콜로 구현, proxy-62.irenes-isp.net로 불림
  2. HTTP 1.0 프로토콜로 구현, cache.joes-hardware.com로 불림
  • 네트워크 라우팅 루프를 탐지하기 위해 Via 헤더를 사용할 수 있다.

Via 문법

  • 쉽표로 구분되는 경유지waypoint 목록
  • 각 경유지는 개별 프락시 서버나
    게이트웨이 홉을 나타낸다.
    • 중간노드의 프로토콜과 주소에 대한 정보를 담고 있다.
1
Via: ([ protocol-name "/ ] protocol-version ( host [ ":" port] ) [ comment ]), (...)
1
2
3
4
5
6
Via: 1.1 62e18ccb7bd6.cloudfront.net (CloudFront)

protocol-name: HTTP
protocol-version: 1.1
host: 62e18ccb7bd6.cloudfront.net
comment: (CloudFront)
  • 프로토콜 이름: 중개자가 받은 프로토콜 / 프로토콜이 HTTP라면 이름이 없어도 된다.
  • 프로토콜 버전: 수신한 메세지의 버전. 버전포맷은 프로토콜에 달려있다.
  • 노드 이름: 중개자의 호스트와 포트번호(포트번호가 없으면 사용하는 프로토콜의 기본 포트라고 간주), 보안을위해 가명으로 대체 가능하다.
  • 노드 코멘트: 중개자 노드를 서술하는 선택적인 코멘트. 벤더나 버전 정보를 포함한다. 프락시 서버에서 일어난 진단정보를 포함하기도 한다.

Via 요청과 응답 경로

  • 요청메세지가 프락시 A,B,C를 지나간다면,
    응답메세지는 프락시 C,B,A를 지나간다.
  • 응답 Via 헤더는 거의 요청 Via 헤더와 반대다.

Via와 게이트웨이

  • 몇몇 프락시 서버에게 비 HTTP 프로토콜을 사용할 수 있는 게이트웨이 기능을 제공한다.
  • Via 헤더는 이러한 프로토콜 변환을 기록하므로 HTTP 어플리케이션은 프락시 연쇄에서 프로토콜 능력과 변환이 있었는지 알아챌 수 있다.

Server헤더와 Via헤더

  • Server 응답 헤더 필드는 원서버에 의해 사용되는 소프트웨어를 알려준다.
  • 응답 메세지가 프락시를 통과할 때, 프락시는 Server 헤더를 수정해서는 안된다.
  • Server 헤더는 원 서버를 위해 존재한다.
    대신 프락시는 Via 항목을 추가해야 한다.
1
Server: nginx/1.10.3 (Ubuntu)

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

  • 보안을 위한다면, Via 노드 이름을 가명으로 교체해야한다.
  • 아주 강력한 보안을 위해 프락시는 정렬된 일련의 Via 경유지 항목들을 하나로 합칠 수 있다.
    • 여러 경유지들이 모두 같은 조직의 통제하에 있고,
      호스트가 이미 가명으로 교체되지 ㅇ낳은 이상,
      그들에 대한 항목들을 합쳐서는 안된다.
    • 수신된 프로토콜 값이 서로 다른 항목들도 합쳐서는 안된다.
1
2
3
4
5
Via 1.0 foo, 1.1 devirus.company.com, 1.1 access-logger.company.com

아래처럼 합칠 수 있다.

Via: 1.0 foo, 1.1 concealed-stuff

6.2 TRACE 메서드

  • 프락시가 점점 복잡해지고, 더 많은 벤더가 프락시 제품을 배치하면서, 상호운용성 문제가 증가한다.
  • 프락시 네트워크를 진단하기 위해, HTTP/1.1의 TRACE메서드는
    요청 메세지를 프락시의 연쇄를 따라가면서 관찰/추적할 수 있도록 해준다.
    • 프락시 흐름을 디버깅하는데 매우 유용하다. (널리 구현되지 않았다)
  • TRACE 요청이 목적지 서버에 도착했을 때,
    서버는 전체 요청 메세지를 HTTP 응답 메세지의 본문에 포함시켜 송신자에게 그대로 돌려보낸다.
    • Content-Type은 message/http

Max-Forwards

  • 모든 프락시와 게이트웨이는 Max-Forwards를 지원해야 한다.
  • TRACE와 OPTIONS 요청의 프락시 홉 갯수를 제한하기 위해 Max-Forwards를 사용한다.
  • 전달되는 메세지가 무한루프에 빠지지 않는지
    프락시 연쇄를 테스트하거나, 연쇄 중간의 특정 프락시 서버들의 효과를 체크할 때 유용하다.
  • Max-Forwards요청 헤더 필드는 이 요청 메세지가 몇번 더 다음 홉으로 전달될 수 있는지 말해주는 정수 하나를 담고 있다.
  • 만약 0이라면, TRACE메서드를 더이상 전달하지 말고, 반드시 클라에게 돌려줘야한다.
  • 0보다 크다면, 다음으로 전달될때 1을 감소하고 갱신해야한다.

7. 프락시 인증

  • 접근 제어장치로써 제공될 수 있다.
    1. HTTP는 사용자가 유효한 접근 권한 자격을 프락시에 제출하지 않는 한,
      콘텐츠에 대한 요청을 차단하는 프락시 인증이라는 매커니즘을 정의하고 있다.
  • 제한된 콘텐츠에 대한 요청이 프락시 서버에 도착했을 때,
    407 Proxy Authorization Required 상태코드를 Proxy-Authenticate 헤더 필드와 함께 반환할 수 있다.
  1. 클라는 407 응답을 받게되면, 사용자에게 요구되는 자격을 수집한다.
  2. 자격을 획득하면: Proxy-Authenticate 헤더 필드에 자격을 담아서 다시 보낸다.
  3. 자격이 유효하면: 프락시는 원요청을 통과시킨다.
    자격이 유효하지 않으면: 407 응답을 보낸다.
  • 프락시 인증은 인증해야하는 프락시가 연쇄상 있을 경우 잘 동작하지 않는다.

8. 프락시 상호운용성

  • 클라, 서버, 프락시는 여러 벤더에 의해 만들어진다.
  • 프락시 서버는 서로 다른 클라, 서버 사이를 중개해야한다.

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

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

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

  • OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가
    어떤 기능을 지원하는지(메서드 등) 클라(혹은 프락시)가 알아볼 수 있게 해준다.
  • 성공한다면, 200 OK 응답으로 반환한다.
    (서버에서 지원하거나, 지정한 리소스에 대한 가능한 선택적인 기능들을 서술하느 ㄴ여러 헤더를 포함하여)
    1. HTTP/1.1이 명시한 헤더는, 서버에 의해 어떤 메서드가 지원되는지 서술하는 Allow 헤더 하나뿐이다.

8.3 Allow 헤더

  • 요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다.
    1
    Allow: GET, HEAD, PUT
  • 서버는 클라가 원하는 모든 메서드를 지원해야할 의무는 없다.
  • 요청에 대한 응답에는 실제로 지원하는 메서드들을 열거하는 Allow 헤더를 포함시켜야한다.
  • 프락시는 Allow 필드를 수정할 수 없다.

참고자료

  1. MDN PAC 파일 참고자료
  2. DHCP (Dynamic Host Configuration Protocol)
profile

author.

Joy Kim @feel5ny

웹 프론트엔드 개발자입니다. 글쓰기와 정리를 좋아합니다.

📚