HTTP - (14) Redirection(리다이렉션), Load-Balancing(부하 균형)

HTTP는 웹 내에서 많은 프로토콜에 의해 영향을 받는데, 이 때 송신자와 수신자 사이에서 목적지를 올바르게 찾아갈 줄 알아야 한다.

리다이렉션 기술은 최종 목적지를 결정하는 네트워크 기법이며 프락시, 캐시, 혹은 서버팜 등 어떤 서버에서 끝나는지 판별하는 데에 사용된다.

​

리다이렉션은 요즈음의 웹에서 반드시 필요한 요소이다.

HTTP 어플리케이션은 신뢰성과 낮은 지연성, 네트워크 대역폭 절약과 같은 이유로 여러 장소에 배포되기 때문이다.

HTTP는 여러 배포 장소 중 어느 곳으로 도착해야 빠르게 리소스에 접근이 가능할지, 네트워크 혼잡도를 줄일 수 있을지 판단할 수 있어야한다.

Redirection과 동시에 Load-Balancing(부하 균형)도 함께 고민이 되어야하는데, 둘은 공존하는 문제이기 때문이다.

​

클라이언트는 동일하게 '서버'로 여겨질 수 있는 서버, 프락시, 캐시, 게이트웨이를 대상 목적지로 삼고 있다.

Redirection의 목적은 HTTP 메시지를 빠르게 웹 서버로 보내는 것이다.

서버로의 리다이렉션이 여럿 있는데, HTTP 리다이렉션, DNS리다이렉션, IP MAC포워딩, IP주소 포워딩 등이 있다.

프락시로의 리다이렉션은 프락시 자동설정, 인터넷 캐시 프로토콜, 명시적인 브라우저 설정 등이 해당된다.

​

우선 서버로의 리다이렉션 기법들에 대해 살펴보자.

---

* HTTP 리다이렉션

​

웹 서버는 다른 서버로 요청을 보내도록 짧은 리다이렉트 메시지를 클라이언트로 전송할 수 있다.

이 기능을 사용하여 웹 서버는 트래픽을 분산하기도 한다.

리다이렉팅 서버가 따로 존재해서, 가용한 서버들 중 어떤 서버가 가장 부하가 적을지 고민한 뒤 결정하여 클라이언트로 메시지를 보낸다.

​

이 방법에는 단점이 있다. 리다이렉션 방향을 정할 서버가 많은 양의 처리를 해야한다는 것이다.

또한 클라이언트가 페이지에 접근하기 위해 리다이렉션 한 번 당 두 번의 요청과 응답을 처리해야하기 때문에 사용자가 오래 기다리게 된다.

만약 리다이렉션 서버가 고장이 난 경우 사이트에 접근도 어려워진다.

따라서 HTTP 리다이렉션은 다른 기법들과 함께 사용되곤 한다.

---

* DNS 리다이렉션

클라이언트에서 호스트 헤더에 사이트 주소를 전송할 경우 DNS 분석자는 해당 URL을 IP주소로 변환해주어야한다.

DNS는 하나의 도메인에 여러 IP주소 매핑이 가능하기 때문에, 어떤 IP주소를 반환하여 목적지로 전송해줄 것인지를 결정해야한다.

DNS 결정 알고리즘 중 가장 간단한 것은 라운드 로빈이다.

CNN.com이 실제로 20개의 IP를 보유하고 있는데, DNS 서버는 각 IP별 룩업이 되었을 경우 주소를 순환하게 한다.

​

라운드로빈 방식 역시 단점이 있는데, 룩업마다 서버 주소가 다른 주소로 반환되기 때문이다.

한 번의 룩업을 통해 주소를 재사용할 경우 클라이언트가 같은 서버에 꽤 오랫 동안 매핑되어있을 수 있다.

운영자 입장에서는 여러 클라이언트들의 부하 총량을 분산시키는 방법으로서 적절하지 않은 리다이렉션 기법일 수 있다.

따라서 이 기법의 성능은 유사한 수준의 부하를 발생시키는 클라이언트들의 수가 어느 정도 확보가 된다는 가정을 두고 있다.

​

라운드로빈 외에도 로드밸런싱 알고리즘이나 근접 라우팅 알고리즘 등이 지원된다.

---

* 임의 캐스팅 어드레싱(Addressing)

동일한 IP를 보유하면서 지리적으로 분산되어있는 여러 웹 서버들이 클라이언트에서 가장 가까운 위치 순서대로 매핑되는 것이다.

이 방식은 백본 라우터의 최단거리 라우팅 기법을 기반으로 하고 있는데, 백본 라우터가 패킷과 가장 가까운 라우터를 반환한다.

이 방식은 여러 서버가 동일한 IP주소(즉 논리적으로 한 서버임을 가정)를 사용하고 있으므로 라우팅 누수(충돌)가 발생하지 않도록 유의해야한다.

---

* IP MAC 포워딩

Ethernet에서 HTTP메시지는 패킷의 형태로 전송되는데, 패킷에는 출발지와 목적지의 IP주소와 TCP 포트번호를 보유하고 있다.

또한 스위치나 허브에서 필요로하는 MAC주소도 보유하고 있다.

예를 들어 80번 포트로 향하는 모든 웹 트래픽을 프락시로 보내고 그 외의 트래픽은 모두 게이트웨이로 전송하고자 할 때 사용될 수 있다.

---

* IP주소 포워딩

앞서 살펴본 MAC주소가 아닌 목적지 URL 주소에 따른 라우팅을 결정한다.

MAC포워딩의 경우 서버와 프락시가 스위치와 한 홉 거리에 위치해야한다(점 대 점으로 가능한 기술)는 단점이 있는데, 이를 보완했다.

