[HTTP] 프록시

[TOC]

06 프록시

• 웹 프록시 서버는 중개자
  • 어떤 중개자 ? -> HTTP 메세지를 정리하는 중개자

• HTTP 프록시 vs 웹 게이트웨이
• 프록시의 유용한 활용방법
• 실제 네트워크에 어떻게 배치되는지, 트래픽 이동은 어떻게 되는지
• 브라우저에서 프록시 사용법
• HTTP 프록시 요청 vs 일반 서버 요청
• 프록시 로깅
• 프록시 기반 HTTP 접근 제어
• 프록시 상호작용 원리

 

6.1 웹 중개자

• 웹 프록시 서버는 클라이언트 입장에서 트랜잭션을 수행하는 중개인이다.
• 또한 웹 서버이기도 하며 클라이언트이기도 하다 (클라이언트 -> 프록시 -> 서버 구조라서)

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

• 개인 프록시
  • 하나의 클라이언트만을 위한 프록시

• 공유 프록시
  • 여러 클라이언트가 함께 사용하는 프록시
  • 대부분의 프록시는 공용이다
  • 중앙 집중형 프록시를 관리하는 것이 더 비용효율이 높고 쉬움
  • 사용자들의 공통된 요청을 처리하는 과정에서 이득이 있음

6.1.2 프록시 대 게이트웨이

• 프록시는 같은 프로토콜을 사용하는 둘 이상의 어플리케이션을 연결
  • 프록시는 가끔 특정 상황에서 게이트웨이 기능을 구현하기도 한다.
  • ex) SSL 보안 프로토콜, SOCKS 방화벽,FTP 접근 등
• 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결

 

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

• 프록시 서버는 실용적이고 유용한 것이라면 무슨 일이든 한다
  • 보안 개선
  • 성능 향상
  • 비용 절약
  • 트래픽 감시 및 수정

• 어린이 필터
  • 성인 콘텐츠 차단 필터링 프록시

• 문서 접근 제어자
  • 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적을 하기 위해 사용되기도 함
  • 주로 대기업 환경이나 분산된 관료 조직에서 사용
  • 인증 과 인가 역할이다.

• 보안 방화벽
  • 보안을 강화하기 위해 프록시 서버를 사용
  • Application 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제함
  • 바이러스를 제거하는 웹이나 이메일 프록시가 사용할 수 있는 트래픽 관찰용 hook 제공

• 웹 캐시
  • 로컬 사본을 관리하여 캐시 역할을 함

• 대리 프록시
  • 진짜 웹 서버인것 처럼 위장할 때가 있음
  • 공용 컨텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용됨
  • 이런 프록시를 서버 가속기라고 부름
  • 분산 네트워크 역할

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

• 트랜스 코더
  • 프록시 서버는 콘텐츠를 클라이언트에게 전달하기 전 본문 포맷 수정 가능
  • 예를 들어 크기를 줄이기 위해 GIF를 JPG로 변환함

• 익명화 프록시
  • HTTP 메시지에서 신원을 식별할 수 있는 특성들을 적극적으로 제거하여 익명성 보장 기여
    • User-Agent에서 사용자, OS 정보 제거
    • From 제거하여 발신지 제거
    • 방문 경로 삭제 위해 Referer 차단
    • 신원 정보 없애기 위해 Cookie 헤더 삭제

 

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

• 어떻게 프록시가 네트워크에 배치되는가
• 어떻게 프록시의 연쇄가 계층을 이루는가
• 어떻게 트래픽이 올바르게 프록시를 찾아가는가.

6.3.1 프록시 서버 배치

• 어떻게 사용할지에 따라서 어디에든 배치 가능

• 출구(Egress) 프록시
  • 트래픽을 제어하기 위해 로컬 네트워크의 출구에 박아 넣을 수 있음
  • 방화벽 제공 및 인터넷 트래픽 성능 개선을 위함
  • 필터링으로도 사용

• 접근(입구) 프록시
  • 고객의 모든 요청을 종합적으로 처리하기 위해 ISP 접근 지점에 위치
    • ISP(Internet Service Provider)
    • 다운로드 속도 개선 및 대역폭 비용 줄임(캐시 프록시 사용)

