프락시

1. 웹 중개자

HTTP 프락시 서버는 웹 서버이기도 하고 웹 클라이언트이기도 합니다. 프락시는 HTTP 클라이언트의 요청을 받으며 동시에 프락시는 요청을 서버로 보내기도 합니다. 트랜잭션을 완료하는 것이 클라이언트라는 점은 변하지 않지만, 프락시 서버가 제공하는 좋은 서비스를 이용하게 됩니다.

프락시 서버는 하나의 클라리언트가 독점으로 사용할 수도 있고, 여러 클라이언트가 공유할 수도 있습니다. 하나의 클라이언트만을 위한 프락시를 개인 프락시라고 부릅니다. 여러 클라이언트가 함께 사용하는 프락시는 공용 프락시라 부릅니다.

엄밀하게 말하면, 프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결합니다. 게이트웨이는 클라이언트와 서버가 서로 다른 프로토콜을 말하더라도 서로 간의 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 동작합니다. 하지만 실질적으로 프락시도 때때로 약간의 포로토콜 변환을 하기 때문에 프락시와 게이트웨이의 차이점은 모호합니다.

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

프락시 서버는 실용적이고 유용한 것이라면 무슨 일이든 합니다. 보안을 개선하고, 성능을 높여주며, 비용을 절약합니다. 그리고 프락시 서버는 모든 HTTP 트래픽을 들여다보고 건드릴 수 있기 때문에, 프락시는 부가적인 가치를 주는 여러 유용한 웹 서비스를 구현하기 위해 트래픽을 감시하고 수정할 수 있습니다.

2.1. 프락시 배치

출구 프락시

로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프락시를 로컬 네트워크의 출구에 박아 넣을 수 있습니다. 프락시 서버는 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제합니다. 프락시는 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적(Audit Trail)을 할 수 있으며, 종종 보안을 강화하기 위해 사용합니다.

접근 프락시

클라이언트로부터의 모든 요청을 종합적으로 처리하기 위해 프락시는 ISP 접근 지점에 위치하기도 합니다. ISP는 사용자들의 다운로드 속도를 개선하고 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용해 많이 찾는 문서들의 사본을 저장합니다.

대리 프락시

대리 혹은 리버스 프락시로 불리는 이들은 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 지원을 요청할 수 있습니다. 또한 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로써 성능을 개선할 수도 있습니다. 대리 프락시는 일반적으로 웹 서버의 이름과 IP 주소로 스스로 가장하기 때문에, 모든 요청은 서버가 아닌 이 프락시로 가게 됩니다.

네트워크 교환 프락시

캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시하기 위해 충분한 처리 능력을 갖춘 프락시가 네트워크 사이의 인터넷 피어링 교환 지점들에 놓일 수 있습니다.

2.2. 프락시 계층

프락시들은 프락시 계층이라고 불리는 연쇄를 구성할 수 있습니다. 다음번 인바운드 프락시(서버에 가까운 쪽)를 부모라고 부르고 다음번 아웃바운드 프락시(클라이언트에 가까운 쪽)는 자식이라고 부릅니다.

계층이 반드시 정적이어야 하는 것은 아닙니다. 프락시 서버는 여러 가지 판단 근거에 의해 메시지를 다양하고 유동적인 프락시 서버와 원 서버들의 집합에게 보낼 수 있습니다. 동적 부모 선택의 몇 가지 예를 들면 다음과 같습니다.

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

2.3. 트래픽 처리

클라이언트 트래픽이 프락시로 가도록 만드는 방법에는 다음 네 가지가 있습니다.

클라이언트를 수정합니다.

많은 웹 클라이언트들은 수동 혹은 자동 프락시 설정을 지원합니다.

네트워크를 수정합니다.

클라이언트는 알지도 못하고 간섭도 할 수 없는 상태에서, 네트워크 인프라를 가로채서 웹 트리픽을 프락시로 가도록 조정합니다. 일반적으로 HTTP 트래픽을 지켜보고 가로채어 클라이언트 모르게 트래픽을 프락시로 보내는 스위칭 장치와 라우팅 장치를 필요로 합니다. 이것을 인터셉트 프락시라고 부릅니다.

DNS 이름공간을 수정합니다.

웹 서버 앞에 위치하는 프락시 서버인 대리 프락시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용합니다. 그래서 모든 요청은 서버 대신 대리 프락시로 갑니다.

웹 서버를 수정합니다.

HTTP 리다이렉션 명령을 클라이언트에게 돌려줌으로서 클라이언트의 요청을 프락시로 리다이렉트 하도록 설정할 수 있습니다.

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

3.1. 완전 URI와 부분 URI

원래의 HTTP 설계에서, 클라이언트는 단일한 서버와 직접 대화했습니다. 단일 서버는 자신의 호스트 명과 포트번호를 알고 있으므로, 클라이언트는 불필요한 정보 발송을 피하기 위해 스킴과 호스트가 없는 부분 URI만 보냈습니다.

프락시가 부상하면서, 부분 URI는 문제가 되었습니다. 프락시는 목적지 서버와 커넥션을 맺어야 하기 때문에, 그 서버의 이름을 알 필요가 있었습니다. 그리고 프락시 기반 게이트웨이는 FTP 리소스나 혹은 그 외의 스킴과 연결하기 위해 URI의 스킴을 알 필요가 있었습니다. 그래서 우리는 서버로는 부분 URI를, 그리고 프락시로는 완전한 URI를 보낼 필요가 있습니다.

