[http 완벽 가이드] 20장 리다이렉션과 부하 균형

 

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

20장 리다이렉션과 부하 균형

• 이 장은 리다이렉션 기술에 대한 장이다.
• 리다이렉션 기술은 보통 메시지가 프락시, 캐시, 서버 팜의 특정 웹 서버 중 어디에서 끝나는지 판별하기 위해 사용한다.
• 리다이렉션 기술은 클라이언트의 메시지를 명시적으로 요청하지 않은 곳으로 보낼 수 있다.

1. 왜 리다이렉트인가?

• 리다이렉션은 다음 세가지를 수행하게 해준다.
  • 신뢰할 수 있는 HTTP 트랜잭션의 수행
  • 지연 최소화
  • 네트워크 대역폭 절약
• 한 곳에서 문제가 생기거나 트래픽이 몰리면 다른 곳으로 리다이렉트 해줌으로 써 부하 균형을 유지한다.

2. 리다이렉트 할 곳

• 서버, 프락시 , 캐시 , 게이트웨이는 클라이언트 관점에서 서버이기에 그들 모두에게 동작한다.
• 하지만 웹 서버는 IP 별로 다루기 때문에 똑같이 복제된 서버들로 요청을 분산한다는 것은 같은 URL에 대해 여러 곳에서 온 요청들을 각각 최적의 웹 서버로 보내겠다는 것을 의미한다.
• 프락시는 이웃의 모든 HTTP 트래픽은 프락시를 거치는 게 이상적이다.

3. 리다이렉션 프로토콜의 개요

• 리다이렉션의 목표는 HTTP 메시지를 가용한 웹 서버로 가급적 빨리 보내는 것이다.
• 라우팅 장치를 통해 리다이렉션을 수행하는데 예를 들면 다음과 같다.
  • 브라우저 애플리케이션의 사용자는 브라우저가 클라이언트 메시지를 프락시 서버로 보내도록 설정할 수 있다.
  • DNS 분석자는 메시지의 주소를 지정할 때 사용될 아이피 주소를 선택한다.
  • 메시지는 주소가 지정된 여러 개의 패킷으로 나뉘어 네트워크를 통과한다. 스위치와 라우터들은 패킷의 TCP/IP 주소를 검증하고 그에 근거하여 패킷을 어떻게 라우팅 할 것인지 결정한다.
  • 웹 서버는 HTTP 리다이렉트를 이용해 요청이 다른 웹 서버로 가도록 할 수 있다.

4. 일반적인 리다이렉션 방법

• 이 장에서, 우리는 서버와 프락시 양쪽에서 공통으로 쓰이는 여러 가지 리다이렉션 방법들을 한층 더 깊이 파볼 것이다.
• 이 기법들은 트래픽을 다른 서버나 프락시를 통해 벡터 트래픽으로 리다이렉트하기 위해 사용될 수 있다.

4.1 HTTP 리다이렉션

• 웹 서버들은 다른 곳에 요청을 보내보라고 말해주는 짧은 리다이렉트 메시지를 클라이언트에게 돌려줄수 있다.
• 요청을 처리하는 서버는 가용한 것들 중 부하가 가장 적은 콘텐츠 서버를 찾아서 브라우저의 요청을 그 서버로 리다이렉트 한다
• 웹 서버들이 광범위하게 분산되어 있다면 '최선의' 가용한 서버를 결정하는 것은 더욱 어려워진다.
• HTTP 리다이렉션이 가지고 있는 단점때문에, HTTP 리다이렉션은 보통 몇몇 다른 리다이렉션 기법과 함께 조합하여 사용된다.
• HTTP 리다이렉션은 서버로 향하는 요청의 방향을 변경할 수 있지만 , 다음과 같은 몇가지 단점이 있다.
  • 어떤 서버로 리다이렉트 할지 결정하려면 원 서버는 상당히 많은 처리를 해야 한다.
  • 페이지에 접근할 때마다 두 번의 왕복이 필요하기 때문에, 사용자가 더 오래 기다리게 된다
  • 만약 리다이렉트 서버가 고장 나면, 사이트도 고장 난다

4.2 DNS 리다이렉션

• 클라이언트가 죠의 하드웨어 웹 사이트에 접근하려고 시도할 때마다, 도메인 주소는 반드시 아이피 주소로 분석되어야 한다.
• DNS 분석자는 클라이언트의 운영체제일 수도 있고, 클라이언트의 네트워크에 있는 DNS 서버이거나 혹은 더 원격에 있는 DNS 서버일 수도 있다.
• DNS 분석자가 어떤 아이피 주소를 반환할 것인가를 결정하는 방법은 단순한것부터 복잡한 것를 검사해서 로드가 가장 적은 서버의 아이피 주소를 반환하는 것까지 다양하다.
• DNS 라운드 로빈
  • DNS 라운드 로빈은 웹 서버 팜 전체에 대한 부하의 균형을 유지하기 위해 DNS 호스트 명 분석 기능을 사용한다
  • 이 방식은 서버에 대한 클라이언트의 상대적인 위치나 서버의 현재 스트레스를 고려하지 않는다
