1. 프록시란?

프록시란 클라이언트와 서버 사이에 위치하여 그들 사이의 HTTP 메시지를 정리하는 중애인이다. 즉,
클라이언트에서 서버로 접속을 할 때 직접적으로 접속하지 않고 중간에 대신 전달해주는 서버를 의미한다.

프록시 서버는 웹 서버이기도 하고 웹 클라이언트이기도 한다. 프록시는 클라이언트 요청을 받고 반드시 웹 서버처럼 요청과 커넥션을 다루고 응답을 돌려줘야 한다. 동시에 요청을 서버로 보내기도 하므로, 요청을 보내고 응답을 받는 클라이언트처럼 동작해야 한다.

1-1. 프록시 서버를 이용한 데이터 통신 과정

1. 클라이언트에서 프록시 서버로 전달할 요청을 보낸다.
2. 프록시 서버는 클라이언트로부터 전달 받은 요청을 서버에 요청한다.
3. 서버는 요청에 맞게 데이터를 프록시 서버로 전달한다.
4. 프록시 서버는 서버로부터 전달 받은 데이터를 클라이언트에 전달한다.

2. 프록시의 두 종류

2-1. 포워드 프록시(Forward Proxy)

포워드 프록시 서버는 위 그림처럼 클라이언트 바로 뒤에 놓여 있다.

클라이언트가 웹 리소스에 대한 액세스를 요청하면 대상 서버로 직접 요청하는 대신 포워드 프록시 서버로 요청을 보냅니다. 그런 다음 정방향 프록시는 요청을 대상 서버로 전달하고 응답을 수신하여 클라이언트로 다시 보냅니다. 클라이언트는 실제 서버의 신원을 인식하지 못합니다.

Forward Proxy는 내부망에서 클라이언트와 Proxy 서버가 통신하여 인터넷을 통해 외부에서 데이터를 가져온다.

포워드 프록시 예)

1. 클라이언트에서 www.example.com과 같은 웹사이트에 요청을 보냅니다.
2. www.example.com으로 직접 요청을 보내는 대신 클라이언트가 포워드 프록시 서버로 요청을 보냅니다.
3. 포워드 프록시 서버는 요청을 실제서버(www.example.com)에게 전달합니다.
4. 실제서버는 포워드 프록시 서버에게 응답을 다시 보냅니다.
5. 응답을 받은 포워드 프록시 서버는 이를 클라이언트에게 전달합니다.

2-1-1. 포워드 프록시의 장단점

장점 단점

2-2. 리버스 프록시(Reverse Proxy)

리버스 프록시는 위 그림 처럼 웹서버 or WAS 앞에 놓여 있는 것을 말한다.

클라이언트는 웹서비스에 접근할때 웹서버에 요청하는 것이 아닌, 프록시로 요청하게 되고, 프록시가 배후(reverse)의 서버로부터 데이터를 가져오는 방식이다.

클라이언트쪽으로 데이터(response)를 밀어주는게 포워드라면, 그 반대편인 서버 쪽으로 데이터(request)를 밀어주는 것이 리버스 프록시 라고 보면 된다.

Reverse Proxy는 내부망에서 Proxy 서버와 내부망서버가 통신하여 인터넷을 통해 요청이 들어오면 Proxy 서버가 받아 응답해준다.

리버스 프록시 예)

1. 사용자가 www.example.com을 요청합니다.
2. 요청이 리버스 프록시 서버로 이동합니다.
3. 리버스 프록시 서버는 로드, 위치 또는 기타 요소를 기반으로 요청을 처리해야 하는 백엔드 웹 서버를 결정합니다.
4. 선택한 백엔드 서버로 요청을 전달합니다.
5. 백엔드 서버는 요청을 처리하고 응답을 리버스 프록시로 다시 보냅니다.
6. 그러면 리버스 프록시가 사용자에게 응답을 보냅니다.

2-2-1. 리버스 프록시의 장단점

장점 단점

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

1. 요청(request)시 프록시 URL과 서버 URL의 차이
   • 클라이언트가 웹 서버로 요청할 때, 요청줄에 스키마(http://), 호스트명(www.example.com), 포트번호(80)가 없는 부분 URL를 가진다.
     • 클라이언트가 프록시를 사용하지 않도록 설정되어 있다면, 부분 URL를 보낸다.
   • 클라이언트가 프록시 서버로 요청할 때, 완전한 URL를 가진다.
     • 클라이언트가 프록시를 사용하도록 설정되어 있다면, 완전한 URL를 보낸다.

2. 프록시 요청과 서버 요청을 다룰 수 있는 프록시 서버
   • 트래픽이 프록시 서버로 리다이렉트 될 수 있는 여러 가지 방법이 존재하기 때문에, 다목적 프록시 서버는 요청 메시지의 완전한 URL과 부분 URL를 모두 지원해야 한다.
     • 완전한 URL이 주어졌다면, 프록시는 그것을 사용해야 한다.
     • 부분 URL이 주어졌고 Host 헤더가 있다면, Host 헤더를 이용해 실 서버의 이름과 포트 번호를 알아내야 한다.
     • 부분 URL이 주어졌으나 Host 헤더가 없는 경우
       • 프록시가 실 서버를 대신하는 대리 프록시라면 프록시에 실제 서버의 주소와 포트 번호가 설정되어 있을 수 있다.
       • 어떤 인터셉트 프록시가 가로챘던 트래픽을 받았고, 그 인터셉트 프록시가 실 서버의 IP 주소와 포트 번호를 사용할 수 있도록 해뒀다면 그 IP 주소와 포트 번호를 사용할 수 있다.

4. 양방향 통신 간 프록시의 메시지 흐름

4-1. Via 헤더

Via 헤더 필드는 메시지가 지나는 각 중간 노드(프록시 or 게이트웨이)의 정보를 나열한다.
메시지가 또 다른 노드를 지날 때마다 중간 노드는 Via 헤더 목록의 끝에 반드시 추가되어야 한다.
Via 헤더는 요청과 응답 모두 표시될 수 있으며 메시지 전달을 추적하고 요청 루프를 피하며 요청/응답에서 발신자의 프로토콜 기능을 식별하는 데 사용됩니다.

4-1-1. Via 헤더 구성요소

1. 프로토콜 이름
   • 중개자가 받은 프로토콜이 HTTP라면 프로토콜 이름은 없어도 된다.
   • 프로토콜 이름은 버전 앞에 “/”로 구분되어 붙는다.
2. 프로토콜 버전
   • 수신한 메시지의 버전
3. 노드 이름
   • 만약 포트가 포함되어 있지 않다면, 사용하는 프로토콜의 기본 포트라고 간주할 수 있다.
   • 호스트 명을 가명으로 대체할 수 있다.
4. 노드 코멘트
   • 중개자 노드를 서술하는 선택적인 코멘트

4-2. TRACE 메소드

HTTP/1.1의 TRACE 메소드는 요청 메시지를 프록시의 연쇄를 따라가면서 어떤 프록시를 지나가고 어떻게 각 프록시가 요청 메시지를 수정하는지 관찰/추적할 수 있도록 해준다. 프록시 흐름을 디버깅하는데 매우 유용하다.

요청의 최종 수신자(실제서버)는 전체 요청 메시지를 HTTP응답 메시지의 본문에 포함시켜 송신자에게 그대로 돌려보낸다. TRACE 메소드 응답의 Content-Type은 message/http이며 상태는 200OK이다.

Max-Forwards 참고 : https://withbundo.blogspot.com/2017/08/http-15-http-v-max-forwards-proxy.html