• 대리 프록시
  • 리버스 프록시라고도 한다.
  • 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치
  • 모든 요청을 서버대신 처리하고 필요할 때만 웹 서버에 자료 요청

• 네트워크 교환 프록시
  • 캐시를 이용해 인터넷 교차로의 혼잡 완화
  • 트래픽 흐름 감시

6.3.2 프록시 계층

클라이언트 <--> 프록시 1 <--> 프록시 2 <--> 프록시 3 <--> 원 서버
        (프록시 2의 자식)  (프록시 3의 자식, (프록시 2의 부모)
                          프록시 1의 부모) 

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

프록시 계층 콘텐츠 라우팅

• 위의 프록시 계층 구조는 정적이다.
• 언제나 1은 2를 통해야 하며 2는 3을 통해야 하기 때문
• 프록시는 상황에 맞는 프록시에 라우팅 할 수 있다.

• 동적 부모 선택의 몇가지 예시
  • 부하 균형
    • 부하를 분산하기 위해 부모들의 작업량 수준에 근거하여 부모 프록시 고름
  • 지리적 인접성에 근거한 라우팅
    • 원 서버의 지역을 담당하는 부모 선택
  • 프로토콜/타입 라우팅
    • URI에 근거하여 다른 부모나 원 서버로 라우팅 가능
  • 유료 서비스 가입자를 위한 라우팅
    • 유료 사용자를 위한 빠른 처리를 위한 라우팅

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

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

• 클라이언트 수정
  • 의도적으로 프록시로 보낼 수 있음 (브라우저에서 수정)

• 네트워크 수정
  • 네트워크 인프라를 개로채서 웹 트래픽을 프록시로 가도록 조정한다.
    • 인터셉트 프록시라 함

• DNS 이름 공간 수정
  • 대리 프록시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용한다.

• 웹 서버 수정
  • 리다이렉션 명령으로 클라이언트 요청을 프록시로 전달 가능

 

6.4 클라이언트 프록시 설정

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

• 크롬이나 익스플로러에서 모두 프록시 설정 가능
• 몇몇 ISP는 그들의 요구에 맞춰 미리 설정된 브라우저나 웹 트래픽을 프록시 서버로 리다이렉트 하는 맞춤형 운영체제 구매

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

• 수동 프록시 설정은 유연하지 못함
• 프록시 자동 설정 (PAC) 파일은 프록시 설정에 대한 동적인 해결책이다.
• 이 파일은 프록시 설정을 그때그때 상황에 맞게 계산해주는 작은 javascript 프로그램이다.
  • 문서에 접근할 때마다 javasciprt 함수가 적절한 프록시 서버 선택

• PAC 파일을 사용하려면 파일의URI를 브라우저에 설정해야함
• .pac 확장자를 가지며 MIME 타입은 application/x-ns-proxy-autoconfig다.
• PAC 파일은 프록시 서버를 계산하는 FindProxyForUri(url, host) 함수를 구현해야함

// 프록시 자동설정 파일 예시

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";
    }
}

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

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

• WPAD 프로토콜이 구현된 클라이언트가 하는 일
  • PAC URI를 찾기 위해 WPAD 사용
  • 주어진 URI에서 PAC 파일 가져옴
  • 프록시 서버를 알아내기 위해 PAC 파일 실행
  • 알아낸 프록시 서버를 이용해 요청 처리

• WAPD 명세
  • 동적 호스트 발견 규약(DHCP)
  • 서비스 위치 규약(SLP)
  • DNS 잘 알려진 호스트 명
  • DNS SRV 레코드
  • DNS TXT 레코드 안의 서비스 URI
  • 자세한 것은 20장

 

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