• 다중 주소와 로빈 주소 순환
  • 부하 균형을 위해, 대부분의 DNS서버는 룩업이 끝났을 때마다 주소를 순환시킨다.
• DNS 캐싱의 효과
  • 호스트 하나에 대한 한 번의 DNS 룩업을 수행한 뒤, 그 주소를 몇번이고 다시 사용한다.
  • 그렇게 하면 DNS 룩업의 비용을 줄일 수 있을 뿐 아니라, 같은 클라이언트와 계속 대화하는 것을 선호하는 서버들도 있기 때문이다. '
• 다른 DNS 기반 리다이렉션 알고리즘
  • 부하 균형 알고리즘 - 몇몇 DNS 서버는 웹 서버의 로드를 추적하고 가장 로드가 적은 웹 서버를 목록의 가장 위에 놓는다
  • 근접 라우팅 알고리즘 - 웹 서버들의 팜이 지리적으로 분산되어 있는 경우, DNS 서버는 사용자를 근처의 웹 서버로 보내는 시도를 할 수 있다.
  • 결함 마스킹 알고리즘 - DNS 서버는 네트워크의 건강 상태를 모니터링하고 요청을 정전이나 기타 장애를 피해서 라우팅 할 수 있다.

4.3 임의 캐스팅 어드레싱

• 임의 캐스트 어드레싱에서, 여러 지리적으로 흩어진 웹 서버들은 정확히 같은 아이피 주소를 갖고 클라이언트의 요청을 클라이언트에서 가장 가까운 서버로 보내주기 위해 백본 라우터의 최단거리 라우팅 능력에 의지한다.
• 이 방법이 동작하는 방식 중 하나는 각 웹 서버에게 자신을 인접한 백본 라우터를 향하는 라우터라고 광고하는 것이다.
• 이 기법은 분산 임의 캐스트의 동작을 위해, 서버는 반드시 '라우터의 언어로 말해야 하고' 라우터는 일어날수 있는 주소 충돌을 다룰 수 있어야 한다.

4.4 아이피 맥 포워딩

• 이더넷 네트워크에서, HTTP메시지는 주소가 붙은 데이터 패킷의 형태로 보내진다.
• 각 패킷은 출발지와 목적지의 아이피 주소와 TCP포트번호로 이루어진 레이어-4주소를 갖고 있다.
• MAC 주소 포워딩은 점 대 점으로만 가능하기 때문에, 서버나 프락시는 스위치와 한 홉 거리에 위치해야 한다

4.5 아이치 주소 포워딩

• 아이피 주소 포워딩에서, 스위치나 다른 레이어 4를 이해하는 장비는 들어오는 패킷에 대해 TCP/IP 어드레싱을 검증하고 패킷을 목적지 맥 주소가 아니라 목적지 아이피 주소의 변경에 따라 라우팅 한다.
  • 맥 포워딩보다 좋은 점 하나는 목적지 서버가 한 홉 거리에 있을 필요가 없다는 것이다.
• 목적지 서버가 한 홉 거리에 있을 필요 없이 그저 스위치에서 업스트림의 위치를 판별할 수만 있으면 된다
• 그러나 여기에는 라우팅 대칭성이라는 문제가 있다. 클라이언트로부터 들어오는 TCP 커넥션을 받아주는 스위치는 그 커넥션을 관리하고 있다.
• 클라이언트로부터 들어오는 TCP 커넥션을 받아주는 스위치는 그 커넥션을 관리하고 있어야 한다. 스위치는 반드시 그 커넥션을 통해 클라이언트에게 응답을 돌려주어야 한다.
• 응답의 귀한 경로를 제어할 수 있는 두 가지 방법은 다음과 같다.
  • 패킷의 출발지 아이피 주소를 스위치의 아이피 주소로 바꾼다.
  • 만약 출발지 아이피 주소가 그 클라이언트의 아이피 주소로 계속 남아있다면, 서버에서 클라이언트로 바로 가는 경로가 존재하지 않아야 한다.

4.6 네트워크 구성요소 제어 프로토콜

• 네트워크 구성요소 제어 프로토콜 (NECP)은 아이피 패킷을 전달하는 라우터나 스위치 같은 네트워크 구성요소들이 웹 서버나 프락시 캐시와 같이 애플리케이션 계층 요청을 처리하는 서버 구성요소들과 대화 할 수 있게 해준다.
  • SE가 NE에 부하 균형 정보 제공
  • MAC 포워딩, GRE 캡슐화, NAT 와 같은 패킷 전달 방식들을 제공

