Proxy
'대리', '대신'이라는 뜻을 가지며, 프로토콜에 있어서는 대리 응답 등에서 사용하는 개념이다.
클라이언트와 서버 사이에 존재하며, 중계기로서 대리로 통신을 수행하는 것을 Proxy라고 하며, 그 중계 기능을 하는 주체를 Proxy Server라고 한다.
Proxy 서버의 특징
프록시 서버는 클라이언트와 서버의 입장에서 볼 때 서로 반대의 역할을 하는 것처럼 보여지게 된다.
클라이언트가 프록시를 바라보면 프록시가 '서버'와 같이 동작을 하게 되는 것이고, 반대로 서버가 프록시를 바라보면 '클라이언트'처럼 작동을 하게 되는 것이다.
Proxy 서버를 이용한 데이터 통신 과정
- 클라이언트에서 프록시 서버로 전달할 요청을 보낸다.
- 프록시 서버는 클라이언트로부터 전달 받은 요청을 서버에 요청한다.
- 서버는 요청에 맞게 데이터를 프록시 서버로 전달한다.
- 프록시 서버는 서버로부터 전달 받은 데이터를 클라이언트에 전달한다.
Proxy 서버의 메커니즘
- 요청된 데이터 또는 페이지가 로컬 캐시에 이미 있는 경우 프록시 서버 자체가 필요한 검색을 클라이언트에 제공
- 요청한 데이터 또는 페이지가 로컬 캐시에 없는 경우 프록시 서버는 해당 요청을 대상 서버로 전달
- 프록시 서버는 클라이언트에 응답을 전송하고 또한 클라이언트에 캐시됨
Proxy의 장점
- 프록시 서버 중 일부는 프록시 서버에 요청된 내용들을 캐시를 이용하여 저장함
- 캐시 안에 있는 정보를 요구하는 요청이 들어온다면 원격 서버에 접속하지 않아도 됨
- 전송 시간을 절역하고 불필요한 외부와의 연결을 하지 않아 외부와의 트래픽이 감소함 → 네트워크 병목 현상 방지 효과를 가진다.
Proxy 사용하는 이유
- 익명으로 컴퓨터를 유지(주로 보안을 위함)
- 캐시를 사용하여 접근을 빠르게 하기 위함
- 보안 및 통제를 뚫고 나가기 위함
- 바이러스 전파, 악성 루머 전파, 다른 정보들을 빼낼 목적
- 역으로 IP 추적을 당하지 않기 위함
- 지역 제한을 우회하기 위함
- etc.
Proxy 종류
포워드 프록시(Forward Proxy)
보통 말하는 프록시가 포워드 프록시로 Client와 Server 사이에 위치하여 요청을 중계하며, 요청과 응답은 Proxy Server를 거친다.
클라이언트를 감추는 효과가 있다.
장점
- 캐시 저장(액세스 고속화)
프록시 서버에 캐시를 저장할 수 있다. 다시 동일한 페이지를 요청하면 캐시에 남아있는 정보를 클라이언트에게 준다.
- URL 필터링
외부의 액세스는 프록시 서버를 경유하므로 사용자 전원의 외부 웹 사이트로의 액세스를 필터링할 수 있다.
- 암호화(Encryption)
클라이언트의 요청은 포워드 프록시 서버를 통과할 때 암호화된다. 클라이언트의 ip를 감춰서 보안 효과를 내는데 본 서버에서 IP를 추적해도 포워드 프록시 서버 IP만 보인다.
단점
- 단일 실패 지점
포워드 프록시 서버가 다운되면 이를 사용하는 모든 사용자의 인터넷 액세스가 중단되어 가동 중지 시간이 발생할 수 있다.
- 성능 오버헤드
모든 요청과 응답이 포워드 프록시를 통과해야 하므로 성능 오버헤드가 발생할 수 있다. 프록시 서버의 전력이 부족하거나 과부화된 경우 지연 시간이 발생할 수 있다.
리버스 프록시(Reverse Proxy)
포워드 프록시와 마찬가지로 요청과 응답이 Proxy Server로 이동하는데, 포워드 프록시와 다르게 Server들이 주로 내부망으로 구성되며 프록시에게만 연결을 허용한다. 즉, 서비스를 위한 보안 채널을 구축한다.
이런 경우 Client가 Server에 직접 접근이 불가능하므로, Reverse Proxy에서 요청을 적극적으로 중계하는 Load Balancing의 역할을 수행하기도 한다.
서버를 감추는 효과가 있다.
장점
- 부담 분산
설정으로 정적 콘텐츠와 동적 콘텐츠의 보는 곳을 나눔으로써 메모리 사용량의 효율화를 할 수 있다. 로드 밸런스와 병용하면 더욱 부담을 분산할 수 있다.
- 캐시의 저장
포워드 프록시와 동일하게 동일한 데이터를 얻을 때 프록시 서버에 저장했던 내용을 돌려준다.
- 보안 대책, 바이러스 대책
통신시 프록시 서버에 집약되므로 프록시 서버 내에 보안 대책, 바이러스 대책을 구현하여 Web 서버로의 부정 액세스, 사용등을 방지할 수 있다.
- 암호화(Encryption)
SSL 암호화에도 좋다. 본래 서버가 클라이언트들과 통신을 할때 SSL(or TSL)로 암호화, 복호화를 할 때 비용이 많이 드는데 리버스 프록시를 사용하면 들어오는 요청을 모두 복호화하고 나가는 응답을 암호화해주므로 클라이언트와 안전한 통신을 할 수 있으며 본래 서버의 부담을 줄여줄 수 있다.
단점
- 단일 실패 지점
리버스 프록시 자체가 사용할 수 없게 되면 모든 클라이언트의 백엔드 서버에 대한 액세스가 중단되어 잠재적으로 가동 중지 시간이 발생할 수 있다.
- 복잡성
리버스 프록시를 구현하고 관리하는 것은 특히 여러 백엔드 서버가 있는 환경에서 복잡할 수 있다. 구성이 잘못되면 서비스가 중단될 수 있다.
- 리소스 집약적
리버스 프록시는 특히 트래픽이 많은 환경에서 들어오는 트래픽을 처리하기 위해 리소스(하드웨어 및 소프트웨어)가 필요하므로 인프라 비용이 추가될 수 있다.
