[HTTP 완벽 가이드] - 프록시

Lee Jeong Min·2022년 3월 25일
FEonTheBlockhttp네트워크스터디
2

네트워크

목록 보기
13/17
post-thumbnail

6장 프록시

웹 중개자

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

웹 프락시 서버는 웹 서버이기도하고 웹 클라이언트이기도 함

개인 프락시와 공유 프락시

개인 프락시

하나의 클라이언트만을 위한 프락시

공유 프락시

여러 클라이언트가 함께 사용하는 프락시로 사용자가 많을 수록 유리하다. → 여러 사용자들의 공통된 요청에서 이득을 취할 수 있기 때문!

프락시 대 게이트웨이

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

브라우저 <-HTTP-> 웹 프락시 <-HTTP->  웹 서버

게이트웨이: 서로 다른 프로토콜을 사용하는 둘 이상을 연결

브라우저 <-HTTP-> 웹/이메일 게이트웨이 <-POP->  웹 서버

그러나 프락시와 게이트웨이의 실질적인 차이점은 모호한데, 프락시가 때때로 약간의 프로토콜 변환을 하기도 하며, 상용 프락시 서버는 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근, 웹 기반의 어플리케이션 지원을 위해 게이트웨이 기능을 구현하기 때문이다.

왜 프락시를 사용하는가?

  • 보안 개선
  • 성능 향상
  • 비용 절약

위 3가지 뿐만아니라 아래와 같은 기능들을 제공하기도 함

  • 어린이 필터: 초등학교에서 성인 콘텐츠를 차단
  • 문서 접근 제어자: 단일한 접근 제어 전략을 구현하고, 감사 추적을 함 → 특정 클라이언트에게는 접근 허용, 다른 클라이언트는 막음
  • 보안 방화벽: 네트워크의 한 지점에서 응용 레벨 프로토콜의 흐름을 통제
  • 웹 캐시: 문서에 대한 요청이 오면 가까운 위치에서 빠르게 제공해줌
  • 대리 프락시: 리버스 프락시, 서버 가속기라고도 알려져 있으며 웹 서버인 것처럼 위장하여 웹 서버 요청을 받는다. 보통 공용 컨텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용!
  • 콘텐츠 라우터: 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작한다. 사용자에 따른 캐싱 및 서버 요청을 관리할 수 있다. → 돈 낸사람 캐싱서버로 안그런 사람 원 서버로 요청
  • 트랜스코더: 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있다. → 영문을 한국어로 변환한 페이지를 제공하는 등등..
  • 익명화 프락시: HTTP 메시지에서 신원을 식별할 수 있는 특성인 IP주소, From 헤더, Referrer 헤더, 쿠키, URI 세션 아이디 등을 적극적으로 제거하여 개인 정보 보호와 익명성 보장에 기여한다.

프락시는 어디에 있는 가?

프락시가 어디에 있고 언제 네트워크 아키텍처상에 배치되는지 이야기해보자.

프락시 배치 서버

어떻게 사용할지에 따라 프락시를 어디에든 배치할 수 있다.

  • 출구 프락시: 로컬 네트워크와 더 큰 인터넷 사이 오가는 트래픽을 제어하기 위해 프락시를 로컬 네트워크 출구에 놓을 수 있다. → 초등학교의 성인콘텐츠를 막는 필터링 출구 프락시가 대표적인 예시
  • 접근(입구) 프락시: 모든 요청을 종합적으로 처리하기 위해 ISP 접근 지점에 위치하기도 함 보통 캐시 프락시를 사용해 많이 찾는 문서들의 사본을 저장한다.
  • 대리 프락시: 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에 자원을 요청
  • 네트워크 교환 프락시: 캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시하기 위해 네트워크 사이의 인터넷 피어링 교환 지점에 놓일 수 있다.

프락시 계층

프락시들은 프락시 계층과 같은 연쇄를 구성할 수 잇는데, 프락시 서버들을 부모와 자식의 관계를 맺는다.

