HTTP 완벽 가이드 6장

6장 Proxy

1. 웹 중개자

프락시는 클라이언트와 서버 사이에서 서버와 클라이언트 역할을 수행한다.
HTTP 프락시 서버는 웹 서버이기도 하고 웹 클라언트이기도 하다. (요청을 중개한다.)

공용 프락시

대부분의 프락시는 공용이며 공유된 프락시이다.
여러 사람들의 공통된 요청이 발생하면 효율성이 발휘된다.

개인 프락시

클라이언트 컴퓨터에서 직접 실행되는 형태로 흔하게 사용되지는 않는다.
무료 IPS 서비스를 위한 광고를 운영하기 위해 작은 프락시를 사용자의 컴퓨터에서 직접 실행한다.

인터넷 서비스 공급자가 제공하는 인터넷 서비스에는 인터넷 액세스, 인터넷 전송, 웹 호스팅, 도메인 이름 등록, 코로케이션 및 유즈넷 서비스가 포함될 수 있습니다. ISP는 일반적으로 인터넷에서 사용 가능한 모든 것에 대한 액세스를 사용자에게 제공하는 액세스 지점 또는 게이트웨이 역할을 합니다.

게이트웨이

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

2. 왜 프락시를 사용하는가

필터링

• 프락시에서 블랙리스트 주소를 관리하여 특정 URL 접근을 제한 할 수 있다.

  어린이들이 부적절한 사이트에 접근하는 경우 접근을 강제로 차단 할 수 있다.

접근 제어

• 웹 서버 및 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적을 하기 위해 사용.
• 중앙화된 프락시 서버에서 각 웹서버들에 대한 접근 제어를 설정하여 편리하다.

  특정 리소스에 접근 할 시에 비밀번호를 요구 할 수 있다.

방화벽

• 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제한다.
• 트래픽을 세심히 살펴볼 수 있는 hook를 제공한다. (바이러스 여부 등 확인)

웹캐시

• 자주 사용되는 문서의 로컬 사본을 관리한다.
• 해당 문서에 대한 요청이 오면 빠르게 제공하여, 느리고 비싼 인터넷 커뮤니케이션을 줄인다.

대리 프락시

• 대리 혹은 리버스 프락시로 불린다.
• 진짜 웹 서버처럼 위장하고 요청을 받는다.

  본래 서버의 IP 주소 노출을 방지하여 해커들의 DDoS 공격과 같은 공격을 막는데 유용

• 대리 프락시는 공용 콘텐츠에 대한 느린 웹서버의 성능을 개선하기 위해 사용된다.

  성능 향상을 위해 캐시 데이터를 저장

• 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 시작한다.
• 본래 서버가 클라이언트들과 직접 통신을 하면 SSL(or TSL)로 암호화, 복호화 비용이 많이 든다.
  리버스 프락시를 사용하면 들어오는 요청을 모두 복호화하고 나가는 응답을 암호화해주므로
  클라이언트와 안전한 통신을 할 수 있으며 본래 서버의 부담을 줄여준다.

콘텐츠 라우터

• 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도한다.
• 사용자 또는 콘텐츠 제공자의 서비스 이용 방법에 따라 맞춤형 라우팅이 가능하다.

  성능 향상을 위해 돈을 지불하면 가까운 캐싱 서버를 사용하여 콘텐츠를 빠르게 전달하거나
  필터링 서비스에 가입하여 있다면 필터링 프락시를 통과하도록 할 수도 있다.

트랜스코더

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

  이미지 확장자 변경 및 크기 압축, 텍스트 압축, 웹페이지 텍스트 축소하여 생성 등

익명화 프락시

• HTTP 메세지에서 신원을 식별할 수 있는 특성을 제거한다.

  클라이언트 IP주소, From 헤더, Referer 헤더, 쿠키, URI 세션 아이디를 제거

3. 프락시는 어디에 있는가

프락시 서버 배치

출구(Egress) 프락시

• 악의적인 해커를 막는 방화벽을 위해
• 인터넷 요금 절약 및 인터넷 성능을 개선하기 위해
• 특정 URL 접근 등 필터링을 위해

접근 프락시

• 고객의 모든 요청을 종합적으로 처리하기 위해 ISP 접근 지점에 위치하여 다운 속도 개선
• 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 둔다.

대리 프락시

• 웹 서버 앞에 위치하여 웹 서버에게 필요한 때에 요청을 전달한다.
• 웹 서버에 대한 보안기능 추가 및 캐시를 통해 성능 향상을 한다.

네트워크 교환 프락시

• 캐시를 이용해 인터넷 교차로의 혼잡을 완화
• 트래픽 흐름을 감시
• 네트워크 사이(IPS간)의 인터넷 피어링(연결 및 트래픽 교환) 교환 지점에 둔다.

프락시 계층

프락시 서버들은 부모와 자식 관계를 갖는다.
다음번 인바운드 프락시(서버와 가까운 쪽)를 부모라고 부르고
다음번 아웃바운드 프락시(클라이언트와 가까운 쪽)는 자식이라고 부른다.
또한 프락시의 부모 선책은 동적으로도 이루어진다.

