역외의 서버에서 로깅과 로그에 대한 학습이 일어나고, 프론트에서 클릭이나 노출 로그를 넘겨주어야 하는 요구사항. 클릭 로그의 파이프라인 상에 RD / Proxy란 표시가 있어서 뭘까 좀 궁금했다. 대충 찾다보니 원하는 정확한 답을 얻을 수 있을지는 좀 의문이지만, 적어도 proxy랑 redirect가 웹에서 어떤 역할인지 정도는 정리하고 가도 되지 않을까.
Proxy
사전적 의미로는 '대리' '대행'이다. 프록시 서버는 컴퓨터, 모바일 등 엔드유저 (client) 와 웹페이지, 파일, 비디오 등을 호스팅하는 인터넷 서버 사이에서 중계 역할을 한다.
즉, 클라이언트가 직접 본래 서버에 요청을 하는 게 아니라 프록시 서버를 거쳐 요청을 넣고, 서버 역시 프록시 서버를 거쳐 응답을 제공하는 것이다. 이때 프록시 서버는 요청에 대한 복잡도를 계산해 로드 밸런싱 상에서 이점을 얻을 수도 있다. 또한 클라이언트 입장에서 프록시 서버를 이용함으로써 얻는 이점은 요청의 발원지를 마스킹할 수 있다는 점이다.
open proxy vs reverse proxy
open proxy
원래는 여기까지 다룰 생각 없었는데 서버 사이드의 이점을 살펴보니 reverse proxy 쪽이 더 중요해보였다. open proxy는 어떤 인터넷 사용자든 접근할 수 있는 프록시 서버를 의미한다. 특히 클라이언트 측의 IP를 숨겨주는 anonymous proxy가 있고, 프록시 서버의 기능 중 캐시를 활용한 빠른 리턴에 더 방점이 찍혀있고 클라이언트 측의 IP는 그대로 넘겨주는 transparent proxy도 있다.
reverse proxy
이건 클라이언트 입장에서 본 서버를 모르게 하는 방법이다. 클라이언트는 웹 서버들 중 어느 서버에서 응답이 오는지 모르게 되는데, 이런 방식의 리버스 프록시 서버를 사용하는 이유에는 여러 가지가 있다.
- SSL encryption: 대게 SSL acceleration hardware를 갖춘 리버스 프록시 서버에서 SSL 암호화가 이루어진다.
- Load Balancing: 웹 서버는 복수 개의 서버로 구성되어 있고 각각의 어플리케이션을 담당하므로, 프록시 서버는 redirection (외부에 공개된 url -> 내부적으로 관리하는 위치) 을 통해 각각의 웹페이지로 요청을 보낸다.
- 캐싱: static content는 프록시 서버의 캐싱을 통해 서빙하는 게 리소스 상 유리
- Spoon feeding: 성능 떨어지는 클라이언트에게 캐싱 기능을 이용해 순차적으로 소스를 전달
- 보안: 웹 서버로 인입되기 전인 프록시 서버에 OS / 웹서버 대상의 공격을 막을 수 있는 레이어가 추가된다. 그러나 웹 어플리케이션이나 서비스 자체에 대한 공격은 막지 못한다.
프록시 사용의 주된 이유
위 reverse proxy의 사용 이유에서 어느 정도 커버가 된 면도 있지만, 조금 더 큰 범주에서 프록시 서버의 용도를 조금 더 살펴보면 이렇다.
- 모니터링 / 필터링: 학교나 회사망에서 url 접속이 제한된 경우를 생각해보면 쉽다. firewall이 제한하지 않은 프록시 서버를 사용하면 이러한 제한을 우회할 수는 있지만, 프록시 서버를 통해 개인정보 (비밀번호, 사진...) 를 전달해야 하는 위협이 있다.
- 역으로 프록시 서버를 로깅/감청을 위해 사용할 수도 있다. 나는 너를 믿었던 만큼 내 친구도 믿었기에...
- 퍼포먼스 증대: 프록시 서버의 가장 처음 용도는 캐싱 프록시였다. 자주 요청받는 항목들을 프록시 서버에 두어 upstream bandwidth의 사용과 비용을 줄인다.
그 밖에 보안, QA 용도가 있지만... 내겐 크게 중요하지 않은 것 같아 줄인다.
Redirect
위에서 잠깐 언급한 (url) redirection을 사용하는 이유로는:
- url 단축
- broken link (이동/제거된 웹페이지) 에 대한 대응
- 여러 개의 도메인을 보유하고 있을 경우 이를 하나의 웹 사이트로 이동시키기 위한 수단
- 개인정보 보호: 접근 권한 관리 등 (로그인 페이지로 리다이렉트 후 권한을 확인)
- 피싱이나 malware 배포를 위한 악의적 용도의 redirection
이 있다. 말 그대로 유저가 처음 입력했던 url과 다른 곳으로 이끄는 거라고 보면 될텐데, 요즘에는 지역 타게팅의 용도로도 쓰인다. 가령 이런 식이다. "강남 맛집 줘" -> "나는 (14, 158)에 있어. + 강남 맛집 줘"
http 리다이렉트는 http 표준으로 정의되어 있다. 일단 최초 요청을 받으면 웹 서버는 302 코드를 보내고, 그거에 더해 응답 메시지 헤더 중에 location 값으로 reirected URL을 제공한다. 웹 클라이언트는 302 코드를 보고는 헤더의 redirected URL을 확인해 다시 요청을 거는 구조이다.
Redirect vs Forward
리다이렉트의 경우 위에서 언급한 것처럼 302코드 확인 > 재요청의 과정을 클라이언트가 거쳐야 하지만, 포워딩의 경우 서버 사이드에서만 작업이 이루어진다. 리다이렉팅이 태생적으로 포워딩보다는 느릴 수밖에 없지만, 용도에 따라 리다이렉팅을 선택할 수 있다.
나가며
클릭이 발생한 프론트 서버 -> 로깅을 담당할 서버로 데이터를 전송하면서 어느 지점에서 익명화나 보안 단계가 더 필요했던 건지, 아니면 적절한 로깅 서버에 보내기 위해 프록시 서버가 필요했던 건지는 모르겠는데 "RD Proxy" 라고 써져있던 걸 상기해보면 redirect 성격의 프록시 서버에 조금 더 가깝지 않나 싶다. 개발담당자한테 한번 물어보는 것도 괜찮을 것 같고.
출처
https://en.wikipedia.org/wiki/Proxy_server
'Web' 카테고리의 다른 글
| SSP-DSP 간 연동을 중심으로 알아보는 HTTP GET vs POST (0) | 2025.04.29 |
|---|---|
| HTTP Request 와 Request Methods (2) | 2022.05.29 |
| Cookie 쿠키 와 3rd party cookie (1) | 2022.02.26 |