서버쪽에 가까운 쪽을 인바운드 프락시라고 하여 부모라고 하며, 클라이언트에 가까운 쪽은 아웃바운드 프락시라고 하여 자식이라고 부른다.

  • 프락시 계층 콘텐츠 라우팅: 계층이 반드시 정적이진 않고, 상황에 맞게 부모 프락시나 원 서버에 라우팅하기도 한다. → 동적 부모 선택
  • 부하 균형: 부하를 분산하기 위해 부모들의 작업량 수준에 근거하여 부모 프락시를 고름
  • 지리적 인접성에 근거한 라우팅: 원 서버의 지역을 담당하는 부모를 선택
  • 프로토콜/타입 라우팅: URI에 근거하여 판단하며, 특정 종류의 URI를 갖고 있는 요청의 경우 특별한 프락시 서버로 보내져 특별한 프로토콜로 처리될 수 있다.
  • 유료 서비스 가입자를 위한 라우팅: 웹서비스 운영자가 빠른 서비스를 위해 추가금을 지불한경우, 그들의 URI는 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅 도리 수 있다.

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

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

  • 클라이언트를 수정한다: 브라우저와 같은 웹 클라이언트에서 프락시를 사용할지말지 설정하는 것
  • 네트워크를 수정한다: 클라이언트 모르게 스위칭 장치와 라우팅 장치를 통해 프락시로 이동시킴 → 이를 인터셉트 프락시라고 부른다.
  • DNS 이름공간을 수정한다: DNS 이름 테이블을 수동으로 편집하거나 사용할 적절한 프락시나 서버를 계산해주는 특별한 동적 DNS 서버를 이용해서 조정될 수 있다.
  • 웹 서버를 수정한다: HTTP 리다이렉션 명령을 클라이언트에게 돌려줌으로써 요청을 프락시로 리다이렉트 하도록 설정할 수 있다.

클라이언트 프락시 설정

브라우저가 프락시를 설정하는 여러 가지 방법

  • 수동 설정: 프락시를 사용하겠다고 명시적으로 설정
  • 브라우저 기본 설정: 브라우저 벤더나 배포자가 브라우저를 소비자에게 전달하기 전에 프락시를 미리 설정
  • 프락시 자동 설정(PAC): JS 프락시 자동 설정 파일에 대한 URI를 제공할 수 있다. → 이를 이용하여 클라이언트가 판단해서 프락시를 쓸지 말지, 어떤 프락시 서버를 쓸지 판단한다.
function FindProxyForURL(url, host) {
  if (url.substring(0,5) === 'http:') {
    // 지정한 프록시를 사용해야함을 의미하는 PROXY host:port
    return "PROXY http-proxy.mydomain.com:8080";
  } else if (url.substring(0,4) === "ftp:" {
    return "PROXY ftp-proxy.mydomain.com:8080";
  } else {
    // 프락시 없이 연결이 직접적으로 이루어져야함을 의미하는 DIRECT
    return "DIRECT";
  }
}
// 그외 SOCKS host:port -> 지정한 SOCKS 서버를 사용
  • WPAD 프락시 발견: 자동 설정 파일을 다운 받을 수 있는 ‘설정 서버'를 자동으로 찾아주는 웹 프락시 자동발견 프로토콜을 제공한다.
    이 프로토콜이 구현된 클라이언트는 다음과 같은 일들을 함.
- PAC URI를 찾기 위해 WPAD를 사용
- 주어진 URI에서 PAC 파일을 가져온다.
- 프락시 서버를 알아내기 위해 PAC파일을 실행한다.
- 알아낸 프락시 서버를 이용해서 요청을 처리한다.

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

프락시 서버 요청의 미묘하고도 오해하기 쉬운 측면들에 대해 설명한다.

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

클라이언트가 웹 서버로 요청을 보낼 때, 스킴과 호스트가 없는 부분 URI만을 보내지만, 프락시로 보낼 때는 완전한 URI를 보낸다.

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

가상으로 호스팅 되는 웹 서버는 여러 웹사이트가 같은 물리적 웹 사이트를 공유한다. 이 부분이 프락시의 ‘스킴/호스트/포트번호 누락'과 같은 문제라고 볼 수 있는데 각각 다른 방법으로 해결되었다.

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

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

인터셉트 프락시나 대리 프락시와 같이 클라이언트가 자신이 프락시와 대화하고 있는 지 모르는 경우가 있다.

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

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

다목적 프락시는 요청 메시지의 완전한 URI와 부분 URI를 모두 지원해야한다.

그 규칙은 다음과 같다.

  • 완전한 URI가 주어진 경우 프락시는 이것을 사용한다.
  • 부분 URI가 주어졌고 Host 헤더가 있다면 이를 이용해 원 서버의 이름과 포트 번호를 알아낸다.
  • 부분 URI가 주어졌으나 Host 헤더가 없다면, 다음의 방법으로 원 서버를 알아내야 한다.
    • 대리 프락시인경우, 프락시에 실제 서버의 주소와 포트 번호가 설정되어 있을 수 있다.
    • 인터셉트 프락시가 원 IP 주소와 포트번호를 사용할 수 있도록 해두었다면 이를 사용한다.
    • 모두 실패하였다면 반드시 에러 메시지를 반환해야한다.

전송 중 URI 변경

URI의 변경은 다운스트림 서버와 상호 운용성에 문제를 일으킬 수 있기 때문에 신경을 써야한다.

일반적으로 프락시 서버는 가능한 한 관대하도록 애써야하며 URI의 변경을 최소한으로 하고, 유일한 예외는 빈 경로를 ‘/’로 교체하는 경우이다.

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

호스트가 발견되지 않는 경우 브라우저들은 자동화된 호스트 명의 ‘확장'을 제공하고자 한다.

ex)

  • www 와 같은 접두사 및 com 접미사를 붙인다.
  • 오타 교정
  • DNS는 호스트 명의 앞부분만 입력하면 자동으로 도메인 검색

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

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

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