• 프록시 요청의 URI는 서버 요청과 어떻게 다른가
• 인터셉트 프록시와 리버스 프록시는 어떻게 서버 정보를 알아내기 어렵게 만드는가
• URI 수정에 대한 규칙
• 프록시는 브라우저의 똑똑한 URI 자동완성이나 호스트 명 확장 기능에 어떻게 영향을 주는가

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로 오는데, 가상으로 호스팅 되는 웹 서버는 요청이 접근하고 싶어하는 호스트명을 모른다.
• 해결책
  • 명시적인 프록시는 요청 메시지가 완전한 URI를 갖도록 함
  • 가상으로 호스팅 되는웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더 요청

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

• 클라이언트는 자신이 프록시와 대화하고 있음을 항상 알고있는 것은 아니다.
  • 대리 프록시나 인터셉트 프록시를 지날 것을 모르고 있을수 있다.
  • 자신이 프록시와 대화하는 것을 모르면 부분 URI를 보낼 것이다.

• 그래서 어떡하라는거지?

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

• 다목적 프록시 서버는 요청 메시지의 완전한 URI와 부분 URI를 모두 지원해야함
• 규칙은 다음과 같다
  • 완전한 URI가 주어지면 프록시는 그것을 사용해야 함
  • 부분 URI가 주어졌고 Host 헤더가 주어지면 Host 헤더를 통해 원 서버의 정보 얻음(포트, 서버 이름)
  • 부분 URI가 주어졌고 Host 헤더가 없으면 다음의 방법을 사용한다.
    • 대리 프록시면 실제서버의 주소나 포트번호가 설정되어있을 수 있음
    • 이전에 어떤 인터셉트 프록시가 가로챘던 트래픽을 받았고, 그 인터셉트 프록시가 원 IP 주소와 포트 번호를 사용할 수 있도록 해두었다면 그 IP주소와 포트 번호 사용 가능
    • 모두 실패하면 에러 메시지 반환 (Host 헤더 사용하는 현대적 브라우저로 업그레이드 권유)

6.5.5 전송 중 URI 변경

• 몇몇 프록시는 URI를 다음 홉으로 보내기 전에 표준 형식으로 정규화 하기도 함
• 이 과정에서 상호운용성 문제 발생 가능
• 일반적으로 프록시 서버는 가능한 한 관대하도록 애써야함
• HTTP명세는 일반적인 인터셉트 프록시가 URI를 전달할 때 절대 경로를 고쳐 쓰는 것을 금지함
  • 유일한 예외는 빈 경로를 '/'로 교체하는 것 뿐

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

• 브라우저는 프록시의 존재 여부에 따라 요청 URI를 다르게 분석
  • 웹사이트 가운데(ex) naver)만 입력하면 자동으로 접두사(www.) 접미사(.com)을 붙임

6.5.7 프록시 없는 URI 분석(URI Resolution)

• 브라우저는 유효한 호스트 명이 발견될 때까지 다양한 호스트 명의 가능성 섬색
  • 기본 스킴이나 포트번호, 접두사, 접미사 붙임

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

• 명시적 프록시를 사용하면 위와 같은 자동확장 안됨
  • 브라우저의 URI가 프록시를 그냥 지나쳐버리기 때문

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

• 호스트 명 분석은 보이지 않는 인터셉트 프록시와 함께일 때 약간 달라짐
  • 왜냐하면 클라이언트 입장에서 인터셉트 프록시는 존재하지 않음

• DNS가 성공할 때까지 호스트 명을 자동학장하는 브라우저를 사용할 때, 동작은 프록시가 아닌 서버의 경우와별 차이 없음
• 그러나 인텃베트 프록시를 사용하고 있는 브라우저는 죽은 서버의 IP 주소를 탐지할 수 없음

 

 

6.6 메시지 추적

• 프록시는 점점 흔해지고 있다.
• 서로 다른 스위치와 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것은 원래 중요했음
• 여기에 프록시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요해짐

6.6.1 Via 헤더

• Via 헤더 필드는 메시지가 지나는 각 중간 노드(프록시, 게이트웨이)의 정보를 나열함
  • 다음의 헤더는 두개의 프록시를 지남을 의미함

Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

• Via 문법
  • Via 헤더 필드는 쉼표로 구분된 경우지(waypoint)의 목록임
  • 각 경유지는 개별 프록시 서버나 게이트웨이 홉을 나타냄
  • 프로토콜과 주소에 대한 정보를 담음
    • 프로토콜 이름(선택)
    • 프로토콜 버전(필수)
    • 노드 이름(필수)
    • 코멘트(선택)

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

