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

이 장에서는 리다이렉션 기법들과 그것들이 어떻게 동작하며 어떤 부하균형 능력을 갖고 있는지 살펴본다

 

---

 

1 .왜 리다이렉트인가?

 

• 리다이렉션은 최적의 분산된 콘텐츠를 찾는 것을 도와주는 기법의 집합이다
• 리다이렉션 장치들은 들어오는 메시지의 부하를 서버들의 집합에게 분산할 수 있다

 

2. 리다이렉트 할 곳

 

• 서버, 프락시, 캐시, 게이트웨이가 모두 공통적으로 서버의 특성을 갖고 있기 때문에, 많은 리다이렉션 기법이 그들 모두에서 동작한다. 그러나 어떤 리다이렉션 기술들은 특정 종류의 종단만을 위해 특별히 설계되어 일반적인 적용이 불가능하다
• 웹 서버는 IP별로 요청을 다룬다. 서버로의 리다이렉트란 휘발유를 찾는 모든 운전기사를 가장 가까운 주유소로 보내주는 것이다
• 프락시는 프로토콜별로 요청을 다룬다. 프락시의 리다이렉트는 주 진입로의 트래픽을 근처에 있는 지름길로 빨아들이는 것과 같다

 

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

 

• 라다이렉션의 목표는 HTTP 메시지를 가용한 웹 서버로 가급적 빨리 보내는 것이다. HTTP 메시지가 인터넷을 통해 나아가는 방법은 그 메시지가 오고, 거쳐가고, 향하는 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 서버는 네트워크의 건강 상태를 모니터링하고 요청을 정전이나 기타 장애를 피해서 라우팅 할 수 있다.

4.3 임의 캐스트 어드레싱

 

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

 

4.4 아이피 맥 포워딩

 

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

 

4.5 아이피 주소 포워딩

 

• 아이피 주소 포워딩에서, 스위치나 다른 레이어 4를 이해하는 장비는 들어오는 패킷에 대해 TCP/IP 어드레싱을 검증하고 패킷을 목적지 맥 주소가 아니라 목적지 아이피 주소의 변경에 따라 라우팅 한다
• 목적지 서버가 한 홉 거리에 있을 필요 없이 그저 스위치에서 업스트림의 위치를 판별할 수만 있으면 된다
• 클라이언트로부터 들어오는 TCP 커넥션을 받아주는 스위치는 그 커넥션을 관리하고 있어야 한다. 스위치는 반드시 그 커넥션을 통해 클라이언트에게 응답을 돌려주어야 한다.

 

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

 

네트워크 구성요소 제어 프로토콜(NECP)은 아이피 패킷을 전달하는 라우터나 스위치 같은 네트워크 구성요소들이 웹 서버나 프락시 캐시와 같이 애플리케이션 계층 요청을 처리하는 서버 구성요소들과 대화할 수 있게 해 준다.

NECP는 MAC 포워딩, GRE캡슐화, NAT와 같은 패킷을 전달하는 여러 방법을 제공한다

 

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

5.1 명시적 브라우저 설정

 

대부분의 브라우저에는 프락시 서버에 접촉하기 위해 프락시 이름, 아이피 주소, 포트번호를 설정할 수 있는 풀다운 메뉴가 존재한다. 몇몇 서비스 제공자들은 사용자들이 직접 브라우저의 설정을 변경해서 프락시를 사용하도록 하는 대신, 미리 설정이 다 되어 있는 브라우저를 다운 받도록 한다.

 

5.2 프락시 자동 설정

 

PAC(프락시 자동 설정)은 브라우저들이 URL별로 접촉해야 할 프락시를 지정한 PAC파일이라는 파일을 찾도록 하는 것이다

브라우저는 PAC파일을 얻기 위해 지정한 서버에 접촉하도록 설정되어야 한다. 그런 뒤에 브라우저는 재시작할 때마다 PAC파일을 가져온다.

