2부: HTTP 아키텍처
06장. 프락시
🔔 오늘의 학습 내용
- HTTP 프락시와 웹 게이트웨이를 비교하고 HTTP 프락시가 어떻게 배치되는지?
- 프락시가 실제 네트워크에 어떻게 배치되어 있는지 그리고 트래픽이 어떻게 프락시 서버로 가게 되는지 설명한다.
- 브라우저에서 프락시를 사용하려면 어떻게 설정해야하는가?
- HTTP 프락시 요청이 서버 요청과 어떻게 다른지, 그리고 프락시가 어떻게 브라우저의 동작을 미묘하게 바꾸는지 보여준다.
- 일련의 프락시 서버들을 통과하는 메시지의 경로를, Via 헤더와 TRACE 메서드를 이용해 기록하는 방법을 설명한다.
- 프락시에 기반한 HTTP 접근 제어를 설명한다.
🎨 01. 웹 중개자
- 웹 프락시 서버는 클라이언트의 입장에서 트랜잭션을 수행하는 중개인이다.
- 웹 프락시가 없다면, 클라이언트는 HTTP 서버와 직접 이야기한다.
- 웹 프락시가 있다면, 클라이언트는 HTTP 서버와 이야기하는 대신 자신의 입장에서 서버와 대화해주는 프락시와 이야기한다.
- 트랜잭션을 완료하는 것이 클라이언트라는 점은 변하지 않지만, 프락시 서버가 제공하는 좋은 서비스를 이용하게 된다.
- HTTP 프락시 서버는 웹 서버이면서 동시에 웹 클라이언트이기도 하다.
- 프락시는 HTTP 클라이언트의 요청을 받게 되므로, 반드시 웹 서버처럼 요청과 커넥션을 적절히 다루고 응답을 돌려줘야한다.
📌 개인 프락시와 공유 프락시
- 프락시 서버는 하나의 클라이언트가 독점적으로 사용할 수도 있고, 여러 클라이언트가 공유할 수도 있다.
- 하나의 클라이언트만을 위한 프락시를 개인 프락시라고 부르고, 여러 클라이언트가 함께 사용하는 프락시는 공용 프락시라고 부른다.
💎 공용 프락시
- 대부분의 프락시는 공용이며 공유된 프락시다.
- 중앙 집중형 프락시를 관리하는게 더 비용 효율이 높고 쉽다.
- 캐시 프락시 서버와 같은 몇몇 프락시 애플리케이션은 프락시를 이용하는 사용자가 많을수록 유리한데, 여러 사용자들의 공통된 요청에서 이득을 취할 수 있기 때문이다.
💎 개인 프락시
- 개인 전용 프락시는 흔하지는 않지만, 꾸준히 사용되고 있다.
- 어떤 브라우저 보조 제품들은 몇몇 ISP 서비스와 마찬가지로 브라우저의 기능을 확장하거나 성능을 개선하거나 무료 ISP 서비스를 위한 광고를 운영하기 위해 작은 프락시를 사용자의 컴퓨터에서 직접 실행한다.
📌 프락시 대 게이트웨이
- 프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고,
게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다. - 게이트웨이는 클라이언트와 서버가 다른 프로토콜로 말하더라도 서로 간의 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 동작한다.
- 그림 (a)의 중개 장치는 클라이언트와 서버 양쪽 모두에게 HTTP로 말하므로 프락시다.
- 그림 (b)의 중개 장치는 HTTP 프론트엔드에 매여서 POP 이메일 백엔드를 향하고 있으므로 HTTP/POP 게이트웨이다.
- 이 게이트웨이는 웹 트랜잭션을 적절한 POP 트랜잭션으로 변환하고,
사용자가 이메일을 HTTP를 통해 읽을 수 있게 한다. - 야후! 메일이나 MSN 핫메일과 같은 웹 기반 이메일 프로그램은 HTTP 이메일
게이트웨이이다.
- 이 게이트웨이는 웹 트랜잭션을 적절한 POP 트랜잭션으로 변환하고,
💎 둘의 차이점?
- 실질적으로 프락시와 게이트웨이의 차이점은 모호하다.
- 브라우저와 서버는 다른 버전의 HTTP를 구현하기 때문에, 프락시는 때때로 약간의 약간의 프로토콜 변환을 하기도 한다.
- 상용 프락시 서버는 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근, 그리고 웹 기반 애플리케이션을 지원하기 위해 게이트웨이 기능을 구현한다.
🎨 02. 왜 프락시를 사용하는가?
- 프락시 서버는 보안을 개선하고, 성능을 높여주며, 비용을 절약한다.
- 프락시 서버는 모든 HTTP 트래픽을 들여다보고 건드릴 수 있기 때문에,
부가적인 가치를 주는 여러 유용한 웹 서비스를 구현하기 위해 트래픽을 감시하고 수정할 수 있다.
💎 어린이 필터
- 초등학교 어린이들에게 교육 사이트를 제공하면서 동시에 성인 콘텐츠를 차단하기 위해 필터링 프락시를 사용할 수 있다.
💎 문서 접근 제어자
- 프락시 서버는 많은 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적(audit trail)을 하기 위해 사용될 수 있다.
- 각기 다른 조직에서 관리되는 다양한 종류의 수많은 웹 서버들을에 대한 접근 제어를 수시로 갱신할 필요 없이, 중앙 프락시 서버에서 접근 제어를 설정할 수 있다.
🔔 중앙화된 접근 제어 프락시는 다음과 같은 일을 한다.
- 클라이언트A에게 제약 없이 서버의 뉴스 페이지에 접근할 수 있도록 허가한다.
- 클라이언트B에게 제약 없이 인터넷 컨텐츠에 접근할 수 있는 권한을 준다.
- 클라이언트C에게 서버 B에 접근하기 전에 먼저 비밀번호를 요구한다.
💎 보안 방화벽
- 네트워크 보안 엔지니어는 종종 보안을 강화하기 위해 프락시 서버를 사용한다.
- 프락시 서버는 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제한다.
- 또한 바이러스르 제거하는 웹이나 이메일 프락시가 사용할 수 있는, 트래픽을 세심히 살펴볼 수 있는 후크(hook)를 제공한다.
💎 웹 캐시
- 프락시 캐시는 인기 있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공하여 느리고 비싼 인터넷 커뮤니케이션을 줄인다.
💎 대리 프락시
- 어떤 프락시들은 웹 서버인 것 처럼 위장한다.
- 그렇기 때문에 대리 혹은 리버스 프락시로 불리는 이들은 진짜 웹 서버 요청을 받지만, 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 시작한다.
- 대리 프락시는 공용 콘텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용될 수 있다.
- 이런 식으로 사용하는 대리 프락시를 흔히 서버 가속기라고 부른다.
- 대리 프락시는 도한 콘텐츠 라우팅 기능과 결합되어 주문형 복제 콘텐츠의 분산 네트워크를 만들기 위해 사용될 수 있다.
💎 콘텐츠 라우터
- 프락시 서버는 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작할 수 있다.
- 콘텐츠 라우터는 또한 사용자들에게 제공할 여러 서비스를 구현하는데 사용할 수 있다.
💎 트랜스코더
- 프락시 서버는 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있다.
- 이와 같이 데이터의 표현 방식을 자연스럽게 변환하는 것을 트랜스코딩이라고 한다.
- 트랜스코딩 프락시는 크기를 줄이기 위해 자신을 거쳐 가는 GIF 이미지를 JPG로 변환할 수 있다.
- 마찬가지로 txt 파일은 압축될 수 있고, 인터넷을 이용할 수 있는 무선 호출기와 스마트폰을 위해 작은 텍스트로 줄인 웹페이지를 생성할 수 있다.
💎 익명화 프락시(Anonymizer)
- 익명화 프락시는 HTTP 메시지에서 신원을 식별할 수 있는 특성들(ex. 클라이언트 ID 주소, From 헤더, Refer 헤더, 쿠키 등)을 적극적으로 제거함으로써 개인 정보 보호와 익명성 보장에 기여한다.
🔔 익명화 프락시는 개인 정보 보호를 위해 사용자의 메시지를 이렇게 변경한다.
- User-Agent 헤더에서 사용자의 컴퓨터와 OS의 종류를 제거한다.
- 사용자의 이메일 주소를 보호하기 위해 From 헤더는 제거된다.
- 어떤 사이트를 거쳐서 방문했는지 알기 어렵게 하기 위해 Refer 헤더는 제거된다.
- 프로필과 신원 정보를 없애기 위해 Cookie 헤더는 제거된다.
🎨 03. 프락시 서버는 어디에 있는가?
📌 프락시 서버 배치
- 어떻게 사용할지에 따라서 프락시는 어디에든 배치할 수 있다.
💎 출구(Egress) 프락시
- 로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프락시를 로컬 네트워크의 출구에 넣을 수 있다.
- 악의적인 해커들을 막는 방화벽 제공을 위해
- 인터넷 요금을 절약하고 인터넷 트래픽의 성능을 개선하기 위해
- 초등학교 학생들이 부적절한 컨텐츠 브라우징 하는 것을 막기 위해
- 필터링 출구 프락시를 사용할 수 있다.
💎 접근(입구) 프락시
- 고객으로부터의 모든 요청을 종합적으로 처리하기 위해 프락시는 ISP 접근 지점에 위치하기도 한다.
- ISP는 사용자들의 다운로드 속도를 개선하고, 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용해 많이 찾는 문서들의 사본을 저장한다.
💎 대리 프락시
- 프락시는 종종 대리 프락시(리버스 프락시라고도 한다.)로 사용된다.
- 대리 프락시는 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 ㅅ버에게 자원을 요청할 수 있다.
- 또한 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 높음으로써 성능을 개선할 수 있다.
- 대리 프락시는 일반적으로 웹 서버의 이름과 IP 주소로 스스로를 가장하기 때문에 모든 요청은 서버가 아닌 이 프락시로 가게 된다.
💎 네트워크 교환 프락시
- 캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시하기 위해
충분한 처리 능력을 갖춘 프락시가 네트워크 사이의 인터넷 피어링
교환 지점들에 놓일 수 있다.
📌 프락시 계층
- 프락시 계층에서, 메시지는 최종적으로 원 서버에 도착할 때 까지 프락시와 프락시를 거쳐 이동한다.
- 그 후 다시 프락시들을 거쳐 클라이언트로 돌아온다.
- 프락시 계층에서 프락시 서버들은 부모와 자식의 관계를 갖는다.
- 다음번 인바운드 프락시(서버에 가까운 쪽)를 부모라고 부르고, 다음번 아웃바운드 프락시(클라이언트 가까운 쪽)는 자식이라고 부른다.
📌 프락시 계층 컨텐츠 라우팅
- 프락시 계층은 정적이다.
- 프락시 1은 언제나 메시지를 프락시 2, 3으로 보내고, 다음 프락시로 보낸다.
- 그러나 계층이 반드시 정적이어야 하는 것은 아니다.
- 프락시 서버는 여러 가지 판단 근거에 의해 메시지를 다양하고 유동적인 프락시 서버와 원 서버들의 집합에게 보낼 수 있다.
💎 동적 부모 선택의 예 - 01. 부하 균형
- 자식 프락시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거하여 부모 프락시를 고른다.
💎 동적 부모 선택의 예 - 02. 지리적 인접성에 의한 라우팅
- 자식 프락시는 원 서버의 지역을 담당하는 부모를 선택할 수도 있다.
💎 동적 부모 선택의 예 - 03. 프로토콜/타입 라우팅
- 어떤 자식 프락시는 URI에 근거하여 다른 부모나 원 서버로 라우팅할 수 있다.
- 어떤 특정 종류의 URI를 갖고 있는 요청의 경우, 특별한 프락시 서버로 보내져 특별한 프로토콜로 처리될 수도 있다.
💎 동적 부모 선택의 예 - 04. 유료 서비스 가입자를 위한 라우팅
- 웹서비스 운영자가 빠른 서비스를 위해 추가금을 지불했다면, 그들의 URI는 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅 될 수 있다.
💡 동적 부모 라우팅 로직은 제품(설정 파일, 스크립트 언어, 동적으로 실행 가능한
ㅤ 플러그인 등)마다 다르게 구현된다.
📌 어떻게 프락시가 트래픽을 처리하는가
- 클라이언트 트래픽이 프락시로 가도록 만드는 방법에는 다음 네 가지가 있다.
💎 클라이언트를 수정한다.
- 구글 크롬과 마이크로소프트의 브라우저를 포함한 많은 웹 클라이언트들은 수동 혹은 자동 프락시 설정을 지원한다.
- 만약 클라이언트가 프락시를 사용하도록 설정되어 있다면, 클라이언트는 HTTP 요청을 바로 그리고 의도적으로 원 서버가 아닌 프락시로 보낸다.
💎 네트워크를 수정한다.
- 클라이언트는 알지도 못하고 간섭도 할 수 없는 상태에서, 네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 조정하는 몇 가지 기법이 있다.
- 이 가로챔은 일반적으로 HTTP 트래픽을 지켜보고 가로채어 클라이언트 모르게 트래픽을 프락시로 보내는 스위칭 장치와 라우팅 장치를 필요로 한다.
- 이것을 인터셉트 프락시라고 부른다.
💎 DNS 이름공간을 수정한다.
- 웹 서버 앞에 위치하는 프락시 서버인 대리 프락시는 웹 서버의 이름과 IP주소를 자신이 직접 사용한다.
- 그래서 모든 요청은 서버 대신 대리 프락시로 간다.
- 이는 DNS 이름 테이블을 수동으로 편집하거나 사용할 적절한 프락시나 서버를 계산해주는 특별한 동적 DNS 서버를 이용해서 조정될 수 있다.
💎 웹 서버를 수정한다.
- 몇몇 웹 서버는 HTTP 리다이렉션 명령(305코드)을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트 하도록 설정할 수 있다.
- 리다이렉트를 받는 즉시 클라이언트는 프락시와의 트랜잭션을 시작한다.
🎨 클라이언트 프락시 설정
💡 모든 현대적인 브라우저는 프락시를 사용할 수 있도록 설정할 수 있다.
ㅤ 사실 많은 브라우저가 프락시를 설정하는 여러 가지 방법을 제공한다.
💎 수동 설정
- 프락시를 사용하겠다고 명시적으로 설정한다.
💎 브라우저 기본 설정
- 브라우저 벤더나 배포자는 브라우저(혹은 다른 웹 클라이언트)를 소비자에게 전달하기 전에 프락시를 미리 설정해 놓을 수 있다.
💎 프락시 자동 설정(Proxy auto-configuration, PAC)
- 자바스크립트 프락시 자동 설정(PAC) 파일에 대한 URI를 제공할 수 있다.
- 클라이언트는 프락시를 써야 하는지, 만약 그렇다면 어떤 프락시 서버를 써야 하는지 판단하기 위해서 그 자바스크립트 파일을 가져와서 실행한다.
💎 WAPD 프락시 발견
- 대부분의 브라우저는 자동설정 파일을 다운받을 수 있는 '설정 서버'를 자동으로 찾아주는, 웹 프락시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol, WAPD)을 제공한다.
📌 클라이언트 프락시 설정: PAC 파일
- 수동 프락시 설정은 단순하지만 반면에 유연하지 못하다.
- 모든 컨텐츠를 위해 단 하나의 프락시 서버만을 지정할 수 있고, 장애 시의 대체 작동에 대한 지원도 없다.
- 또한 수동 프락시 설정은 큰 조직에서는 관리 문제를 야기한다.
- 설정된 브라우저가 매우 많다면, 그 모두를 원하는 대로 변경하는 것은 어렵거나 불가능하다.
- 프락시 자동 설정(PAC) 파일은 프락시 설정에 대한 보다 동적인 해결책이다.
- 프락시 설정을 상황에 맞게 계산해주는 작은 자바스크립트 프로그램이기 때문이다.
- 문서에 접근할 때마다, 자바스크립트 함수가 적절한 프락시 서버를 선택한다.
- PAC 파일을 사용하려면, 자바스크립트 PAC 파일의 URI를 브라우저에 설정해야한다.
📌 클라이언트 프락시 설정: WPAD
- 브라우저 설정을 위한 또 다른 매커니즘은 웹 프락시 자동발견 프로토콜(WPAD)이다.
- WPAD는 여러 발견 매커니즘들의 상승 전략을 이용해 브라우저에게 알맞은 PAC 파일을 자동으로 찾아주는 알고리즘이다.
- WPAD 프로토콜이 구현된 클라이언트가 하게 될 일은 다음과 같다.
- PAC URI를 찾기 위해 WPAD를 사용한다.
- 주어진 URI에서 PAC 파일을 가져온다.
- 프락시 서버를 알아내기 위해 PAC 파일을 실행한다.
- 알아낸 프락시 서버를 이용해서 요청을 처리한다.
- WPAD는 올바른 PAC 파일을 알아내기 위해 일련의 리소스 발견 기법을 사용한다.
- 여러 가지 발견 기법을 사용하게 되는데, 모든 조직이 모든 기법을 사용할 수 있는 것은 아니기 때문이다.
- WPAD는 성공할 때까지 각 기법을 하나씩 시도해본다.
- 현재의 WPAD 명세는 다음의 기법을 순서대로 정의한다.
- 동적 호스트 발견 규약(DHCP)
- 서비스 위치 규약(SLP)
- DNS 잘 알려진 호스트 명
- DNS SRV 레코드
- DNS TXT 레코드 안의 서비스 URI
📌 프락시 요청의 미묘한 특징들
💎 프락시 URI는 서버 URI와 다르다
- 웹 서버와 웹 프락시 메시지의 문법은 서로 같지만, 한 가지 예외가 있다.
- 클라이언트가 프락시 대신 서버로 요청을 보내면 요청의 URI가 달라진다.
- 클라이언트가 웹 서버로 요청을 보낼 때, 요청줄은 다음의 예와 같이 스킴, 호스트, 포트번호가 없는 부분 URI를 가진다.
- 그러나 클라이언트가 프락시로 요청을 보낼 때, 요청줄은 다음의 예와 같이 완전한 URI를 갖는다.
💎 가상 호스팅에서 일어나는 같은 문제
꾸준함의 가치를 믿는 개발자