부하 균형

• 자식 프락시는 부모의 작업량 수준에 근거하여 부모 프락시를 고른다.

지리적 인접성에 근거한 라우팅

• 자식 프락시는 원 서버의 지역을 담당하는 부모를 선택할 수도 있다.

프로토콜/타입 라우팅

• 자식 프락시는 URI에 근거하여 다른 부모나 특정 프락시, 원 서버로 라우팅 할 수 있다.

유료 서비스 가입자를 위한 라우팅

• 웹 서비스 운영자가 빠른 서비스를 위해 추가금을 지불한다면
  그들의 URI는 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅 될 수 있다.

트래픽 처리

어떻게 HTTP 트래픽이 프락시로 향하는 길을 찾아내는지는 이하 4가지 방법이 있다.

클라이언트를 수정한다.

구글 크롬 등 많은 웹 클라이언트들은 수동 혹은 자동 프락시 설정을 지원한다. 만약 클라이언트가 프락시를 사용하도록 설정되어 있다면, 클라이언트 HTTP 요청을 여기에서 바로 프락시로 보낸다.

네트워크를 수정한다.

클라이언트는 알지 못하는 상태에서, 네트워크 인프라를 가로채서 웹 트래픽이 프락시로 가도록 조정한다. 스위칭 장치와 라우팅 장치를 필요로 하며, 이러한 프락시를 인터셉트 프락시라고 부른다.

DNS 이름공간을 수정한다.

대리 프락시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용한다. 그러면 모든 요청은 서버 대신 대리 프락시로 가는데, 이는 DNS 이름 테이블을 수동으로 편집하거나 사용할 적절한 프락시 서버를 계산해주는 특별한 동적 DNS 서버를 이용해서 조종될 수 있다.
실제 서버의 IP 주소와 이름이 변경되고, 대리 프락시에게는 이전 주소와 이름이 주어지기도 한다.

웹 서버를 수정한다.

웹 서버는 HTTP 리다이렉션 명령을 클라이언트에 돌려주고, 리다이렉트를 받는 즉시 클라이언트는 프락시와의 트랜잭션을 시작한다.

4. 클라이언트 프락시 설정

수동 설정

브라우저는 수동으로 프락시를 지정하는 설정을 제공한다.
하나의 프락시 서버만을 지정할 수 있고, 장애 시 대체 작동 지원은 없다.
크롬의 경우 설정 => 고급 설정 >= 프락시 설정 변경에서 사용자가 수동으로 설정할 수 있다.

브라우저 기본 설정

브라우저 벤더 혹은 배포자가 기본 설정을 해둘 수 있다.

프락시 자동 설정 (Proxy Auto Configuration, PAC)

PAC 파일은 프락시 설정을 그때그때 상황에 맞게 계산해주는 작은 자바스크립트 프로그램이다.
브라우저는 URI로 부터 PAC파일을 가져와서 매 접근마다 적절한 프락시 서버를 계산한다.
DIRECT(프락시 없이 직접 연결), PROXY host:port(지정한 프락시 이용), SOCKS host:port(지정한 SOCKS 이용)과 같은 값이 반환되는 .pac 파일을 가져야한다.

WPAD

대부분의 브라우저는 웹 프락시 자동발견 프로토콜(Web Proxy Auto Discovery protocol, WPAD)을 제공한다. WPAD는 브라우저에게 알맞은 PAC 파일을 자동으로 찾아주는 알고리즘이다.
WPAD는 PAC URI를 찾고 가져와 적절한 프락시를 알아내기 위해 사용된다.
WPAD의 기법의 순서는 이하와 같다.

• 동적 호스트 발견 규약(DHCP)
• 서비스 위치 규약(SLP)
• DNS 잘 알려진 호스트 명
• DNS SRV 레코드
• DNS TXT 레크드 안의 서비스 URI

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

프락시 URI와 서버 URI

단일 서버는 자신의 호스트 명과 포트번호를 알고 있으므로 클라이언트는 불필요한 정보 발송을 피하기 위해
스킴과 호스트, 포트번호가 없는 부분 URI만 보냈다.

프락시는 목적지 서버와 커넥션을 맺어야 하기 때문에, 그서버의 이름을 알 필요가 있다.
또한 다른 스킴과 연결하기위해 URI의 스킴정보도 필요로 한다.
위와 같은 이유로 클라이언트가 프락시를 사용하도록 설정되어 있다면 완전한 URI를 보낸다.

가상호스팅

가상으로 호스팅 되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유한다.
부분 URI가 오면, 웹 서버는 어떤 호스트에 접근하는 요청인지 알 수 없다.
Host헤더를 요구하거나 명시적인 프락시는 요청 메세지가 완전한 URI를 보내도록 하였다.

인터셉트 프락시

클라이언트가 프락시를 사용하지 않는다고 설정을 하여도, 대리 프락시나 인터셉트 프락시를 지날 수 있다. 두 경우 모두 클라이언트는 웹 서버와 대화한다고 생각하여 부분 URI를 보낼 수 있다.

