ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Proxy
    Tech/Backend 2019. 12. 24. 20:31

    본 내용은 HTTP 완벽가이드 도서를 통한 학습과정을 기록한 글입니다. 개인적인 공부를 위해 남기는 목적이기에 내용상에 오류가 있을 수 있습니다. 잘못된 내용이 있다면 주저하지 마시고 알려주시면 감사드리겠습니다.


    1. Proxy Server

    프록시 서버란 무엇일까? 프록시의 뜻을 살펴보면 [대리]의 의미를 가지고 있다. 이를 보면 어떤 과정이나 행동을 대신해 준다고 막연하게나마 생각해볼 수 있다. 좀 더 구체적으로 설명한다면 '클라이언트와 서버 사이에 위치하여 HTTP 메시지를 정리하는 중개인' 정도로 생각할 수 있다.

    그렇다면, 중개인이 왜 필요한 것일까? 당연하게도 여러 이점이 있기 때문이다. 가령 보안상의 이유라던가, 필터링 기능, 부하 경감을 위한 Load Balancing 기능, 속도 개선을 위한 캐시 기능 등 프록시를 사용하는 것에는 이처럼 다양한 이유가 있다. * HTTP 트래픽을 모니터링하고 수정할 수도 있음.

    이제 [HTTP 완벽 가이드]의 내용을 천천히 살피며 프록시에 대해 좀 더 깊이 알아보도록 하겠다.


    2. 웹 중개의 역할을 하는 프록시 서버

    프록시 서버는 클라이언트와 서버 사이에 위치하기 때문에 웹 서버인 동시에 웹 클라이언트이기도 하다. 요청을 서버로 보내기도 하고, 요청을 보내고 응답을 받기도 하므로 요청과 커넥션을 적절히 다루고 응답해야한다. 이에 프록시를 만든다면, HTTP 클라이언트와 HTTP 서버의 양쪽 규칙 모두를 주의 깊게 따라야 한다.

    이런 프록시 서버는 하나의 클라이언트가 독점적으로 사용할 수도 있고, 여러 클라이언트가 공유할 수도 있다. 하나의 클라이언트만을 위한 프록시를 [개인 프록시]라 부른다. 여러 클라이언트가 함께 사용하는 프록시는 [공용 프록시]라 부른다.

    2-1. 공용 프록시

    대부분의 프록시는 공용이며 공유된 프록시이다. 이러한 공용 프록시는 중앙 집중형 프록시로 관리하는 게 비용효율이 높다. 또한 사용자가 많기 때문에 공통된 요청에서 이득을 취할 수 있는 캐시 프록시로 사용하기 좋다.

    2-2. 개인 프록시

    개인 전용 프록시는 흔하지 않지만 꾸준히 사용되고 있다. 보통 클라이언트 컴퓨터에서 직접 실행되는 형태를 띄우고 있으며, ISP 서비스와 마찬가지로 브라우저의 기능을 확장하거나 성능을 개선하는 등으로 이용된다.


    3. 프록시와 게이트웨이의 차이점?

    프록시는 같은 프로토콜을 사용하는 둘 이상의 어플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다. 게이트웨이는 클라이언트와 서버가 서로 다른 프로토콜로 말하더라도 서로 간의 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 작동한다. 하지만 실질적으로 프록시와 게이트웨이의 차이점은 모호하다. 브라우저와 서버는 다른 버전의 HTTP를 구현하기에 프록시는 때때로 약간의 프로토콜 변환을 한다. 또한 상용 프록시 서버는 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근 등을 지원하기 위해 게이트웨이 기능을 구현한다.


    4. 프록시 활용 사례

    4-1. 어린이 필터

    어린이들에게 교육 사이트를 제공하면서 동시에 성인 콘텐츠를 차단하는 필터링 프록시

    4-2. 문서 접근 제어자

    프록시 서버는 많은 웹 서버와 리소스에 대한 단일한 접근 제어 전략을 구현한다. 다양하고 많은 수의 웹 서버들을 하나 하나 수시로 수정/갱신하는 것이 아니라 중앙 프록시 서버에서 접근제어를 하는 방식이다. 이는 대기업이나 분산된 관료 조직에서 유용하게 쓰인다.

    4-3. 보안 방화벽

    프록시 서버는 서버로 들어오거나 나가는 프로토콜의 흐름을 네트워크의 한 지점에서 통제한다. 이는 바이러스를 제거하거나 트래픽을 세심히 살펴볼 수 있도록 한다.

    4-4. 웹 캐시

    프록시 캐시는 인기 있는 리소스의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공하여, 느리고 비싼 인터넷 커뮤니케이션을 줄인다. 이에 대한 예로 CDN(Content Delivery Network)을 들 수 있으며, 추후 CDN에 대해서도 다루어 보고자 한다.

    CDN(Content Delivery Network) 그림 *CloudFlare

    4-5. 리버스 프록시

    리버스 프록시는 진짜 웹 서버 요청을 받지만 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 시작한다. 이는 하나의 프록시로 다수의 서버 요청을 처리하고, 공용 콘텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용된다. 이러한 리버스 프록시는 Nginx, Apach와 같은 웹 서버들을 통해서도 사용가능하지 추후 실제 코드로 다루어 보고자 한다.

    4-6. 트랜스코더

    프록시 서버는 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있다. 이와 같이 데이터의 표현 방식을 자연스럽게 변환하는 것을 트랜스 코딩이라고 한다. 중개자에 의한 콘텐츠 변형. 예를 들어, GIF 이미지를 JPG로 변환할 수도 있고, 다른 언어로 문서를 변환하는 것도 가능하다.

    4-7. 익명의 프록시

    익명화 프록시는 HTTP 통신에서 신원을 확인할 수 있는 특성들(IP, From 헤더, Referer 헤더, 쿠키 등)을 제거하여 개인정보 보호와 익명성 보장에 기여 함.


    5. 프록시 서버 배치에 따른 분류

    5-1. Egress 프록시

    로컬 네트워크와 인터넷 사이를 오가는 트래픽을 제어하기 위해 프록시를 로컬 네트워크의 출구에 위치시킬 수 있음. 주로 방화벽, 인터넷 트래픽 성능 개선, 필터링의 역할을 수행한다.

    5-2. Ingress 프록시

    클라이언트로부터의 모든 요청을 종합적으로 처리하기 위해 프록시를 접근 지점에 위치시킬 수 있음. 주로 로드 밸런싱, 속도 개선 및 대역폭 비용 감소의 목적으로 사용된다

    5-3. Reverse 프록시

    웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청할 수 있다. 또한 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로써 성능을 개선할 수도 있다. 이처럼 reverse proxy는 웹 서버 성능 개선 목적이 있다.


    6. 프록시의 요청 방법

    프록시 서버들은 원 서버에 가까운 프록시 서버를 부모로 두고 상항에 맞게 부모 프록시나 원 서버에 정적/동적인 요청을 전달할 수 있다. 동적인 요청이라 함은 프록시가 상황에 맞게 유동적으로 프록시 서버와 원 서버에 요청을 보내는 것이라 할 수 있다. 동적으로 부모를 선택하는 방법에는 다음과 같은 예가 있다.

    6-1. 부하균형

    자식 프록시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거하여 부모 프록시를 고른다.

    6-2. 지리적 인접성에 근거한 라우팅

    자식 프록시는 원 서버의 지역을 담당하는 부모를 선택할 수도 있다. 먼 거리에 있는 서버에 요청하는 것이 아니라 인접한 지역을 담당하는 원 서버에 요청을 보낸다.

    6-3. 프로토콜/타입 라우팅

    어떤 자식 프록시는 URI에 근거하여 다른 부모나 원 서버로 라우팅 할 수 있다.

    6-4. 유료 서비스 가입자를 위한 라우팅

    웹 서비스 운영자가 빠른 서비스를 위해 추가 요금을 지불하였다면, 해당 URI는 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅 되어 성능 개선되도록 할 수 있다.


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

    클라이언트가 서버로 직접 요청할 경우에는 스킴/호스트/포트번호가 없는 부분 URI를 가진다. 하지만 클라이언트에서 프록시로의 요청은 완전한 URI를 갖는다. 프록시는 서버와 커넥션이 필요하기 때문에 완전한 URI가 필요하다. 가상 호스트의 경우도 마찬가지이다.

    프록시에서는 부분 URI도 지원해야 하는데, 이는 호스트 헤더를 기반으로 완전한 URI를 추출하거나, 과거 이력에서 참조하는데 어떤 방법으로도 완전한 URI를 찾지 못 한다면 클라이언트로 Error 메시지를 보낸다.


    8. 메시지 추적

    많은 기업들이 보안, 비용 절감, 성능 개선 등 다양한 이유로 프록시 서버를 이용하고 있다. 또한 성능 상의 이유로 세계 곳곳에 흩어져 있는 캐시 저장고에 콘텐츠를 복제해 두는 방식이 흔해지고 있다. 이처럼 프록시가 점점 더 흔해지면서, 프록시를 넘나드는 요청의 흐름을 추적하고 문제점을 찾아내는 것도 정말 필요한 일이 되고 있다. 따라서 Via 헤더를 이용하여 메시지 전달을 추적하고, 메시지 루프를 진단하는 것들이 행해지고 있다.

    'Tech > Backend' 카테고리의 다른 글

    Node&Nginx를 PM2로 배포하기  (0) 2020.03.20
    Nginx 탐구하기  (0) 2020.03.19
    Cache  (0) 2019.12.27

    댓글 2

Designed by Tistory.