명시적인 프락시 사용시, 편리한 확장을 사용할 수 없고 부분 호스트 명을 자동확장하지 않는다. → 이러한 이유로 몇몇 프락시는 이러한 기능들을 흉내내려고 시도한다.

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

프락시 없는 URI 분석과 크게 다르지 않지만, 서버로의 커넥션이 만들어졌을 때 아래와 같은 차이가 발생한다.

→ 브라우저에서 제공하는 것과 동등한 수준의 장애 허용을 제공하기 위해 프락시는 호스트 헤더에 들어 있는 호스트 명을 다시 분석하든 아니면 IP 주소에 대한 역방향 DNS 룩업을 해서든 다른 IP 주소를 시도한다.(명시적인 프락시와 인터셉트 프락시를 이용하는 경우 모두 죽은 서버의 DNS 분석에 대한 장애 허용을 지원하는 것이 프락시에 달려있기 때문에 중요하다!)

메시지 추적

많은 회사들이 보안과 비용 절감을 위해 인터넷 접속 시 캐시 프락시 서버를 사용한다.

Via 헤더

이 헤더를 통해 몇 개의 프락시를 지나갔음을 알 수 있다. 또한 메시지의 전달을 추적하고 메시지의 루프를 진단하며 요청을 보내 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다.

Via 문법

Via 헤더 필드는 쉼표로 구분된 경유지(waypoint)의 목록이다.

Via waypoint 4개 구성요소

  • 프로토콜 이름(선택): HTTP 프로토콜이라면 없어도 된다.
  • 프로토콜 버전(필수): 1.0, 1.1과 같은 것들
  • 노드 이름(필수): 중개자의 호스트와 포트 번호
  • 코멘트(선택): 중개자 노드를 서술하는 선택적인 코멘트

Via 요청과 응답 경로

요청 메시지 응답 메시지 모두 프락시를 지나는 경우 Via 헤더를 가지며 둘이 언제나 반대가 된다.

Via와 게이트 웨이

몇몇 프락시는 비 HTTP 프로토콜을 사용할 수 있는 게이트 웨이 기능을 제공하고, Via 헤더는 프로토콜 변환을 기록하여 어떤 변환이 있었는지 알아챌 수 있다.

Server 헤더와 Via 헤더

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

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

정확한 호스트 명이 들어가기를 원하지 않는 몇 가지 경우가 있는 경우, 적당한 가명으로 교체해야 한다.

TRACE 메서드

요청 메시지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고 어떻게 각 프락시가 요청 메시지를 수정하는지 관찰/추적할 수 있도록 하여 프락시 흐름을 디버깅하는데 매우 유용하다.

Trace 응답의 Content-Type은 message/http 이다.

Max-Forwards

요청의 프락시 홉(hop) 개수를 제한하기 위해 사용할 수 있다.

프락시 인증

프락시는 접근 제어 장치로서 제공될 수 있다. 이를 통해 클라이언트가 프락시 접근 시, 이 콘텐츠에 대한 접근 자격을 물어보고 클라이언트는 응답 받은것을 통해 Proxy-Authorization 헤더 필드에 담아서 요청을 다시 보낸다. 이후 자격이 유효하면 이 요청을 통과시킨다.

프락시의 상호운용성

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

프락시는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 한다.

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

특정 리소스가 어떤 기능을 지원하는지 클라이언트가 알아볼 수 있게 해준다. 성공하면 Allow 헤더를 통해 어떤 메서드가 지원되는지 알려준다.

Allow 헤더

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

Allow: GET, HEAD, PUT

Allow 헤더는 리소스가 지원했으면 하는 메서드를 추천하기 위해 요청 헤더로 사용될 수 있으며, 프락시가 지정된 모든 메서드를 이해할 수 없다고 해도 이 필드를 수정할 수 없다.(클라이언트는 원 서버와 대화하는 다른 경로를 갖고 있을 수도 있기 때문)

profile
Lee Jeong Min
It is possible for ordinary people to choose to be extraordinary.
이전 포스트

[HTTP 완벽 가이드] - 웹서버 + TCP 제어

다음 포스트

[HTTP 완벽 가이드] - 캐시

0개의 댓글