• 대리 프락시는 원 서버의 호스트 명과 아이피 주소를 사용하므로 문제가 없다.
• 인터셉트 프락시는 클라이언트에서 서버로 가는 트래픽을 가로채기 때문에, 웹 서버로 보내는 부분 URI를 얻게 된다.

프락시 요청과 서버 요청

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

• 완전한 URI가 주어지면 그것을 사용한다.
• 부분 URI와 Host 헤더가 주어진다면 Host헤더를 이용하여 원 서버의 이름과 포트 번호를 알아낸다.
• 부분 URI면서 Host 헤더가 없다면
  • 대리 프락시일 경우 실제 서버의 주소와 포트번호를 가지고 있다.
  • 인터셉트 프락시일 경우 설정되어있는 원 서버 IP주소와 포트번호로를 사용한다.
  • 모두 실패하였다면 원 서버를 알 수 없으므로 에러를 반환한다.

전송 중 URI 변경

• URI 변경은 다운스트림 서버와 상호운용성 문제를 일으킬 수 있다.
• 포트 변경이나 이스케이프 변환등 프로토콜을 엄격하게 준수하면 안된다.
• 절대 경로를 고쳐서는 안된다. 유일한 예외는 빈 경로의 경우 '/'로 변경하는 것 뿐이다.

클라이언트의 기능(자동확장과 호스트명 분석)

• 웹 사이트의 이름만 입력하여도 www., .com을 붙여 준다.
• 오타 교정을 하여 사용자가 의도한 URI를 제시하기도 한다.
• 특정 도메인에서 추가적인 값을 입력하면 그 도메인의 DNS는 그 값이 추가로 붙은 URI를 찾아본다.

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

• 브라우저는 유효한 호스트 명이 발견될 때까지 다양한 호스트 명의 가능성들을 검색한다.

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

• 브라우저는 명시적인 프락시가 있는 경우 부분 호스트 명을 자동확장하지 않는다.
• 위와 같은 이유로 몇몇 프락시는 www., .com을 붙이는 자동확장과 같은 브라우저의 기능을 최대한 흉내 내려고 시도한다.

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

• 프락시가 없는 경우와 동일하게 브라우저에서 자동확장을 한다.
• 인터셉터 프락시가 원 서버와 통신을 한 후에 원 서버의 상태를 알게 된다.
• 원 서버에 장애가 있을 경우 IP 주소에 대한 역방향 DNS 룩업을 해서 다른 IP주소를 알아내야 한다.

6. 메세지 추적

via 헤더

via 헤더 필드는 쉼표로 구분된 경유지 목록이다.
각 경유지는 개별 프락시 서버나 게이트웨이 홉을 나타내며 그들 중간 노드의
프로토콜과 주소에 대한 정보를 담고 있다.

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

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

via를 통해 호스트 이름과 포트가 노출되면 이를 악의적인 집단에서 이용할 수도 있기 떄문에, 보안 경계선에 존재하는 프락시는 호스트 명을 적당한 가명으로 교체해줘야 한다.
또 강력한 보안 요구 사항이 있을 경우, 여러 경유지 항목들이 하나로 합치기도 한다.

여러 경유지들이 모두 같은 조직의 통제하에 있고 호스트가 이미 가명으로 교체되지 않은 이상 그들에 대한 항목들을 합쳐서는 안 된다.
수신된 프로토콜 값이 서로 다른 항목들도 합쳐서는 안된다.

TRACE 메서드

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

• Max-Forwards
  요청이 건널 수 있는 프락시 홉 갯수를 제한하는 헤더. 하나의 홉을 지날 때 마다 값이 1만큼 감소하고, 0이 되면 원 서버에 도착하지 않았다할지라도 클라이언트로 메시지를 돌려줘야 한다.

7. 프락시 인증(접근 제어)

요청이 프락시 서버에 도착 하였을때 407 Proxy Authorization Reauired 상태 코드와
Proxy-Authenticate 헤더 필드를 통해 어떻게 자격을 제출할 수 있는지 정보를 반환한다.

8. 프락시 상호운용성

지원하지 않는 헤더 및 메서드

• 프락시 서버는 넘어오는 헤더 필드들을 모두 이해하지 못할 수도 있다.
• 프락시는 이해할 수 없는 헤더필드는 반드시 그대로 전달해야 하며,
  같은 이름의 헤더 필드가 여러개 있는 경우에는 그들의 상대적인 순서도 반드시 유지해야 한다.

OPTIONS

• 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지 클라이언트가 알 수 있게 해준다.
• Allow 헤더를 통해 서버가 지원하는 메서드를 확인 할 수 있다.

OPTIONS * HTTP/1.1

HTTP/1.1 200 OK
Allow: GET, PUT, POST, HEAD, TRACE, OPTIONS

OPTIONS http://www.test.com/index.html HTTP/1.1
static HTML file wouldn`t accept a POST method.