5. 프락시 리다이렉션 방법

• 콘텐츠에 접근할 때 프락시를 통할 필요가 있는 경우도 있으며, 클라이언트가 이용하면 유익한 프락시 캐시가 네트워크에 있을 수도 있다.
• 그러나 웹 브라우저와 같은 클라이언트들이 어떻게 프락시로 가는 길을 아는가 여기에는 3가지 방법이 있다.
  • 명시적 브라우저 설정
  • 프락시 자동 설정
  • 웹 프락시 자동 발련 프로토콜 WPAD

5.1 명시적 브라우저 설정

• 브라우저는 프락시 이름, IP 주소, 포트 번호를 설정할 수 있음
• 하지만 이 방법은 단점이ㅣ 있다.
  • 프락시로부터 응답이 없어도 원서버로 가지 않음
  • 네트워크 아키텍처 변경을 브라우저 사용자에게 전파하기 어려움

5.2 프락시 자동 설정

• PAC 을 통한 브라우저의 동적 프락시 설정
• 네트워크 아키텍퍼가 변겨왿어도 PAC 파일만 업데이트하면 브라우저는 해당 설정을 읽어서 반영

5.3 웹 프락시 자동발견 프로토콜

• 웹 프락시 자동발견 프로토콜(WPAD)은 최종 사용자가 수동으로 프락시 설정을 할 필요도, 투명한 트래픽 인터셉트에 의존할 필요도 없이 웹브라우저가 근처의 프락시를 찾아내어 사용할 수 있게 해주는 방법을 제공하는 것을 목적으로 하고 있다.

PAC 파일 자동발견

• WPAD는 HTTP 클라이언트가 PAC파일 위치를 알아내고 그 파일을 이용해서 적절한 프락시 서버의 이름을 알아낼 수 있게 해 준다.
• WPAD 프로토콜은 설정 URL이라고 알려진 PAC 파일 URL을 발견한다. 이 PAC파일은 적절한 프락시 서버의 주소를 반환하는 자바스크립트 프로그램을 실행한다.

WPAC의 알고리즘

• WPAD는 적절한 PAC파일 CURL을 결정하기 위해 여러 가지 리소스 발견 기법들을 사용한다
• WPAD 클라이언트에게는 오직 DHCP와 DNS에게 잘 알려진 호스트 명 기법만이 요구된다
• WPAD 클라이언트는 앞에서 언급한 발견 메커니즘을 이용해서 리소스 발견 요청을 순서대로 보낸다. 발견 시도가 성공할 때마다, 클라이언트는 PAC CURL 을 생성하기 위해 취득한 정보를 사용한다
• 만약 PAC파일이 이 CURL 에서 성공적으로 발견되었다면 과정은 종료한다
• 클라이언트는 DNS SRV, 잘 알려진 호스트명들, 그리고 DNS TXT 레코드 방법을 여러 차례 순환한다. 매번 DNS 쿼리 QNAME은 점점 덜 구체적이게 된다

DHCP를 이용한 CURL 발견

• WPAD 클라이언트가 질의하는 DHCP 서버는 반드시 CURL을 저장하고 있어야 한다
• WPAD클라이언트는 DHCP 질의를 DHCP 서버에 보냄으로써 CURL을 얻는다
• WPAD클라이언트가 자신의 초기화 과정에서 이미 DHCP 질의를 했다면, DHCP 서버는 이미 그 값을 제공했을 수 있다

DNS A 레코드 룩업

• 이 메커니즘이 동작하려면, 알맞는 프락시 서버의 IP주소들이 WPAD 클라이언트들이 질의할 수 있는 DNS 서버에 반드시 저장되어 있어야 한다.
• WPAD 클라이언트는 A레코드 룩업을 DNS 서버로 보내 CURL을 얻는다
• 룩업이 성공하면 적절한 프락시 서버의 IP주소를 얻는다

PAC파일 가져오기

한번 후보 CURL이 생성되면, WPAD 클라이언트는 보통 그 CURL로 GET 요청을 만드는데, 이때 자신이 다룰 수 있는 적절한 CFILE 포맷 정보가 담긴 Accept 헤더를 포함해야 한다

언제 WPAD를 실행하는가

• 웹 클라이언트가 시작될 때
• 클라이언트 호스트의 아이피 주소가 변경된 네트워킹 스택으로부터 어떤 언급이 있을 때마다

WPAD 스푸핑

WPAD의 IE5구현은 사용자의 개입 없이 웹 클라이언트가 프락시 설정을 자동으로 탐지하는 것을 가능하게 했다. WPAD알고리즘은 호스트 명 'wpad'를 도메인 이름의 절대 표기 앞에 붙이고 WPAD 서버를 찾아내거나 3차 도메인에 도달할 때까지 계속해서 서브도메인을 지운다.