프록시란?
- (대개) 보안상의 이유로 직접 통신을 지양하는 두 종단간 중계 기능을 하는 것
- 서버 입장에선 프록시가 클라이언트 역할, 클라이언트 입장에선 프록시가 서버 역할 하는 것으로 보임
- 캐싱 역할
- 요청을 기억하고 있다가, 동일한 요청이 올 때 같은 응답을 주도록
- 이 캐싱에서 요청에 대한 응답 처리가 된다면 실제 원격 서버까지 전달되지 않아도 됨.
- 다양한 기능을 수행
- 캐싱 - 공개 또는 비공개가 될 수 있음. (e.g. 브라우저 캐시)
- 필터링 - 바이러스 백신 스캔, 유해 사이트 차단
- 로드밸런싱 - 여러 서버들이 서로 다른 요청 처리하도록
- 인증 - 다양한 리소스에 대한 접근 제어
- 로깅 - 이력 정보 저장
- 애플리케이션 계층에서 동작
Proxy server
Forward Proxy
: 목적지에 직접 접근하지 않고 프록시를 통해 데이터를 주고 받기 위해 사용하는 프록시
- 서버 입장에서 클라이언트가 누군지 모르게 됨
- 프록시의 IP를 통해 전달받음
- 사용자가 프록시에 리소스를 요청하면, 요청된 리소스를 원격 서버에서 가져와 사용자에게 돌려줌.
- 만약 캐시에 있다면, 캐싱된 데이터로부터 제공
- 사용자는 웹 브라우저를 이용해 프록시 서버 사용 설정. (사용자가 프록시 서버에 연결되었다는 것을 알 수 있음)
- 접근 정책 구현 측면에서 다루기 쉽고 비용 저렴
forward proxy 사례
: 아이폰에서 proxy 설정을 하게 되면 네이버로 http요청을 하든 넷플릭스로 http 요청을 하든 해당 Proxy로 응답을 받는다. 예를 들어, 해외 거주자의 경우 네이버 tv 캐스트가 지원이 되지 않는데(판권 문제로), 이 때 아이폰에서 proxy 설정을 해서 우리나라의 proxy로 받도록 하고, 아이폰은 이 proxy에 접속해 영상을 재생할 수 있다.
Reverse Proxy(보안 측면)
: 사용자가 요청을 하는 End-point가 실 서버가 아니라 이 리버스 프록시 서버가 됨
- 프록시 서버를 인터넷 resource 앞에 위치 시켜, 클라이언트가 요청을 할 때 리버스 프록시를 호출하도록 함
- 클라이언트 입장에서 서버가 누군지 모르게 됨 - 사용자가 실제 리소스에 직접 접근하는 것 처럼 느껴짐
- 실제 서버의 IP 등 정보를 알 수가 없음
- 사용자가 reverse proxy로 설정된 서버에 데이터를 요청하면 프록시 서버가 요청을 받아, 실제 내부서버로부터 데이터를 받아옴.
- 리버스 프록시 서버를 두고 실제 서비스 서버는 내부망에 위치. 프록시 서버만 내부의 서비스 서버와 통신해 결과를 클라이언트에게 제공
- e.g.) 아파치 웹 서버를 이용 시 웹 서버는 톰캣의 8080, 8009 포트만 접근하고, 아파치 웹 서버가 해킹당해도 내부망으로는 연결이 불가
- 각 요청에 대한 데이터가 캐싱되어, 부하 조절 기능
reverse proxy 사례
: 대부분의 서비스들의 아키텍처를 생각해보면, 웹 어플리케이션 서버는 웹 서버의 뒷단에 존재할텐데, 웹 어플리케이션 서버가 어디에 위치하는지는 사용자가 알 필요 없다. 그냥 사용자는 웹 서버에 요청하면 웹 서버가 WAS에 요청하고, 받아온 resource를 웹서버가 사용자에게 돌려줄테니
Reference)
HTTP 완벽 가이드
http://blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=221190043948&redirect=Dlog&widgetTypeCall=true&directAccess=false
https://milkye.tistory.com/202
https://brownbears.tistory.com/191