자바스크립트 프로그램은 브라우저에게, DNS 주소나 서브넷, 심지어 요일이나 시각과 같은 호스트 명과 관련된 여러 매개변수에 근거하여 프락시를 선택하도록 요구할 수 있다. 

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차 도메인에 도달할 때까지 계속해서 서브도메인을 지운다.

 

 

 

6. 캐시 리다이렉션 방법

 

 WPAD 리다이렉션 

WCCP(캐시 조직 프로토콜)은 라우터들과 캐시들 사이의 대화를 관리하여 라우터가 캐시를 검사하고 특정 종류의 트래픽을 특정 캐시로 보낼 수 있게 해준다

 

 WPAD 리다이렉션 동작 

• 네트워크가 필요하다. WCCP를 사용할 수 있는 라우터와, 다른 캐시와 의사소통할 수 있는 캐시가 포함되어야 한다
• 라우터들의 집합과 그들의 대상이 되는 캐시들의 WCCP 서비스 그룹을 구성한다
• 만약 서비스 그룹이 HTTP 트래픽을 리다이렉션 하도록 설정되어 있다면, 서비스 그룹의 라우터는 HTTP 요청을 서비스 그룹의 캐시로 보낸다
• HTTP 요청이 서비스 그룹의 라우터에 도착했을 때, 라우터는 그 요청을 처리하기 위해 서비스 그룹의 캐시 중 하나를 선택한다
• 라우터는 요청 패킷을, 캐시의 아이피 주소와 함께 캡슐화하거나 아이피 맥 포워딩을 하여 캐시로 보낸다
• 만약 캐시가 요청을 처리할 수 없다면, 패킷은 평범하게 포워딩되기 위해 라우터로 돌아온다
• 서비스 그룹의 구성원들은 지속적으로 다른 구성원들의 가용성을 확인하기 위해 하트비트 메시지를 교환한다

 

7. 인터넷 캐시 프로토콜

 

• 인터넷 캐시 프로토콜(ICP)은 캐시들이 형제 캐시에서 일어난 캐시 적중을 찾아볼 수 있도록 해준다. 만약 캐시가 HTTP 메시지에서 요청한 콘텐츠를 갖고 있지 않다면, 캐시는 근처의 형제 캐시 중 그 콘텐츠를 갖고 있는 것이 있는지 찾아보고 만약 있다면 원 서버에 질의하는 것보다 비용이 더 들지 않을 것을 기대하며 그 캐시에서 콘텐츠를 가져온다
• ICP는 객체 발견 프로토콜이다. 캐시는 이 프로토콜을 사용해 근처의 캐시 모두에게 특정 URL을 갖고 있는지 한 번에 물어본다
• ICP메시지는 파싱 하기 쉽도록 네트워크 바이트 순서에 따라 32비트 크기로 맞추어진 구조체다. 이 메시지들은 UDP다이어그램을 통해 전송된다. 

 

8. 캐시 배열 라우팅 프로토콜

 

• 캐시 배열 라우팅 프로토콜(CARP)은, 프락시 서버의 배열이 클라이언트의 시점에서는 마치 하나의 논리적인 캐시처럼 보이도록 관리해주는, 마이크로소프트와 넷스케이프 커뮤니케이션이 제약한 표준이다
• CARP는 ICP의 대안이다. CARP와 ICP 둘 다 관리자가 여러 대의 프락시 서버를 사용하여 성능을 개선할 수 있게 해 준다
• ICP프로토콜로 서로 연결된 프락시 서버들 각각은 콘텐츠의 쓸데없는 복제본도 갖고 있는, 다시 말해 프락시 서버들 전체에 걸친 웹 객체에 대한 중복된 엔트리가 허용되는 독립적인 캐시이다.

 

 

---

출처 : 데이빗 골리 외 4인, HTTP 완벽 가이드 :웹은 어떻게 동작하는가, 이응준 , 정상일 옮김, 인사이트, 2014