오늘은 HTTP 프로토콜 강좌의 마지막 시간이다.
6월 말부터 지금까지 약 4개월 정도를 "HTTP 프로토콜 강좌"에 대해 포스팅한 것 같다.
여러가지 내용이 있었으나, 웹프록시(Proxy)는 HTTP 프로토콜 강좌의 많은 부분을 차지 한다. 웹프록시 기반의 캐시라는 녀석이 있으니.. 당연한게 아니겠는가?
더욱이 최근 시장에 소개되는 웹가속기, SSL 가속기, 웹방화벽, ADC 스위치의 L7 스위칭 기능들이 모두 웹 프록시를 기반으로 하고 있다.
클라이언트와 웹서버사이에서 동작하는 웹프록시는 특히 웹서비스 측면에서 이점을 주는데 제약사항이 없을까?
당연히 존재한다. 오늘은 이에 대한 이야기를 해 보려한다.
웹프록시 동작에서의 사용자 IP 변환
웹프록시가 클라이언트와 웹서버 사이에 존재하게 되면, 클라이언트에게는 웹서버인것처럼... 웹서버에게는 클라이언트인것 처럼 동작을 하게 된다.
다시 또 이야기 하지만, 아래 그림과 같이 웹프록시를 기준으로 TCP 세션이 구분된다.
- 1~3번 과정 : TCP 세션 수립
- 클라이언트는 웹서버와 세션을 맺으려고 시도하나, 실제로는 웹프록시와 TCP 세션을 맺게 된다.
- 4번 과정 : HTTP 요청 전달
- 5~7번 과정 : TCP 세션 수립
- 웹서버는 클라이언트와 세션을 수립하는게 아니고 웹프록시와 TCP 세션을 맺는다.
- 8번 과정 : 클라이언트로부터 받은 HTTP 요청 전달
위와 같은 일련의 과정을 "Delayed Binding (지연 바인딩)" 이라 부르기도 한다.
바로 이런 지연바인딩의 동작에서 변경되는 사항이 있는데, 그게 바로 소스 IP 의 변경이다. 5번부터 시작되는 웹프록시와 웹서버간의 동작에서 소스 IP 가 웹프록시 IP로 변경된다.
따라서 웹서버는 실제 사용자의 IP를 확인하지 못한다.
IP 변경에 따른 고려사항
사용자의 IP가 변경되게 되면, 일단, 웹서버에서는 고민거리가 생기게 된다.
웹서버는 처리하는 모든 트랜잭션에 대한 로그를 남기는데, 이런 웹로그에 사용자 IP를 구분할 수 없게 된다. 나중에 문제가 생겨 웹로그를 참고해야 할 상황이 생긴다면 이런 경우는 크나큰 낭패가 아닐수 없다.
또한 사용자 IP 기반으로 동작하는 웹어플리케이션 로직이 있다면.. 이 역시 IP 변경시 문제가 된다.
웹서버 또는 웹어플리케이션 뿐만 아니라.. 웹프록시와 웹서버 사이에 존재하는 네트워크 장비등에서도 운영에 문제가 발생한다.
IP 기반의 ACL Rule 등을 활용하기가 힘들어진다.
네트워크 방화벽이 존재한다면.. 같은 제약사항이 발생하는것이다.
이처럼 사용자 IP 기반으로한 정책들이 있다면, 웹프록시로 인한 사용자 IP 변경은 운영에 큰 영향을 미칠수 있는 중요한 요소가 된다.
x-forwarded-for 헤더를 이용한 사용자 IP 구분
위 고려사항을 모두 해결할 수는 없겠으나, 웹로그 및 웹 애플리케이션 로직상 사용자 IP를 구분할 수 있게 해주는 방안이 있다.
그건 바로 "x-forwarded-for" 헤더이다.
웹프록시는 자신이 처리한 클라이언트의 HTTP 요청을 웹서버로 전달하는 과정에서 x-forwarded-for 헤더정보를 추가하여 실제 사용자 IP를 알려준다.
다음 그림을 보자.
클라이언트의 요청이 웹프록시를 통해서 웹서버로 전달되는 과정의 HTTP 헤더 정보이다.
그림에서와 같이 웹프록시를 통해 웹서버로 전달되는 요청에서 보면, "x-forwarded-for" 헤더가 추가됨을 볼수 있다.
x-forwarded-for 헤더의 정보에는 실제 사용자의 IP 가 담겨 있음을 확인할 수 있다.
웹서버에서는 기존의 웹로그에서 사용자의 IP를 남기는 부분을 IP헤더가 아닌 x-forwarded-for 헤더의 정보를 참고하도록 하면 되며, 웹 애플리케이션의 로직에서도 마찬가지로 x-forwarded-for 헤더 정보를 참고하게 변경하면 사용자 IP 변경을 어느정도 대응할 수 있다.
그동안 HTTP 프로토콜 강좌를 관심있게 봐주신 여러 독자 분들께 진심으로 감사의 말씀을 전한다.
앞으로도 기술적으로 정리할 내용이 있다면, 최대한 쉽고 알차게 정리할 수 있도록 노력하겠다.
끝~
내용 감사합니다. 바로 이해가 됬네요^^
답글삭제