왜 우리는 프록시를 써야하고 왜 지금까지 프록시를 써왔는지에 대해서 생각하는 시간을 가져보자.
프록시는 서버나 클라이언트 사이의 중계기쯤 이라고 생각하자.
프록시를 사용한 일련의 과정은 다음과 같다.
비행기 예매 사이트에서 사용자가 운행 시간을 알아본다고 가정해보자.
위의 과정에서 프록시 서버는 말 그대로 중개인의 입지이다.
여기서 중요한 것은 프록시는 서버이면서 동시에 클라이언트이어야 한다는 것이다.
이런 프록시 서버를 그럼 도대체 왜 쓰는 것일까?
이런 귀찮은 과정을 왜 굳이 거쳐가며 해야하는지에 대해서 고민한다면 나는 다음과 같은 답을 줄 수 있다.
위와 같은 멋진 기능들을 수행한다.
보통 프록시를 사용하면 위와 같은 모습으로 구성이 된다.
이제 빠른 인터넷 서핑이 어떻게 가능한지 이야기해보자.
사용자가 서버로 비행기 예약 정보를 검색한다.
그럼 프록시 서버가 해당 응답에 대한 결과를 저장 (캐시)하여 사용자에게 응답해주고, 만약 다른 클라이언트가 같은 요청을 보내면 서버에게 요청하는 것이 아니라 프록시 서버에 존재하는 캐시 데이터를 응답해주게된다.
그럼 사용자는 요청에 따라 프록시 서버에서 바로 결과를 받기 때문에 더욱 빠른 체감으로 서비스를 이용할 수 있게 되는것이다.
이는 프록시 서버의 보안성과 관련된 이야기이다.
클라이언트는 매 요청을 프록시 서버로 요청하기 때문에 실제 리소스가 있는 서버의 IP를 몰라도 된다.
그럼 클라이언트는 실제 리소스가 위치한 서버에 대한 정보를 아무것도 알지 못하고 프록시만 정보를 알기 때문에 실제 리소스가 더 안전하게 보관될 수 있는 것이다.
이 부분은 정말 중요하고 재미있는 개념이다.
이런 현상을 막아주는 개념이 바로 로드 밸런싱이라는 개념인데, 가볍게 무엇이 로드 밸런싱이 무엇이냐면 부하분산 또는 로드 밸런싱은 컴퓨터 네트워크 기술의 일종으로 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미한다.
즉, 서버에 가해지는 부하(=로드)를 분산(=밸런싱)해주는 장치 또는 기술이다.
프록시에는 2가지의 사용 전략이 있다.
이들을 구분하는 것은 네트워크를 기준으로 어디에 위치해 있냐에 따라서 나뉜다.
그리고 우리는 그들을
Forward Proxy
Reverse Proxy
라고 부르기로 했다.
Proxy
일단 프록시의 개념에서 이야기 했던 부분에서 기능만 먼저 짚고 넘어가자.
캐시
프록시 서버를 거치는 요청 및 응답을 모두 확인할 수 있음
필터링을 할 수 있음
데이터 압축, 언어 변환이 가능
이런 공통점이 있는데 우리가 이야기할 Forward & Reverse는 위의 기능 모두 사용할 수 있다.
한 줄로 요약하자면 클라이언트 대신 서버로 요청을 보냄 이다.
이 Forward Proxy에 대해서 그림으로 표현하자면 아마 다음과 같을 것이다.
일반적으로 우리가 컴퓨터를 사용할 때 설정하는 프록시들이 바로 이 포워드 프록시이다.
이런 포워드 프록시는 사용자가 직접 설치하거나 망 관리자가 설치한다.
포워드 프록시의 동작을 글로 표현하자면
클라이언트가 naver.com에 연결하려고 하면 사용자 PC가 직접 연결하는 것이 아니라 포워드 프록시가 해당 요청을 받아서 naver.com에 연결하고 그 결과를 클라이언트에게 전달한다.
이런 포워드 프록시에는 대게 캐싱 기능이 강화되어 성능적으로 네트워크 비용에 대한 감소를 얻을 수 있다.
마찬가지로 한 줄로 요약하자면 서버 대신 클라이언트의 요청을 받음이다.
이 Reverse Proxy에 대해서 그림으로 표현하자면 아마 다음과 같을 것이다.
이는 서버 관리자나 서버 개발자에 의해서 설정될 수 있는데, 대표적으로 Nginx로 리버스 프록시를 설정하기도 한다.
해당 카테고리에 Nginx 카테고리에서 직접 확인 할 수 있다.
이 리버스 프록시에 대한 과정을 이야기하자면
클라이언트가 naver.com에 데이터 요청을 하면 리버스 프록시가 요청을 받아서 내부 서버로 요청을 전달하고 응답을 받아 클라이언트에게 보낸다.
이런 리버스 프록시는 사용자가 리버스 프록시에 대한 서버의 IP만 알기 때문에 보안적인 측면에서 이득을 볼 수 있다.