• 프로토콜 이름
  • 중개자가 받은 프로토콜
  • HTTP라면 없어도 됨(기본값)

• 프로토콜 버전
  • 수신한 메시지의 버전

• 노드 이름
  • 중개자의 호스트와 포트 번호
  • 가명으로 대체 가능

• 노드 코멘트
  • 중개자 노드를 서술하는 코멘트
  • 벤더나 버전 정보 포함
  • 이벤트 진단 정보 포함

• Via 요청과 응답 경로
  • 요청 메세지와 응답 메시지 모두 프록시를 지나므로 둘 모두 Via 헤더 가짐
  • 요청이 A B C면 응답은 C B A

• Via와 게이트웨이
  • 몇몇 프록시는 서버에게 비 HTTP 프로토콜을 사용할 수 있는 게이트웨이 기능 제공
  • Via를 통해 프록시 연쇄에서 프로토콜 변환이 일어났는지 알 수 있음

• Server 헤더와 Via 헤더
  • 서버 응답 헤더 필드는 원 서버에 의해 사용되는 소프트웨어 알려줌
  • 프록시를 통과할 때 이 서버 헤더가 수정되어서는 안됨
  • Via에만 추가

• Via가 개인정보 보호와 보안에 미치는 영향
  • 컴퓨터 이름과 버전 번호가 유출될 수 있음
  • 호스트명이 들어가기를 원하지 않는 몇가지 경우엔 가명으로 대체

6.6.2 TRACE 메소드

• 프록시 서버는 메시지가 전달될 때 메시지 바꿀 수 있음
• TRACE 메소드로 요청 메시지를 프록시의 연쇄를 따라가면서 어떤 프록시를 지나가고 어떻게 각 프록시가 요청 메시지를 수정하는지 관찰/추적 할 수 있음
  • 디버깅에 용이함
• TRACE 요청이 목적지 서버에 도착하면 서버는 응답 메시지 본문에 포함시켜 송신자에게 보냄

• Max-Forwards
  • 프록시 홉(hop) 개수 제한
  • 메시지가 무한 루프에 빠지지 않는지 프록시 연쇄를 테스트할 때 사용
  • 연쇄 중간의 특정 프록시 서버들의 효과를 체크할 때 유용

 

6.7 프록시 인증

• 프록시는 접근 제어 장치로서 제공될 수 있음
• 제한된 콘텐츠에 대한 요청이 프록시 서버에 도착했을때
  • 프록시 서버는 접근 자격을 요구하는 407 Proxy Authorization Required 상태코드를 어떻게 그러한 자격을 제출할 수 있는지 설명해주는 Proxy-Authenticate 헤더 필드와 함께 반환
  • 클라이언트는 자격 수집
  • 자격 획득 후 Proxy-Authorization 헤더 필드에 담아 요청 다시 보냄
  • 유효하면 통과, 아니면 다시 407

• 연쇄상의 여러개 있을 때 잘 동작하지 않음
• 12장 참고

 

6.8 프록시 상호운용성

• 프록시는 여러 벤더에 의해 만들어져서 지원하는 기능도 다르고 버그도 제각각이다.

6.8.1 지원하지 않는 헤더와 메소드

• 프록시는 가능한 한 메시지를 다음 홉으로 전달하려 시도해야 함
• 지원하지 않는 메소드를 통과시킬 수 없는 프록시는 오늘날 대부분의 네트워크에서 살아남지 못함

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

• OPTIONS로 서버의 능력을 알아 낼 수 있음

OPTIONS * HTTP/1.1

서버 전체의 능력에 대해 물음

• OPTIONS 메소드는 서버에서 지원하거나 지정한 리소스에 대해 가능한 선택적인 기능들을 서술하는 여러 헤더필드를 포함한 200 OK 상태메시지 반환

6.8.3 Allow 헤더

• Allow는 서버가 지원하는 메시지 반환함
• 프록시는 수정 못함