GET /index.html HTTP/1.0 (프락시 미사용)
GET http://www.marys-antiques.com/index.html HTTP/1.0 (프락시 사용)

이것으로 문제의 일부분은 해결되지만, 여전히 남은 문제가 있습니다. 몇몇 프락시는 클라이언트에게 보이지 않을 수 있습니다. 자신의 웹 서버와 대화하고 있다고 생각하고 완전한 URI를 보내지 않을 것입니다. 인터셉트 프락시는 클라이언트에서 서버로 가는 트래픽을 가로채기 때문에, 웹 서버로 보내는 부분 URI를 얻게 될 것입니다. 이를 위한 완전 URI와 부분 URI를 사용하는 규칙은 다음과 같습니다.

• 완전한 URI가 주어졌다면, 프락시는 그것을 사용해야 합니다.
• 완전한 URI가 주어졌다면, 프락시는 그것을 사용해야 합니다.
• 부분 URI가 주어졌으나 Host 헤더가 없다면, 다음의 방법으로 원 서버를 알아내야 합니다.
  • 프락시가 원 서버를 대신하는 대리 프락시라면, 프락시에 실제 서버의 주소와 포트 번호가 설정되어 있을 수 있습니다.
  • 이전에 어떤 인터셉트 프락시가 가로챘던 트래픽을 받았고, 그 인터셉트 프락시가 원 IP 주소와 포트번호를 사용할 수 있도록 해두었다면, 그 IP 주소와 포트번호를 이용할 수 있습니다.
  • 모두 실패했다면, 프락시는 원 서버를 알아낼 수 있는 충분한 정보를 갖고 있지 못한 것이므로 반드시 에러 메시지를 반환해야 합니다.

3.2. URI 클라이언트 자동확장과 호스트 명 분석

많은 브라우저들은 자동화된 호스트 명의 확장을 제공하고자 다음과 같이 몇 가지 시도를 합니다.

• 일반적인 웹 사이트 이름의 가운데 부분만 입력했다면, 많은 브라우저는 www. 접두사를 붙이고 .com 접미사를 붙입니다.
• 몇몇 브라우저는 해석할 수 없는 URI를 서드파티 사이트로 넘겨 오타 교정을 시도하고 사용자가 의도했을 URI를 제시합니다.
• 대부분의 시스템에서 DNS는 사용자가 호스트 명의 앞부분만 입력하면 자동으로 도메인을 검색하도록 설정되어 있습니다.

만약 프락시를 사용한다면, 브라우저는 이와 같이 편리한 확장들 중 어느 것도 더 이상 수행할 수 없습니다. 인터셉트 프락시와 명시적인 프락시는 모두 죽은 서버의 DNS 분석에 대한 장애 허용을 지원해야 한다는 것은 중요한데, 왜냐하면 브라우저가 프락시를 사용할 경우 장애 허용은 프락시에 달려있기 때문입니다.

4. 메시지 추적

프락시가 점점 더 흔해지면서, 서로 다른 스위치와 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것 못지않게 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었습니다.

4.1. Via 헤더

Via 헤더 필드는 메시지가 지나는 각 중간 노드(프락시나 게이트웨이)의 정보를 나열합니다. 메시지가 또 다른 노드를 지날 때마다, 중간 노드는 Via 목록의 끝에 반드시 추가되어야 합니다. 프락시는 요청을 보내기 전에 자신을 가리키는 유일한(Unique) 문자열을 Via 헤더에 삽입해야 하며 네트워크 라우팅 루프가 있는지 탐색하기 위해 이 문자열이 들어온 요청에 있는지 검사해야 합니다.

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

Via 문자열 안에 정확한 호스트 명이 들어가기를 원하지 않는 경우가 있습니다. 보통 명시적으로 이 동작이 켜져 있지 않은 이상, 프락시 서버가 네트워크 방화벽의 일부인 경우 프락시는 방화벽 뒤에 숨어있는 호스트의 이름과 포트를 전달해서는 안됩니다. 반화벽 뒤의 네트워크 아키텍처에 대한 정보가 악의적인 집단에 의해 이용될 수 있기 때문입니다. 만약 Via 노드 이름 전달이 가능하지 않다면, 보안 경계석의 일부분인 프락시는 호스트 명을 그 호스트에 대한 적당한 가명으로 교체해야 합니다.

4.2. TRACE 메서드

HTTP/1.1의 TRACE 메서드는 요청 메시지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고 어떻게 각 프락시가 요청 메시지를 수정하는지 관찰/추적할 수 있도록 해줍니다. TRACE 요청이 목적지 서버에 도착했을 때, 서버는 전체 요청 메시지를 HTTP 응답 메시지의 본문에 포함시켜 송신자에게 그대로 돌려보냅니다. TRACE 응답이 도착했을 때, 클라이언트는 서버가 받은 메시지와 그 메시지가 지나간 프락시들의 목록(Via 헤더 안에 있습니다)을 검사할 수 있습니다.

일반적으로 TRACE 메시지는 중간에 프락시들이 몇 개나 있든 신경 쓰지 않고 목적지 서버로의 모든 경로를 이행합니다. TRACE와 OPTIONS 요청의 프락시 홉(Hop) 개수를 제한하기 위해 Max-Forwards 헤더를 사용할 수 있는데, 이는 전달되는 메시지가 무한 루프에 빠지지 않는지 프락시 연쇄를 테스트하거나 연쇄 중간의 특정 프락시 서버들의 효과를 체크할 때 유용합니다.

5. 출처

• [HTTP 완벽 가이드 - 웹은 어떻게 동작하는가] - 프로그래밍 인사이트