Proxy 개념(1)

최근 궁금한 부분이 생겼다.  외부 API 서버로 데이터를 요청하는데,  중간에 Proxy 서버를 경우 해야 하는 경우이다.

외부 API 인터페이스에 맞게 요청하는데, 별도의 설정없이 프락시 서버에 요청하면 응답이 실제 오는지 아니면 별도의 데이터를 추가해서 전달해야 하는지 궁금증이 생겼다.

 

순서

• Proxy의 서버에 대한 개념 정리
• MS-Azure에 Proxy 서버 생성
• Proxy 서버 생성 후  공공API 호출을 경유하여 테스트 진행

 

 

Proxy 

 

Proxy는 클라이언트와 서버 사이에 위치하여 HTTP 메세지의 중개인 역할을 한다.

 

웹 프락시 서버는 클라이언트의 입장 (요청 보내는 곳)에서 트랜잭션을 수행하는 중개인이다. 트랜잭션이란 하나의 비즈니스 로직을 말하다는데,
여기서는 요청을 보내고 경유한 후 응답을 받아서 다시 전달하는 과정을 이야기하며,
중간에 어떠한 오류(네트워크 통신오류, 프로토콜 형식오류 등등)를 통해 오류가 발생한다면 그 모든 작업은 모두 롤백되어야 함을 이야기한다.

 

HTTP 프락시 서버는 웹 서버이기도 하고 웹 클라이언트이기도 하다.  실제 사용자 입장에서 프록시 서버로 요청을 보내고 그에따른 응답을 전달해 주기때문에 웹 서버이고, 목적지 IP에게 HTTP 메시지를 보내기 때문에 웹 클라이언트라고 할 수 있는 것이다.

 

( * 프록시 서버를 구성할 때 가장 간단히 구성할 수 있기 때문에 실무에서도 squid를 이용해 구축한다고 한다.
따라서 나도 구축할 때 squid를 사용해 구축할 예정이다.)

 

개인 , 공용 프록시

 

프락시 서버를 생성할 때는 개인 프록시로 활용될 것인가? 혹은 공용 프록시 서버로 활용될 것인가로 1차적인 분류가 된다. 

 

 1) 공용 프록시 

   대부분의 프락시 서버는 공용으로 사용된다. 그 이유는 중앙 집중형 프록시를 관리하는게 비용효율이 높고 쉬워서이다. 캐시 프록시 서버와 같은 몇몇 프록시 애플리케이션은 프록시를 이용하는 사용자가 많을수록 유리하다. 

 

 2) 개인 프록시

   개인 전용 프락시는 요즘 활발하게 사용되고 있다. 해당 컴퓨터에서 직접 실행되는 형태로 브라우저의 기능 확장 및 해외 접속, 광고 운영을 위해 작은 개인 프록시를 사용한다.

 

 

 

프록시 서버 사용 사례

 

1. 성인 콘텐츠 차단

 - 요청 url 검증을 통해 성인 콘텐츠를 차단할 수 있다.

 

2. 문서 접근 제어자

 - 프락시 서버는 많은 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적을 하기 위해 사용될 수 있다.

 

3. 보안 방화벽

 - 내부망에 접근하거나 나가는 응용 layer의 프로토콜의 흐름을 네트워크의 한지점에서 통제할 수 있다. 

바이러스를 제거하는 웹이나 이메일 프락시가 사용할 수 있는 트래픽을 살펴볼 수 있는 hook을제 공

 

4. 웹 캐시

 -  프락시 서버의 캐시는 자주 요청되는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공하여, 네트워크 사용량을 줄일 수 있다.

 

5. 대리 프락시(surrogate)

 - 흔히 서버 가속기라고 부른다. 공용 콘텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용될 수 있다. 컨텐츠 라우팅 기능과 결합되어 주문형 복제 컨텐츠의 분산 네트워크 용도로 사용된다.

 

6. 컨텐츠 라우터

- 프락시 서버는 인터넷 트래픽 조건과 종류에 특정 웹 서버로 유도하는 컨텐츠 라우터로 동작할 수 있다. 

 

7. 트랜스코더

- 프락시 서버는 컨텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정 할 수 있다. 이와 같은표현 방식의 변환을

트랜스 코딩이라고 한다.

 

8. 익명 프록시 (Anonymizer)

- HTTP 메시지에서 신원을 식별할 수 있는 특성들을 제거함으로써 개인 정보 보호와 익명성 보장에 기여할 수 있다

ip, from header, referer header, cookies, cookies, uri session id...

 

 

 

프락시가 트래픽을 처리하는 방법

클라이언트 수정 : 웹 브라우저들은 프록시 설정을 지원합니다. 만약 프락시를 사용하도록 설정되어 있다면, 클라이언트는 HTTP 요청을 바로 그리고 의도적으로 프락시로 보낸다.

 

네트워크 수정 : 클라이언트가 눈치챌 수 없도록 네트워크 인프라를 가로채서 웹 트래픽 프락시로 가도록 하는 몇 가지 기법이 있다. 이것을 인터셉트 프락시라고 한다.

 

DNS namespace 수정 : 웹 서버 앞에 있는 surrogate는 웹 서버의 이름과 IP주소를 직접 사용한다. 그래서 모든 요청은 대리 프락시를 거쳐서 가게된다. 즉 DNS 이름 테이블을 수동 편집하거나,  적절한 프록시 서버를 계산해주는 특별한 동적 DNS 서버를 이용해서 조정될 수 있다.

 

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

 

 

프록시 서버 특징

