리다이렉션 기술은 보통 메시지가 프락시, 캐시, 서버 팜의 특정 웹 서버 중 어디에서 끝나는지 판별하기 위해 사용한다. 리다이렉션 기술은 클라이언트의 메시지를 명시적으로 요청하지 않은 곳으로 보낼 수 있다.
#1. 왜 리다이렉트인가?
리다이렉션은 현대의 웹에서는 피할 수 없는 현실이다. 그 이유는?
- 신뢰할 수 있는 HTTP 트랜잭션의 수행
- 지연 최소화
- 네트워크 대역폭 절약
이러한 이유들 때문에 웹 콘텐츠는 흔히 여러 장소에 배포된다.
리다이렉션은 최적의 분산된 콘텐츠를 찾는 것을 도와주는 기법의 집합이다.
- 한 곳에서 실패한 경우 다른 곳을 이용할 수 있어 신뢰성이 개선된다.
- 클라이언트가 보다 가까운 리소스에 접근할 수 있게 되어 콘텐츠를 빨리 받게 되므로 응답 시간이 줄어든다.
- 목적지 서버가 분산되므로 네트워크 혼잡도 줄어든다.
리다이렉션의 구현에는 부하 균형의 과제가 포함되는데 그 이유는 둘은 서로 공존하기 때문이다.
#2. 리다이렉트 할 곳
서버, 프락시, 캐시, 게이트웨이는 클라이언트가 그들에게 HTTP 요청을 보내고 그들이 그것을 처리한다는 관점에서 보면 클라이언트에게 있어 모두 서버라고 할 수 있다. 따라서 많은 리다이렉션 기법이 서버, 프락시, 캐시, 게이트웨이에서 공통적으로 동작한다.
웹 서버는 IP별로 요청을 다룬다. 똑같이 복제된 서버들로 요청을 분산한다는 것은 같은 URL에 대해 여러 곳에서 온 요청들을 각각 최적의 웹 서버로 모내겠다는 것을 의미한다.
프락시는 프로토콜별로 요청을 다룬다. 만약 클라이언트 근처에 프락시 캐시가 있다면 모든 요청이 프락시 캐시로 흘러 들어가는 것이 이상적이다. 프락시로의 리다이렉트는 주 진입로의 트래픽을 근처에 있는 지름길로 빨아들이는 것과 같다.
#3. 일반적인 리다이렉션 방법
HTTP 리다이렉션
요청을 처리하는 서버(리다이렉팅 서버)는 가용한 것들 중 부하가 가장 적은 콘텐츠 서버를 찾아서 브라우저의 요청을 그 서버로 리다이렉트 한다.
장점 : 리다이렉트를 하는 서버가 클라이언트의 아이피 주소를 안다.
단점 :
- 어떤 서버로 리다이렉트 할지 결정하려면 원 서버는 상당히 많은 처리를 해야 함
- 페이지에 접근할 때마다 두 번의 왕복이 필요하기 때문에 사용자가 오래 기다려야 함
- 리다이렉트 서버가 고장 나면, 사이트도 고장남
DNS 리다이렉션
DNS는 하나의 도메인에 여러 아이피 주소가 결부되는 것을 허용하며, DNS 분석자는 여러 아이피 주소를 반환하도록 설정되거나 프로그래밍될 수 있다. 분석자가 어떤 아이피 주소를 반환할 것인가를 결정하는 방법은 라운드 로빈과 여러 서버의 로드를 검사해서 로드가 가장 적은 서버의 아이피 주소를 반환하는 것까지 다양한다.
DNS 라운드 로빈
DNS 라운드 로빈은 가장 흔한 동시에 가장 단순한 리다이렉션 기법이다. DNS 라운드 로빈은 웹 서버 팜 전체에 대한 부하의 균형을 유지하기 위해 DNS 호스트 명 분석 기능을 사용한다.
대부분의 DNS 클라이언트는 그냥 다중 주소 집합의 첫 번째 주소를 사용한다. 부하 균형을 위해 대부분의 DNS 서버는 룩업이 끝났을 때마다 주소를 순환시킨다. 이 주소 순환을 DNS 라운드 로빈이라 부르기도 한다.
DNS 순환은 서버들 간의 부하 균형을 유지해 준다. 만약 DNS가 주소를 순환시키지 않는다면 대부분의 클라이언트가 목록의 첫 번째 서버를 선택할 것이고 그 서버가 대부분의 부하를 받게 된다.
다른 DNS 기반 리다이렉션 알고리즘
- 부하 균형 알고리즘 : 몇몇 DNS 서버는 웹 서버의 로드를 추적하고 가장 로드가 적은 웹 서버를 목록의 가장 위에 놓는다.
- 근접 라우팅 알고리즘 : 웹 서버들의 팜이 지리적으로 분산되어 있는 경우, DNS 서버는 사용자를 근처의 웹 서버로 보내는 시도를 한다.
- 결함 마스킹 알고리즘 : DNS 서버는 네트워크의 건강 상태를 모니터링하고 요청을 정전이나 기타 장애를 피해서 라우팅 할 수 있다.
임의 캐스트 어드레싱
여러 지리적으로 흩어진 웹 서버들은 정확히 같은 아이피 주소를 갖고 클라이언트의 요청을 클라이언트에서 가장 가까운 서버로 보내주기 위해 백본 라운터의 '최단거리' 라우팅 능력에 의지한다.
웹 서버는 라우터 통신 프로토콜을 이용해 자신과 인접한 백본 라우터와 대화한다. 백본 라우터가 임의 캐스트 주소를 목적지로 하는 패킷을 받았을 때, 그 아이피 주소를 받아들일 수 있는 가장 가까운 '라우터'를 찾는다.
임의 캐스트 어드레싱은 여전히 실험적인 기법이다. 분산 임의 캐스트의 동작을 위해 서버는 반드시 '라우터의 언어로 말해야 하고' 라우터는 일어날 수 있는 주소 충돌을 반드시 다룰 수 있어야 한다.
#4. 그 외 리다이렉션 프로토콜 정리
일반 리다이렉션 (메시지를 서버로 리다이렉트 하기 위해 사용되는 리다이렉션 방법)
| 메커니즘 | 어떻게 동작하나 | 재 라우팅의 근거 | 제약사항 |
| HTTP 리다이렉션 | 콘텐츠를 제공하기에 최적인 웹 서버를 선택해줄 첫 번째 웹 서버로 간다. 그 웹 서버는 클라이언트에게 선택한 서버로의 HTTP 리다이렉트를 보내준다. 클라이언트는 선택된 서버에게 다시 요청을 보낸다. | 라운드 로빈 부하 균형, 회전 지연(latency) 최소화, 최단거리 선정 등의 여러 옵션들 | 느릴 수 있다. 모든 트랜잭션이 추가 리다이렉트 단계를 포함하게 된다. 또한 반드시 첫 번째 웹 서버가 요청 부하들 다룰 수 있어야 한다. |
| DNS 리다이렉션 | DNS 서버가 URL의 호스트 명에 대한 응답으로 어떤 IP 주소를 사용할지 결정한다. | 라운드 로빈 부하 균형, 회전 지연(latency) 최소화, 최단거리 선정 등의 여러 옵션들 | DNS 서버를 설정할 필요가 있다. |
| 임의 캐스트 어드레싱 | 여러 서버가 같은 IP 주소를 사용한다. 각 서버는 백본 라우터인 척 한다. 그 외의 라우터들은 그 공유된 IP 주소로 향하는 패킷을 가장 가까운 서버로 보낸다. | 라우터들은 내장된 최단거리 라우팅 기능을 사용한ㄷ. | 라우터를 갖고 설정할 필요가 있다. 주소가 충돌할 위험이 있다. 만약 라우팅이 바뀌고 커넥션과 연관된 패킷들이 다른 서버들로 보내진다면 수립된 TCP 커넥션이 깨질 수 있다. |
| 아이피 맥(MAC) 포워딩 | 스위치나 라우터 같은 네트워크 요소가 패킷의 목적지 주소를 읽는다. 만약 패킷이 리다이렉트되어야 한다면, 스위치는 그 패킷에게 서버나 프락시의 목적지 MAC 주소를 준다. | 대역폭을 절약하고 QOS(Quality of Service, 서비스 품질)를 개선한다. 부하 균형 | 서버나 프락시는 반드시 한 홉 거리에 있어야 한다. |
| IP 주소 포워딩 | 레이어 4 스위치는 패킷의 목적지 포트를 평가하고, 리다이렉트 패킷의 아이피 주소를 프락시나 미러링 된 서버의 아이피 주소로 바꾼다. | 대역폭을 절약하고 QOS를 개선한다. 부하 균형 | 서버나 프락시가 클라이언트의 IP 주소를 잃어버릴 수 있다. |
프락시와 캐시 리다이렉션
| 메커니즘 | 어떻게 동작하나 | 재라우팅의 근거 | 제약사항 |
| 명시적 브라우저 설정 | 웹브라우저는 가까운 프락시(보통 캐시)에게 HTTP 메시지를 보내도록 설정된다. 최종 사용자나 브라우저를 관리하는 서비스가 이 설정을 한다. | 대역폭을 절약하고 QOS(서비스 품질)를 개선한다. 부하 균형 | 브라우저의 설정 능력에 의존한다. |
| 프락시 자동설정 (Proxy auto-configuation, PAC) | 웹브라우저는 설정 서버로부터 PAC 파일을 검색한다. 이 PAC 파일은 브라우저에게 각 URL에 대해 어떤 프락시를 사용해야 하는지 알려준다. | 대역폭을 절약하고 QOS(서비스 품질)를 개선한다. 부하 균형 | 브라우저는 반드시 설정된 서버로 질의를 보내도록 설정되어야 한다. |
| 웹 프락시 자동발견(Web Proxy Autodiscovery Protocol, WPAD) | 웹브라우저는 설정 서버에게 PAC 파일에 대한 URL을 물어본다. PAC만 사용할 때와 달리 브라우저에 특정 설정 서버가 설정되어야 할 필요가 없다. | 설정 서버는 HTTP 요청 헤더에서 얻은 정보에 근거해 PAC 파일의 URP을 결정한다. 부하 균형. | |
| 웹 캐시 조직 프로토콜(Web Coordination Protocol, WCCP) | 라우터는 패킷의 목적지 주소를 평가하고 프락시나 미러링된 서버의 아이피 주소와 함께 리다이렉트 패킷을 캡슐화한다. 기존의 많은 라우터들과 함께 일한다. 패킷은 캡슐화될 수 있지만, 클라이언트의 아이피 주소는 잃지 않는다. | 대역폭을 절약하고 QOS(서비스 품질)를 개선한다. 부하 균형 | 반드시 WCCP를 지원하는 브라우저를 사용해야 한다. 위상적인(topological) 지약이 약간 있다. |
| 인터넷 캐시 프로토콜(Internet Cache Protocol, ICP) | 프락시 캐시는 형제 캐시의 무리에게 요청 받은 콘텐츠에 대해 질의할 수 있다. 또한 캐시 계층을 지원한다. | 형제 혹은 부모 캐시로부터 콘텐츠를 얻는 것은 원 서버로부터 얻는 것보다 빠르다. | 콘텐츠를 요청할 때 오직 URL만을 사용하기 때문에 캐시 적중이 아님에도 적중인 것처럼 동작할 우려가 있다. |
| 캐시 배열 라우팅 프로토콜(Cache Array Routing Protocol, CARP) | 프락시 캐시 해싱 프로토콜, 캐시가 요청을 부모 캐시로 전달할 수 있도록 해준다. ICP와는 달리 캐시의 콘텐츠는 분산되고 캐시들의 무리는 하나의 큰 캐시처럼 동작한다. | 형제 혹은 부모 캐시로부터 콘텐츠를 얻는게 원 서버로부터 얻는 것보다 빠르다. | CARP는 형제 관계를 지원할 수 없다. 모든 CARP 클라이언트는 반드시 설정에 동의해야 한다. 그렇지 않으면 다른 클라이언트들은 같은 URI를 다른 부모에게 보내게 되어 적중률이 감소할 것이다. |
| 하이퍼텍스트 캐싱 프로토콜(Hyper Text Caching Protocol, HTCP) | 참여하는 프락시 캐시는 형제 캐시의 무리에게 요청받은 콘텐츠에 대해 질의할 수 있다. 미세 조정된 캐시 질의에 HTTP/1.0과 1.1 헤더를 지원한다. | 형제 혹은 부모 캐시로부터 콘텐츠를 얻는게 원 서버로부터 얻는 것보다 빠르다. |
Redirect와 Forward의 차이 : https://doublesprogramming.tistory.com/63
Redirect VS, Forward (Redirect와 forward의 차이)
Redirect VS, Forward (Redirect와 forward의 차이) JSP환경에서 현재 작업중인 페이지에서 다른페이지로 이동하는 두가지 방식의 페이지 전환기능 사례를 통해 redirect와 forward의 차이점에 대해 감을 잡아보자..
doublesprogramming.tistory.com
참고 자료
- HTTP완벽가이드, 인사이트
'HTTP' 카테고리의 다른 글
| [HTTP] 로깅과 사용 추적 (0) | 2020.05.07 |
|---|---|
| [HTTP] 웹 호스팅 (0) | 2020.05.07 |
| [HTTP] 내용 협상(Content-negotiation)과 트랜스코딩 (0) | 2020.05.06 |
| [HTTP] 국제화 : 문자집합 인코딩 (0) | 2020.05.06 |
| [HTTP] 엔터티와 인코딩 (0) | 2020.05.05 |