NAT(Network Address Translation)이 이 방식의 대표적인 사례로 해당한다.

이 방식은 라우팅 대칭성이라는 단점이 있는데, 응답 역시 요청이 온 방향 그대로 돌아와야한다는 것이다.

---

다음은 프락시로의 리다이렉션 방법들에 대해 다뤄볼 것이다.

대부분 보안상의 이유로 콘텐츠 접근 시 프락시를 거치기도 하고, 프락시 캐시를 통해 재빠른 접근을 제공하기도 한다.

웹브라우저가 프락시로 도착하는 경로를 알 수 있는 방법(리다이렉션 방법)들이 여러 가지가 있는데, 각각에 대해 간단히 살펴볼 것이다.

---

* 명시적 브라우저 설정

브라우저 내에는 프락시 서버에 대한 이름, IP주소와 포트번호를 저장할 수 있도록 기능을 지원하는데, 서비스 제공자들은 이를 이용하여 본인의 서비스의 프락시 정보가 미리 기재된 브라우저들을 사용자에게 다운받도록 안내한다.

사용자들은 이 브라우저들을 통해 접촉할 프락시에 대해 미리 알고있는 경우가 있다.

이 방식의 단점은 프락시가 다운되거나 브라우저가 잘못 설정되었을 경우 원서버로의 접근을 하지 않기 때문에 접속에러가 발생한다.

---

* 프락시 자동 설정

올바른 프락시로의 접근이 될 수 있도록 브라우저가 동적으로 프락시를 설정할 수 있게하는 방법도 있다.

브라우저들은 URL별로 접촉해야할 프락시 리스트가 지정된 PAC 파일을 찾도록 되어있다.

브라우저가 재시작될 때마다 서버로부터 PAC파일들을 가져오는데, 브라우저가 PAC서버로 부터 PAC파일을 요청하고 내부에 "FindProxyFor URL"이라는 함수의 반환값에 따라 원서버로 접근할지, 프락시로 접근할지 결정하게 된다.

프락시 리스트 정보가 변경될 경우 PAC파일이 변경되고, 업데이트된 PAC파일을 브라우저가 자동으로 다운받기 때문에 상당히 유용한 기법이다.

오늘날에는 대부분 이 방식을 사용하고 있다고 한다.

---

* 웹 프락시 자동발견 프로토콜(WPAD)

사용자가 전혀 관여하지 않고도 웹 브라우저가 근처 프락시를 발견해내어 접근할 수 있도록하는 기법이다.

WPAD는 HTTP클라이언트가 PAC파일의 위치를 알아내고 그 파일을 읽어 프락시에 대한 정보를 알아낼 수 있게 해준다.

즉 HTTP클라이언트가 WPAD 프로토콜이 구현되어 있다면, WPAD를 이용하여 PAC파일 CURL을 찾고 파일을 가져오는 것이다.

​

WPAD 프로토콜이 적절한 PAC파일 CURL을 찾기 위해 여러 알고리즘을 사용한다.

만약 선행 알고리즘들이 파일 CURL을 찾는 데에 실패할 경우, 후행 알고리즘들이 그 작업을 대신 수행한다.

​

1) DHCP : 동적 호스트 설정 프로토콜, DHCP서버로 쿼리를 날려 CURL정보를 가져온다.

2) DNS A record look-up : DNS서버에 프락시 서버 IP주소들이 쿼리할 수 있는 형태로 저장되어있다는 가정 하에, A 레코드 룩업을 DNS서버로 보내어 CURL을 얻는다.

3) DNS에게 잘 알려진 호스트명 등

​

HTTP 클라이언트는 보유하고 있는 PAC파일의 만료 기간이 다 되었거나, 웹 클라이언트가 새로 시작될 때 WPAD를 수행해야한다.

---

마지막은 캐시로 리다이렉션하는 방법인데, 앞선 프로토콜보다 복잡하다.

캐시로의 접근은 해당 캐시 서버에 신뢰 가능하고 고성능에, 최신 콘텐츠를 보유하고 있어야 사용 가능한 캐시이기 때문에, 이를 파악할 수 있어야한다.

​

캐시 조직 프로토콜(WCCP)는 시스코 시스템즈에서 개발한 프락시 캐시로의 리다이렉션 기법이다.

여러 라우터의 집합과 그 대상의 캐시들이 존재하는 WCCP 서비스 그룹이 형성되어야하는데, 해당 서비스 그룹이 설정되면 어떤 트래픽이 어느 캐시로 도착해야하는지, 어떻게 캐시들 사이에서 트래픽이 분산되어야하는지 등에 대한 정책이 결정되었다고 볼 수 있다.

HTTP 요청이 서비스 그룹의 라우터에 도착했을 때, 라우터는 요청을 처리할 캐시를 결정하게 된다.

이 때 오가는 WCCP2 메시지들이 있다.

라우터와 캐시 사이에는 Here I Am과 I See You 메시지를 통해 설정된 서비스 그룹에 대한 정보를 주고받는다.

​

인터넷 캐시 프로토콜(ICP)는 캐시들 간 캐시 적중에 대한 정보를 공유할 수 있도록 해주는 프로토콜이다.

즉 HTTP요청을 처리하는 캐시에서 요청된 콘텐츠를 보유하고 있지 않을 경우 근처 캐시 중 콘텐츠를 보유하고 있는지 살펴보는 것이다.

캐시는 이 프로토콜로 근처 모든 캐시에게 특정 URL을 보유하고 있는지 질의하고, 캐시는 HIT 혹은 MISS로 간단히 응답한다.

​

---

참고도서

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980 

HTTP 완벽 가이드