• 프록시 URI는 서버 URI와 다르다.
   웹 서버와 웹 프록시 메시지의 문법은 서로 같지만, 한 가지 예외가 있다.
  클라이언트가 프록시 대신 서버로 요청을 보내면 요청의 URI가 달라진다. 서버로 보낼 때와 달리 프락시로 요청을 보낼 때, 요청 줄은 완전한 URI를 갖는다. (서버는 스킴, 호스트, 포트번호 생략 가능)
  목적지 서버와 커넥션을 맺어야 하기 때문에, 서버의 이름을 알 필요가 있었다. 프락시가 부상할 당시, 이미 너무 많은 서버가 배치되어 있었고 완전한 URI를 보낼 필요가 있었다.
  
  
• 가상 호스팅에서 일어나는 같은 문제
   가상 호스팅이란 virtual hosting이라고도 하며 하나의 서버에 여러 개의 도메인 이름을 호스팅 하는 방식을 말한다.
  가상으로 호스팅 되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유한다. 따라서 웹 서버는 호스트의 정보를 요구하기 위해 요청 메시지가 완전한 URI를 갖도록 함으로써 문제를 해결했다. 또한 가상으로 호스팅 되는 웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더를 요구한다.
  
  
• 인터셉트 프락시는 부분 URI를 받는다.
   인터셉트 프락시는 네트워크 단계에서 요청을 가로채 프록시 서버로 전달한다.  이렇게 감춰진 프록시인 경우 클라이언트는 자신이 웹 서버와 연결되었다고 생각하고 완전한 URI를 보내지 않을 것이다. 
    
  - surrogate는 원 서버의 호스트 명과 아이피 주소를 사용해 원 서버를 대신하는 프록시 서버이다.
  - 인터셉트 프락시는 네트워크 흐름에서 클라이언트에서 서버로 가는 트래픽을 가로채 캐시된 응답을 돌려주는 등의 일을 하는 프록시 서버이다.
   
• 프록시는 프록시 요청과 서버 요청 모두 다룰 수 있다.
   다목적 프록시 서버는 완전 URI와 부분 URI를 모두 지원해야 한다. 
  완전 URI와 부분 URI를 사용하는 규칙은 다음과 같다.
  
  1. 완전한 URI가 주어지면 프록시는 그것을 사용한다.
  2. 부분 URI가 주어지고, HOST 헤더가 있다면, HOST 헤더를 이용해 원 서버의 이름과 포트 번호를 알아내야 한다.
  3. 부분 URI가 주어지고 HOST헤더가 없는 경우, surrogate이면 실제 서버 주소와 포트번호가 설정되어 있을 수 있으며, 인터셉트 프락시인 경우 가로챈 트래픽이 존재하고, 원 ip주소와 port번호를 사용할 수 있도록 했다면 사용할 수 있고, 없다면 에러 메시지를 반환한다.
  
  
• 전송 중 URI 변경
    프락시는 URI를 전달할 때 절대 경로를 고쳐 쓰는 것을 금지한다.
    

 

Via 헤더

 

via 헤더 필드는 메시지가 지나는 각 중간 노드의 정보를 나열한다. 이 중간 노드에는 게이트웨이나 프락시서버가 담길 수 있다. 다른 노드를 지날 때마다,  현재 노드는 Via 목록의 끝에 반드시 추가되어야 한다.

 

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

• 프로토콜 이름 : HTTP, HTTPS, FTP...
• 프로토콜 버전 : '1.0', '1.1'...
• 노드 이름 : 호스트와 포트번호...
• 노드 코멘트
• Via 요청과 응답 경로

Via가 개인정보 보호와 보안에 미치는 영향 : 프락시 서버가 네트워크 방화벽의 일부인 경우 프락시는 호스트의 이름과 포트 및 정보를 전달해서는 안된다.

 

프록시 인증

• 제한된 콘텐츠에 대한 요청이 프락시 서버에 도착했을 때, 프락시 서버는 407 상태 코드를 어떻게 그러한 자격을 제출할 수 있는지 설명해주는 Proxy-Authenticate 헤더 필드와 함께 반환할 수 있다
• 407 응답을 받으면, 로컬 데이터베이스를 확인해서든 사용자에게 물어봐서든 요구되는 자격을 수집한다.
• 자격을 획득하면, 클라이언트는 요구되는 자격을 Proxy-Authorization 헤더 필드에 담아서 요청을 다시 보낸다.
• 자격이 유효하다면, 프락시는 원 요청을 연쇄를 따라 통과시킨다. 유효하지 않다면 407 응답을 보낸다.

 

 

프락시 서버의 종류

 

프락시 서버는 위치와 네트워크 구성에 따라 나누어 질 수 있습니다.

 

Forward Proxy 

 일반적인 프록시 서버로, 클라이언트와 서버의 중계 역할을 수행합니다. 이경우는 클라이언트가 요청하기 전까지 웹 서버의 주소를 알 수 없습니다.

 

Reverse Proxy

  클라이언트와 priavte Network에 존재하는 서버들  사이에 위치하여 제어 역할을 수행합니다.

클라이언트의 요청을 받아 내부망 서버에 요청한 후 응답을 클라이언트에게 전달해 줍니다. 실제 서버들에 대한 주소를 매핑하고 있으며, 보안, 로드밸런싱을 위해 사용됩니다.

 

Open Proxy

 열린 프락시로 모든 요청에 열려 있으며,  자신의 IP주소를 숨기고 프록시 IP를 통해 인터넷 서비스를 이용할 수 있습니다. IP 추적 방지 및 우회 접속이 가능합니다.