이번에 자바스크립트 fetch , promise 단계에 들어가니 내 부족한 HTTP 이론에 대해서
뼈저리게 느꼈다.
그리고 웹개발 단톡방에서 나오는 이야기들을 도저히 이해 할 수 없어서 HTTP 공부를 더 열심히 해야겠다고 느꼈다.
웹 중개자
프록시 서버는 클라이언트 입장에서는 트랜잭션을 수행하는 중개인이다.
웹 프록시가 없다면 클라이언트는 서버와 직접적으로 1:1 통신을 하게 된다.
이는 서버 입장에서도 프록시는 클라이언트와의 트랜잭션을 수행시켜주는 중개인이란 점은 동일하다.
이처럼 프록시는 클라이언트 , 호스트의 중개인이기 때문에 클라이언트에겐 올바른 호스트 역할 , 호스트에겐 올바른 클라이언트 역할을 해야 한다.
프록시 vs 게이트웨이
둘 모두 중개인 역할을 하는 것은 동일하지만 중요한점은
프록시는 같은 프로토콜을 이용하는 애플리케이션을 연결 한다.
게이트웨이는 서로 다른 프로토콜을 이용한느 애플리케이션도 연결 한다.
프록시는 그럼 왜 쓰는데 ?
서버와 클라이언트를 직접적으로 연결시키지 않고 프록시라는 중개인을 이용하는 이유는 뭘까 ?
데이터 필터링
예를 들어 요구하는 어떤 것이든 반납하는 호스트 서버가 있다고 이야기 해보자
이 때 어린이들이 해당 서버에 어린이에게 적합하지 않은 정보를 요구할 경우
이를 중재해주는 중개인이 없다면 어린이는 해당 정보를 필터링 없이 받을 수 있다.
하지만 프록시를 사용하면, 접근에 제한을 주어 호스트가 어떤 정보를 주었을 때 해당 정보가 클라이언트에게 적합한지를 판단하고 , 필터링 할 수 있다.
문서 접근 제한
위와 같은 원리로, 회사에서 직급에 따라 접근 가능한 문서의 종류가 다를 때
프록시를 이용하여 직급에 따라 문서에 접근 가능한지, 아닌지를 판단하여 필터링 할 수 있다.
서버측에서 해당 알고리즘을 구현해놔도 되겠지만
높은 확장가능성과 유지 보수성을 위해서 최대한 인터페이스들은 단순하게 계층적인 구조로 이뤄지게 유지 하기 위해 프록시는 중요하다.
보안 방화벽
보안을 강화하기 위해 프록시 서버를 이용한다.
클라이언트가 요청하거나 포스트 한 요청에 대해서 프록시 단에서 호스트에게 해가 갈 수 있는
요청을 막을 수 있다.
웹 캐시
캐싱
캐싱이란 이전에 얻은 데이터나 결과를 저장하여 나중에 동일한 데이터나 결과에 대한 요청에 대해 더 빠르게 응답 할 수 있도록 하는 메커니즘
많은 사람의 클라이언트가 서버에 동일하게 아이폰 출시 뉴스 를 클릭 했다고 해보자
이 때 서버는 많은 사람들의 클라이언트들의 요청이 들어올 때 마다 동일하게 데이터 베이스에서 해당 URL 을 찾고 , 보내고 이러기 보다
가장 먼저 들어온 요청에 대한 응답값을 클라이언트에게 가까운 프록시에 캐싱 해두고 동일한 요청이 들어오면 클라이언트들에게 프록시 단에서 저장되어 있는 캐시 데이터 를 클라이언트에게 제공 할 수 있다.
이는 서버의 부하를 감소시키고 응답 속도를 향상 시킬 수 있다.
콘텐츠 라우터
두 명의 클라이언트가 있을 때 한 클라이언트는 유튜브 프리미엄 회원이고 한 클라이언트는 아니라고 해보자
이 때 동일한 동영상을 클라이언트가 요청했을 때 프록시 단에서는 클라이언트의 상태에 따라 서버 측에 다른 요청을 함으로서 맞춤형 콘텐츠 라우팅이 가능하다.
두 회원이 동일한 동영상을 클릭해도 프록시 단에서 유료 회원에게는 광고가 없는 영상 요청 , 무료 회원에게는 광고가 있는 영상 요청으로 변환해서 프록시가 보낸다.
트랜스 코더
프록시 서버는 콘텐츠를 클라이언트에게 전달하기 전, 본문 포맷을 수정 할 수 있다.
이와 같이 데이터의 표현 방식을 자연스럽게 변환하는 것을 트랜스 코딩이라고 한다.
예를 들어 A회사 의 상품 설명서는 한국어로 작성 되어 있지만
다양한 나라에서 각 나라의 프록시 서버를 거쳐 상품 설명서에 대한 요청을 보내면
프록시 단에서 한국어로 작성된 상품 설명서를 해당 언어로 변환하여 보낸다.
익명화 프록시
프록시라는 중개인을 거쳐 요청을 하게 되면 요청을 보낸 클라이언트의 IP 주소가 어떻게 됐든
서버 측에서는 클라이언트의 IP 가 아닌 거친 프록시의 IP 주소로 요청을 받는다.
이는 사용자의 신원을 식별 할 수 있는 특성을 적극적으로 제거하여 개인정보 보호와 익명성 보장에 기여한다.
프록시 서버 배치
프록시는 어떻게 사용하는지에 따라 배치 하는 위치가 다를 수 있다.
출구(Egress) 프록시
출구 프록시는 클라이언트가 외부 서버에 접근 할 때 클라이언트의 요청을 중개하고 외부 서버에 대한 응답을 받아 다시 클라이언트에게 전달하는 역할을 하는 프록시이다.
이렇게 말하면 더 골치가 아프고
출구 프록시는 호스트의 내부에 존재하는 클라이언트와 호스트 외부에 존재하는 네트워크 사이에 존재한다.
출구 프록시를 통해 내부에서 외부로 나가는 트래픽을 모니터링하고 필터링 하여 호스트 내부 네트워크의 위험을 방지하는 보안 역할을 할 수 있다.
또한 내부 클라이언트의 실제 IP 주소를 외부에 유출 시키지 않아, 서버 내부 네트워크를 익명성을 제공할 수 있다.
또한 내부에서 외부 서버에 대한 접근을 제한 하여 회사 정책이나 사용자 그룹에 따른 접근 제어를 구현 한다.
입구 프록시
입구 프록시는 주로 호스트 외부에 존재하는 클라이언트와 내부 서버 사이에 존재한다.
이는 외부로부터의 요청을 받아 내부 서버로 라우팅 하고, 내부 서버로부터 받은 응답을 다시 외부 클라이언트에게 전달한다.
-
부하 분산
외부에서 오는 다수의 클라이언트 요청을 여러 내부 서버로 분산하여 부하를 균형있게 분배한다. -
애플리케이션 방화벽
외부에서 들어오는 트래픽에 대해 애플리케이션 수준에서의 보안 검사를 수행하여 악성 요청이나 보안 위협을 방지한다. -
접근 제어
특정 클라이언트나 사용자 그룹에 대한 접근 권한을 관리하고, 필요에 따라 특정 리소스에 대한 접근을 제어한다.
대리 프록시
프록시는 종종 대리 프록시 (Reverse Proxy) 라고도 한다.
대리 프록시는 네트워크 가장 끝에 있는 웹 서버들의 바로 앞 에 위치하며, 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청 할 수 있다.
마치 서버처럼 일하는 대리 프록시로 , 웹 서버의 캐시를 속도가 느린 웹 서버 앞에 놓음으로서 성능을 개선 할 수도 있다.
대리 프록시는 서버처럼 일 하기 위해 서버의 이름과 IP 주소로 스스로를 가장하기 때문에 모든 요청은 서버가 아닌 해당 프록시로 가게 된다.
네트워크 교환 프록시
캐시를 이용한 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시하기 위해
충분한 처리 능력을 가진 프록시가 네트워크 사이에 존재 할 수 있다.
프록시 계층
프록시는 계층적 구조를 갖는다.
사이에 여러 개의 프록시가 존재 할 때 자식 부모 관계를 갖는데
프록시의 계층적 구조는 정적으로 고정되어 있는 것이 아닌 동적으로 선택 된다.
예를 들어 프록시 3의 상태가 메롱일 경우 프록시 2는 프록시 3을 거치지 않고 원 서버와 직접적으로 연결하기도 한다.
이를 동적 부모 선택 이라고 한다.
동적 부모 선택의 예시
-
부하 균형
자식 프록시는 부하를 분산하기 위해 부모들의 작업량 수준에 근거하여 부모 프록시를 고른다. -
지리적 인접성에 근거한 라우팅
클라이언트의 지리적 위치에 따라 가까운 위치에 존재한 (더 빠른 서비스를 제공 가능한) 프록시나 다른 서버를 선택 할 수 있다. -
프로토콜/타입 라우팅
클라이언트가 접근하고자 하는 URI 에 근거하여 다른 부모나 원 서버로 라우팅 할 수 있다.
특별한 URI 에 접근 할 경우, 특별한 프록시 서버로 보내져 특별한 프로토콜로 처리 될 수 있다.
- 유료 서비스 가입자를 위한 라우팅
어떻게 프록시가 트래픽을 처리하는가
클라이언트는 웹 서버와 직접 대화하기 때문에 우리는 먼저 어떻게 HTTP 트래픽이 프록시로 향하는 길을 찾아내는지를 알아봐야 한다.
클라이언트를 수정한다.
많은 웹 클라이언트들은 수동 혹은 자동 프록시 설정을 지원한다.
호스트는 클라이언트가 원 서버에 요청을 보내도 의도적으로 원 서버가 아닌 프록시와 연결 시켜버린다.
네트워크를 수정한다.
인터셉트 프록시 라고도 하며, 기존 네트워크 인프라가 존재하여 해당 경로로 요청을 보내도
프록시에서 해당 통신을 인터셉트하여 프록시에서 처리한다.
DNS 이름 공간을 수정한다.
대리 프록시 서버는 호스트 서버 역할을 하기 때문에
웹 서버의 이름이나 IP 주소를 자신이 직접 사용한다.
클라이언트는 요청이 원서버의 DNS 로 보냈기에 원 서버로 갔을 줄 알겠지만 대리 프록시에게 향한다.
웹 서버를 수정한다.
웹 서버는 리다이렉션 명령 (응답 코드 305)을 클라이언트에게 돌려줌으로서 클라이언트의 요청을 프록시에게 리다이렉트 하도록 설정 할 수 있다.
프록시 요청의 미묘한 특징들
프록시 URI 는 서버 URI와 다르다.
웹 서버와 웹 프락시 메시지의 문법은 서로 같지만 예외가 존재한다.
그것은 요청 URI 가 달라진다는 것이다 .
클라이언트가 웹 서버로 요청을 보낼 때 요청 줄은 스킴, 호스트, 포트 번호가 없는 부분 URI 를 가진다.
GET /index.html HTTP/1.0
User-Agent : SuperBrowserv1.3그 이유는 클라이언트와 웹 서버가 프록시 없이 1:1로 연결 되어 있을 때는
3-hand-shaking 이후 연결된 상태에서 단일 서버는 자신의 호스트명 (DNS)과 포트 번호를 알고 있기 때문에
불필요하게 스킴, 호스트, 포트번호 등을 중복적으로 적을 필요가 없었기 때문이다.
하지만 프록시를 이용하게 되면 다음처럼 상대 경로만 존재하는 요청은 문제가 생긴다.
프록시는 클라이언트의 요청을 받은 후 , 웹 서버에 해당 요청을 다시 보내야 하는데
스킴, 호스트, 포트 번호가 존재하지 않기 때문에 웹 서버로 요청을 보낼 수가 없다.
이를 해결하기 위해 프록시는 두 가지 방법을 택했다.
- 클라이언트가 명시적으로 프록시를 이용함을 알고 있을 때에는, 완전한 URI 를 갖도록 하였다.
- 가상으로 호스팅 되는 웹 서버는 호스트와 포트에 대한 정보가 담겨있는
Host헤더를 요구한다.
요청시 주어진 URI에 따라 살펴보자
- 완전한 URI 가 주어졌을 때
- 프록시는 해당 URI 를 사용한다. - 부분 URI 가 주어졌고 Host 헤더가 존재할 때
- 프록시는 Host 헤더를 이용해 원 서버의 이름과 포트 번호를 알아내야 한다. - 부분 URI 가 주어졌지만 Host 헤더가 존재하지 않을 때
-프록시가 원서버를 대신하는대리 프록시라면 프록시 자체에 실제 서버의 주소와 포트 번호가 설정되어있을 가능성이 높다.- 프록시가 인터셉트 프록시가 가로챘던 트래픽을 전달 받았고, 해당 인터셉터 프록시가 원 IP주소와 포트 번호를 사용 할 수 있도록 해뒀다면 해당 호스트 정보를 사용한다.
- 모두 실패했다면 프록시는 원 주소를 알아낼 수 없기 때문에 에러 메시지를 반환한다.
사용자에게 Host 헤더를 지원하는 현대적인 웹 브라우저로 업그레이드 하라고 보낸다.
메시지 추적
오늘날엔 둘 이상의 프록시를 지나게 되는 것은 드문 일이 아니다
많은 회사들이 보안과 비용 절감을 위해 캐시 프락시 서버를 사용하며, 성능 개선과 기능 구현을 위해 프락시 캐시를 사용한다.
이처럼 오늘날 웹 요청의 상당수가 프록시를 지나간다.
그렇기 때문에 기능과 버그들을 해결하기 위해 (프록시들을 제공하는 회사가 여러 개이기에 버전과 기능이 달라 성능을 예측하기 어렵다) 프록시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내야 한다
Via 헤더
Via 헤더는 요청 / 반응이 지나쳐온 프록시의 경로를 저장한다.
AJax공부하느라 만들었던 투두리스트 감시기다 .. 키킥
Response헤더 부분을 보면via : 1.1 vegur가 존재한다.
프록시 인증
프록시는 접근 제어 장치로서 제공 될 수 있다.
HTTP 는 사용자가 유효한 접근 권한 자격을 프록시에 제출하지 않는 한 콘텐츠에 대한 요청을 차단하는 프록시 인증이라는 메커니즘을 정의하고 있다.
이 부분이 제일 흥미로웠다
-
제한된 콘텐츠에 대한 요청이 프록시 서버에 도착했을 때 프록시 서버는 접근 자격을 요구하는
407 Proxy Authorization Required상태 코드와 , 어떻게 그러한 자격을 제출 할 수 있는지 설명해주는Proxy-Authenticate헤더 필드와 함께 반환한다. -
클라이언트는
407응답을 받게 되면 , 로컬 데이터베이스를 확인하든, 사용자에게 물어봐서든 요구되는 자격을 수집한다. -
자격을 획득하면 요구되는 자격을
Proxy-Authorization헤더 필드에 담아서 요청을 다시 보낸다. -
자격이 유효하다면 프록시는 원 요청을 연쇄에 따라 통과 시키며, 유효하지 않다면 407 응답을 보낸다.
프록시 상호 운용성
위에서 앞서 설명했듯이 프록시는 여러 회사에서 개발해서 제공하기 때문에
프록시 간 헤더 필드의 양식이 다를 수도, 지원하는 기능이 다를 수도 있다.
그래서 A 프록시가 보낸 헤더를 B 프록시는 해석 할 수 없을 수 있지만
프록시는 중개인 역할이기 때문에 이해하지 못하는 헤더 필드더라도 그대로 다음 프록시, 혹은 서버나 클라이언트에게 그대로 전달하고, 상대적인 순서 또한 유지한 채 보내야 한다.
철저하게 중개인 역할을 지켜야 한다.
OPTIONS : 어떤 기능을 지원하는지 알아보기
HTTP OPTIONS 메소드는 웹 서버의 특정 리소스가 어떤 기능을 지원하는지 클라이언트 (혹은 프록시) 가 알아볼 수 있게 해준다.
이는 서로 다른 기능 수준의 서버와 프록시가 더 쉽게 상호작용 할 수 있도록 클라이언트는 OPTIONS 를 이용해 서버의 능력을 먼저 알아낼 수 있다.
서버는 클라이언트측으로부터 OPTIONS 메소드를 받으면 상태코드 200 과 함께 Allow 헤더에 해당 리소스가 지원하는 메소드들을 담아 전달한다.
PS . 보면 좋을 동영상
[10분 테코톡] 🐿 제이미의 Forward Proxy, Reverse Proxy, Load Balancer
