리다이렉션과 부하 균형

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

왜 리다이렉트인가?

HTTP 애플리케이션은 항상 세 가지를 원한다

• 신뢰할 수 있는 HTTP 트랜잭션의 수행
• 지연 최소화
• 네트워크 대역폭 절약

과 같은 이유 때문에 웹 콘텐츠는 여러 장소에 배포되고, 한 곳에서의 요청이 실패하면 다른 곳을 이용하면서 여러 이점을 누릴 수 있다.

• 콘텐츠 레이턴시 감소
• 신뢰성 개선
• 목적지 서버 분산으로 네트워크 혼잡도 줄이기

들어오는 메시지는 반드시 어떤 식으로든 부하를 공유하는 서버들 중 하나에게 전달되어야 하기 때문에 어떤 로드 밸런싱(부하 균형)도 리다이렉션을 포함하게 된다.

리다이렉트 할 곳

웹 서버

웹 서버는 IP별로 요청을 다룬다. 똑같이 복제된 서버들로 요청을 분산한다는 것은 같은 URL에 대해 여러 곳에서 온 요청들을 각각 최적의 웹 서버로 보내졌다는 것을 의미한다.

프락시

프락시는 프로토콜별로 요청을 다룬다. 이상적으로는 프락시 이웃의 모든 HTTP 트래픽은 프락시를 거쳐 감으로써 클라이언트 근처의 캐시를 찾아 제공하여 로드 밸런싱을 한다.

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

리다이렉션의 목표 → HTTP 메시지를 가용한 웹 서버로 가급적 빨리 보내는 것

예시

• 브라우저 애플리케이션의 사용자 : 브라우저가 클라이언트 메시지 → 프락시 서버로 보내도록 설정
• DNS resolver : 메시지 주소 지정 시 사용된 IP 주소 선택
• 메시지 : 주소가 지정된 여러 개의 패킷으로 나뉘어 네트워크를 통과. 스위치와 라우터들은 패킷의 TCP/IP 주소를 검증하고 이에 근거하여 패킷을 어떻게 라우팅 할 것인지 결정
• 웹 서버 : HTTP 리다이렉트를 이용해 요청이 다른 웹 서버로 가도록함 이와 같이 HTTP 메시지가 인터넷을 통해 나아가는 방향은 그 메시지가 오고, 거쳐가고, 향하는 HTTP 애플리케이션과 라우팅 장치에 영향을 받음

브라우저, DNS, TCP/IP 라우팅, HTTP는 모두 메시지를 리다이렉트하는 메커니즘을 제공한다.

브라우저 설정과 같은 방법은 프락시로 향하는 리다이렉트 트래픽에 대해서만 사용할 수 있다.

L4(Layer 4)스위치 OSI 7계층 모델 중 4계층인 전송 계층(Transport Layer) 의 정보를 활용하여 동작하는 네트워크 스위치. 일반적인 스위치(레이어 2 스위치)가 MAC 주소를 기반으로 패킷을 전달하고, 라우터 기능이 있는 레이어 3 스위치가 IP 주소를 기반으로 경로를 설정하는 것과 달리, 레이어 4 스위치는 IP 주소와 함께 TCP/UDP 포트 번호까지 참조하여 패킷을 처리. 위에 나온 것처럼 포트 평가까지 하면서 로드 밸런싱을 수행

일반적인 리다이렉션 방법

HTTP 리다이렉션

• 요청을 처리하는 서버는 가용한 것들 중 부하가 가장 적은 콘텐츠 서버를 찾음(클라이언트 IP 기반) → 브라우저의 요청을 그 서버로 리다이렉트
• 301, 302 등의 응답 코드와 Location을 함께 리다이렉트 메시지 돌려줌
• 단점
  • 리다이렉트할 서버를 고르는데 많은 처리
  • 두번의 왕복 → 레이턴시가 길어짐
  • 리다이렉트 서버가 고장나면 사이트도 고장남 → 다른 리다이렉션 기법과 함께 조합하여 사용

DNS 리다이렉션

• DNS는 하나의 도메인에 여러 아이피주소가 결부되는 것을 허용 + DNS Resolver는 여러 아이피 주소를 반환하도록 설정되거나 프로그래밍 될 수 있음
• 단순한 라운드로빈부터 로드를 검사하는 등 다양한 방법이 있음
• DNS 라운드 로빈
  • 웹 서버 팜 전체에 대한 부하의 균형을 유지하기 위해 DNS 호스트명 분석 기능을 사용하는 순수 부하 균형 전략
  • 서버에 대한 클라이언트의 상대적인 위치나 서버의 현재 스트레스를 고려하지 않음
  • 다중 주소와 라운드 로빈 주소 순환
    • 다중 주소 집합의 첫 번째 주소 사용 + 룩업이 끝났을 때마다 주소 순환
• DNS 캐싱의 효과
  • 서버에 대한 DNS 룩업 → 서버 주소를 다른 순서로 가져오기 때문에 로드 밸런싱
  • 단일 클라이언트의 트랜잭션을 서버의 복제들에게 나눠주지는 않더라도 여러 클라이언트의 부하 총량 분산
• 다른 DNS 기반 리다이렉션 알고리즘
  • 부하 균형 알고리즘
    • 가장 로드가 적은 웹 서버를 최상위로
  • 근접 라우팅 알고리즘
    • 웹서버들의 팜이 지리적으로 분산되어 있는 경우, DNS 서버가 사용자를 근처의 웹서버로 보냄
  • 결함 마스킹 알고리즘
    • 네트워크의 건강 상태를 모니터링하고 요청을 네트워크 상황에 따라 라우팅
  • 보통 이런 서버 추적 알고리즘을 실행하고 있는 DNS 서버는 콘텐츠 제공자의 통제하에 있는 권위 있는 서버(Authoritative Server)

임의 캐스트 어드레싱

웹 서버 → 같은 IP 주소를 갖고 클라이언트의 요청을 클라이언트에서 가장 가까운 서버로 보내주기 위해 백본 라우터의 최단거리 라우팅 능력에 의지

백본 라우터 인터넷 백본(Backbone Network)에서 트래픽을 중계하고 전달하는 고성능 라우터. 즉, 인터넷이나 기업 내부의 핵심 경로를 담당하는 주요 라우터

동작 방식

• 웹 서버에게 자신을 인접한 백본 라우터를 향하는 라우터라고 광고
• 라우터 통신 프로토콜을 사용해 자신과 인접한 백본 라우터와 대화
• 백본 라우터가 임의 캐스트 주소를 목적지로 하는 패킷을 받으면 가장 가까운 라우터를 찾음
• 서버는 자신이 그 주소를 위한 라우터라고 광고해서 그 서버로 패킷을 보냄

단점

• 반드시 라우팅 통신 프로토콜을 통해 대화
• 주소 충돌 처리가 필수적(라우팅 누수 위험)

아이피 맥 포워딩

HTTP메시지 → 주소가 붙은 데이터 패킷의 형태로 보내짐.

• 각 패킷은 출발지와 목적지의 아이피 주소와 TCP 포트번호로 이루어진 레이어-4
• 레이어-2 장비가 주의를 기울여야 하는 레이어-2 주소인 미디어 접근 컨트롤 주소도 갖고 있음
  • 레이어-2 → 특정 맥 주소의 패킷을 받아 나가는 특정 맥 주소로 포워딩
• IP 주소(Layer 3, 네트워크)와 MAC 주소(Layer 2, 데이터 링크 계층)가 데이터 패킷을 목적지까지 전달하는 과정에서 IP 주소를 활용하여 ARP로 MAC 주소를 얻고, 패킷에 MAC 주소와 IP 주소를 함께 넣어 보내면서 데이터 프레임을 만들고 전달
• 단점 → 점대점으로만 포워딩 가능 + 서버와 프락시는 스위치와 한 홉 거리여야 함.

아이피 주소 포워딩

장점

• 목적지 서버가 한 홉 거리에 있을 필요가 없음
  • 일반적인 레이어-3 종단간 인터넷 라우팅이 패킷을 올바른 위치로 보내줌(NAT)
• 라우팅 대칭성의 문제
  • TCP 커넥션을 받아주는 스위치는 그 커넥션을 관리하고 있으며 그 커넥션으로 반드시 응답을 줘야 함
  • 응답 경로를 제어할 수 있는 두 가지 방법
    • 패킷의 출발 아이피 주소를 스위치의 아이피 주소로 변경
      • 완전 NAT → 목적지와 출발지 아이피 주소 양쪽을 번역해주는 아이피 전달 장치
    • 서버에서 클라이언트로 바로 가는 경로가 존재하지 않아야 함
      • 반 NAT
      • 장점 → 서버가 클라이언트 아이피 주소를 얻음
      • 단점 → 클라이언트와 서버 사이의 네트워커 전체에 약간의 통제가 필요

NAT(Network Address Translation) 내부(사설) IP 주소 ↔ 외부(공인) IP 주소를 변환하는 기술

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

Network Element Control Protocol, NECP

• 아이피 패킷을 전달하는 라우터나 스위치 같은 네트워크 구성요소들(NE)이 웹 서버나 프락시 캐시와 같이 애플리케이션 계층 요청을 처리하는 서버 구성요소들(SE)와 대화하게 해줌
• 명시적인 부하 균형 정보 제공X
• SE → NE 에게 부하 균형 정보를 제공할 수 있는 방법 제공
• MAC 포워딩, GRE 캡슐화, NAT와 같은 패킷을 전달하는 방법 제공

프락시 리다이렉션 방법

웹브라우저와 같은 클라이언트들이 어떻게 프락시로 가는 길을 아는 지에 대한 방법

명시적 브라우저 설정

• 대부분의 브라우저에는 프락시 서버에 접촉하기 위해 프락시 이름, 아이피 주소, 포트번호를 설정할 수 있는 풀다운 메뉴가 존재함 → 설정하면 브라우저는 모든 요청에 대해 프락시와 접촉함
  • 미리 설정돼있는 브라우저를 제공하기도 함
• 중요 단점
  • 프락시 사용 브라우저 → 프락시가 응답하지 않더라도 원 서버와 접촉 X
  • 네트워크 아키텍처 변경 시 변경사항을 모든 최종사용자에게 전파하는 것이 어려움

프락시 자동 설정

• PAC(Proxy Auto-Configuration) 프로토콜 → 브라우저가 동적으로 자신을 설정할 수 있게함
  • PAC파일 → FindProxyForUrl(url, host)가 정의된 js
  • 요청 URL마다 함수 호출
• 브라우저들이 URL별로 접촉해야 할 프락시를 지정한 PAC 파일을 찾도록 함 → 브라우저는 반드시 PAC 파일을 얻기 위해 지정된 서버에 접촉하도록 설정 + 재시작마다 PAC 파일을 가져옴
• DNS주소, 서브넷, 요일, 시각 등 여러 매개변수에 근거하여 프락시를 선택하도록 요구
• 프락시 위치 변경 시 PAC 파일만 업데이트하면됨

function FindProxyForURL(url, host) {
    // 접속하려는 URL 또는 호스트 이름을 소문자로 변환 (일관성 유지)
    url = url.toLowerCase();
    host = host.toLowerCase();
 
    // 1. 내부망(인트라넷) 사이트는 직접 연결
    if (isPlainHostName(host) ||
        shExpMatch(host, "*.local") ||
        isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0") ||
        isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0")) {
        return "DIRECT";
    }
 
    // 2. 특정 외부 도메인은 특정 프록시 사용
    if (shExpMatch(host, "*.example.com") ||
        shExpMatch(host, "example.org")) {
        return "PROXY proxy1.mycompany.com:8080";
    }
 
    // 3. 비디오 스트리밍 사이트는 다른 프록시 사용 또는 직접 연결
    if (shExpMatch(url, "http://*.youtube.com/*") ||
        shExpMatch(url, "http://*.netflix.com/*")) {
        return "PROXY media-proxy.mycompany.com:8888; DIRECT"; // media-proxy 실패 시 직접 연결
    }
 
    // 4. 그 외 모든 요청은 기본 프록시 사용
    return "PROXY default-proxy.mycompany.com:3128";
}

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file

웹 프락시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol , WPAD)

• 최종사용자가 수동으로 프락시 설정이나 트래픽 인터셉트에 의존하지 않고 브라우저가 근처 프락시를 찾아내어 사용
• PAC 파일 자동발견
  • WPAD 는 HTTP 클라이언트가 PAC 파일 위치를 알아내 적절한 프락시 서버 이름을 알 수 있게 함
  • 부하균형이나 장애 대처 등의 추가 기능을 위해 직접적으로 프락시 서버 이름을 알아내진 않음
  • WPAD 프로토콜 클라이언트 예시
    • WPAD 로 PAC CURL 탐색
    • URL 에 해당하는 PAC 파일을 받아옴
    • PAC 파일을 실행해 프락시 서버 알아냄
    • 프락시 서버에 요청
• WPAD 알고리즘
  • 적절한 PAC 파일 CURL을 결정하기 위해 여러 가지 리소스 발견 기법 사용
  • CURL을 얻는데 성공할 때 까지 순차실행
    • DHCP (Dynamic Host Configuration Protocol)
    • SLP (Service Location Protocol)
    • DNS에게 잘 알려진 호스트 명
      • 클라이언트는 자신의 호스트 이름이나 도메인 이름을 기반으로 특정 규칙에 따라 미리 약속된 호스트 이름(well-known hostname) 을 DNS 서버에 질의하는데, 이 과정에서 DNS 서버에 해당 wpad 호스트 이름에 대한 A 레코드(IP 주소)가 설정되어 있고, 해당 IP 주소의 웹 서버 특정 경로(보통 /wpad.dat)에 PAC 파일이 존재하면 클라이언트는 이 파일을 다운로드 (예: http://wpad.example.co.kr/wpad.dat)
    • DNS SRV 레코드
    • TXT 레코드의 DNS 서비스 URL 들
  • 찾으면 완료. 실패시 다시 시작
  • WPAD 클라이언트는 DHCP 와 DNS 에게 잘 알려진 호스트명만 요구됨
  • 모든 프로세스를 실패하면 프락시를 사용 안하는 것으로 설정
• DHCP를 이용한 CURL 발견
  • 클라이언트가 네트워크에 연결되어 IP 주소를 DHCP 서버로부터 할당받을 때, DHCP 서버는 IP 주소, 서브넷 마스크, 게이트웨이 정보 등과 함께 WPAD 옵션 (옵션 코드 252) 을 통해 PAC 파일의 URL을 클라이언트에게 알려줌. (DHCP 서버는 CURL을 저장하고 있어야 함)
  • 클라이언트가 이 옵션을 받으면, 해당 URL에서 PAC 파일을 다운로드하여 프록시 설정을 구성
  • OS의 API를 통해 DHCP가 보낸 값을 얻을 수 없으면 DHCPINFORM 메시지를 DHCP 서버에게 보내 질의해서 얻음
  • 이 방식은 DHCP 서버에서 중앙 집중적으로 PAC 파일 위치를 관리할 수 있음

CURL(Configuration URL) DHCP Option 252: http://wpad.company.local/wpad.dat와 같이 클라이언트가 DHCP 서버에 요청을 보내면 Configuration URL을 반환하고 이 CURL을 사용하여 PAC 파일을 다운로드 할 수 있는 URL HTTP 요청 툴인 curl과 혼동할 수 있다.

• DNS A 레코드 룩업 방식
  • 프락시 서버의 IP 주소들이 DNS 서버에 저장되어있어야 메커니즘 동작
  • 모든 룩업 요청은 wpad 접두어가 붙은 QNAME 을 가짐
  • 룩업에 성공하면 WPAD 클라이언트가 구축한 URL의 IP 주소를 얻음
• PAC 파일 가져오기
  • 위의 방법으로 얻어온 CURL 로 GET 요청
  • 클라이언트가 다룰 수 있는 CFILE 포맷 정보가 담긴 Accept 헤더가 포함되어야 함
  • CURL의 결과가 리다이렉트 → 리다이렉트가 향하는 곳이 클라이언트의 최종 목적지
• 언제 WPAD를 실행하는가
  • 웹 클라이언트가 시작될 때(첫 인스턴스의 시작때만 수행)
  • 클라이언트 호스트의 IP 주소가 변경된 네트워킹 스택으로부터 어떤 언급이 있을 떄마다
  • PAC 파일이 만료 → WPAD 프로세스 재실행
  • PAC 파일을 무효화 → WPAD 프로토콜 재실행
    • WPAD는 If-Modified-Since 조건부 요청으로 PAC 파일 가져오기 지원 X
  • WPAD 프로토콜 브로드캐스트, 멀티 캐스트 커뮤니케이션을 위한 네트워크 왕복을 제외하고 더 자주 동작해서는 안됨
• WPAD 스푸핑(spoofing)
  • 클라이언트는 DHCP 또는 DNS를 통해 wpad.dat 파일의 위치를 찾는데, 이 과정에서 ‘wpad’ 도메인 이름의 절대 표기 앞에 붙여 가짜 WPAD 서버를 제공
  • 사용자의 트래픽을 공격자가 지정한 악성 프록시 서버로 우회시키는 공격
  • 보안 취약점으로 작용하여 악의적인 사용자가 WPAD 서버 설정 후 의도대로 프락시가 설정되도록 하는 명령을 제공할 수도 있음
• 타임아웃
  • 클라이언트는 각 단계가 일정한 시간 내에 끝나는지 반드시 확인해야 함
  • 네트워크 특성에 맞는 값 선택하기
• 관리자를 위한 고려사항
  • 클라이언트가 반드시 구현 → DHCP & DNS A 레코드
  • 관리자 → DHCP || DNS A 중 하나 설정

캐시 리다이렉션 방법

WCCP(캐시 조직 프로토콜) 리다이렉션

시스코 시스템즈에서 웹 트래픽을 프락시 캐시로 리다이렉트 할 수 있도록 개발 라우터들과 캐시들 사이의 대화를 관리하여 라우터가 캐시 검사 → 특정 종류의 트래픽을 특정 캐시로 보냄 해당 절에서 다루는 WCCP는 WCCP 버전 2로, 개방형 프로토콜 라우터/스위치 ↔ 캐시 서버 간의 통신을 관리

WCCP 리다이렉션 동작

• WCCP를 사용할 수 있는 네트워크 → 라우터와 캐시와 소통할 수 있는 캐시가 필요.

• 라우터들의 집합 & 대상 캐시 → WCCP 서비스 그룹

• 서비스 그룹이 HTTP 트래픽을 리다이렉션하도록 설정 → 라우터가 HTTP 요청을 서비스 그룹의 캐시로 보냄

• HTTP 요청이 서비스 그룹 라우터에 도착하면 라우터가 요청 처리를 위해 캐시 선택

  • 요청 아이피 주소의 해시값이나 마스크/값 집합 짝짓기

• 요청 패킷을 캐시의 아이피 주소와 함께 캡슐화하거나 아이피 맥 포워딩을 통해 캐시로 보냄

• 캐시가 요청을 처리 못하면 라우터로 돌아와 평범한 포워딩

• 서비스 그룹의 구성원은 하트비트 메시지를 교환함으로써 구성원의 가용성 확인

• 등록(Registration)
  캐시 서버(Squid 등)는 WCCP를 지원하는 라우터/스위치에 “나 여기 있어요!” 하고 등록

• 협상(Negotiation)
  라우터는 캐시 서버와 통신하여 정책(포트, 프로토콜 등)을 협상

• 리디렉션(Redirection)
  클라이언트가 HTTP 요청을 하면 라우터가 이 요청을 캐시 서버로 리디렉션 가로챈 패킷은 협상된 리디렉션 방법을 사용하여 지정된 WCCP 클라이언트(어플라이언스)로 전달

  • GRE (Generic Routing Encapsulation) 리디렉션: 패킷을 GRE 터널로 캡슐화하여 어플라이언스로 전송. 어플라이언스가 다른 네트워크 세그먼트에 있어도 사용 가능하지만, 약간의 오버헤드가 발생.
  • L2 (Layer 2) 리디렉션: 패킷의 MAC 주소를 어플라이언스의 MAC 주소로 변경하여 전달. 라우터와 어플라이언스가 동일한 로컬 네트워크(브로드캐스트 도메인)에 있어야 하며, 오버헤드가 거의 없음.

• 응답 처리
  캐시 서버는 요청된 컨텐츠를 제공하거나 원 서버에서 가져온 뒤 캐시하여 응답

GRE 터널 패킷을 캡슐화하여 다른 네트워크를 통해 전달하는 터널링 기술로, 주로 서로 다른 네트워크를 연결하거나, VPN, 또는 리디렉션에 사용.

WCCP2 메시지

메세지 구성요소

• 각 WCCP2 메세지는 헤더와 구성요소로 되어있음
• 헤더는 메세지 종류, 버전, 길이를 포함
• 각 구성요소는 종류와 길이를 서술하는 4바이트 헤더로 시작
  • 구성요소 길이는 헤더의 길이를 포함하지 않음
    

서비스 그룹

• WCCP를 지원하기 때문에 WCCP 메시지를 교환할 수 있는 라우터와 캐시들의 집합으로 구성된 그룹.
• 라우터 → 서비스 그룹의 캐시로 트래픽을 보냄
• 서비스 그룹의 설정 = 어떻게 트래픽이 서비스 그룹의 캐시들로 분산되는지 결정
• 라우터 ←> 캐시 Here I Am / I See you 메시지로 서비스 그룹 설정 정보 교환

GRE 패킷 캡슐화

• WCCP 지원 라우터는 HTTP 패킷을 특정 서버의 IP 주소와 함께 캡슐화함으로써 그 서버로 리다이렉트
• 일반 라우터 캡슐화(Generic Router Encapsulation, GRE)임을 나타내는 IP 헤더 proto 필드도 포함
  • proto 필드 → 패킷이 캡슐화되어있음을 알려줌

WCCP 부하 균형

• WCCP 라우터를 통해 여러 수신 서버 간의 부하 균형 유지
• 라우터와 수신 서버가 서로 하트비트 메시지 교환
• 수신 서버가 메시지를 보내지 않으면 인터넷으로 바로 보냄
  • 노드가 정상화되면 로직도 정상화

인터넷 캐시 프로토콜(ICP)

• 캐시들이 형제 캐시에서 일어난 캐시 히트를 찾아볼 수 있도록 해줌
• 일종의 객체 발견 프로토콜
• 캐시가 HTTP 메시지에서 요청한 콘텐츠가 없다면 캐시는 근처의 형제 캐시 중 그 콘텐츠를 갖고 있는 것이 있는지 찾아보고 있다면 캐시에서 가져옴
• 일종의 캐시 클러스터링 프로토콜
• 한 차례 이상의 ICP 질의 → HTTP 요청 메시지의 목적지를 결정한다는 점에서 리다이렉션 프로토콜
• 근처의 캐시에게 특정 URL을 가지고 있는지 물어보고 가지고 있는 이웃 캐시에 대해 HTTP 커넥션을 열음
• 32비트 구조체로 단순하고 가벼움
• 효율을 위해 UDP 다이어그램 전송

1. 사용자가 Squid 프록시 서버에 요청
2. Squid가 자기 캐시에 해당 콘텐츠가 없을 경우, 다른 캐시 서버에게 ICP QUERY 메시지를 보냄
3. 다른 캐시 서버는 해당 콘텐츠를 가지고 있다면 ICP HIT, 없다면 ICP MISS로 응답
4. 응답을 바탕으로:
   • HIT이면 해당 서버에서 가져오고
   • MISS면 원 서버에서 직접 요청

ICP의 각 부분

• OP 코드 : ICP 메시지의 의미를 가진 8비트 값
• 버전 : 프로토콜의 버전
• 메시지 길이 : 16비트
• 요청 번호 : 여러 요청과 응답을 추적하기 위함(요청은 응답과 같은 요청 번호)
• 옵션 : ICP 동작을 변경하는 플래그
• 옵션 데이터
  • 32비트 옵션 기능
  • 하위 16비트를 형제로부터 원 서버까지 왕복 시간 측정값
• 발송자 호스트 주소
  • 32비트 아이피 주소
• 페이로드
  • ICP_OP_QUERY
    • ICP_OR-QUERY 요청 메시;지
  • ICP_OP_HIT& OBJ : NUL로 끝나는 URL, 16비트 객체 크기, 객체 데이터

캐시 배열 라우티 프로토콜(CARP)

• 대량의 트래픽은 프락시 서버 자체에 과도한 부하를 줄 수 있음 → 프락시 서버를 늘리면 됨.
• 캐시 배열 라우팅 프로토콜을 통해 프락시 서버의 배열이 하나의 논리적인 캐시처럼 보이도록 관리
• ICP의 대안으로도 사용
• ICP의 경우
  • 캐시 비적중 시 이웃 캐시들에게 ICP 메시지를 보내고 질의한 후 가장 적절한 위치를 선택
  • 콘텐츠가 중복되어 존재해서 재배치 필요없음
  • ICP 프로토콜만을 수행하는 기존 프락시 서버는 CARP 무리에 쉽게 포함될 수 없음
• CARP의 경우
  • 각 구성요소 서버가 전체 캐시된 문서의 일부만 갖고있는 하나의 큰 서버로 동작
  • URL에 해시 함수 → 특정 프락시 서버에 매핑
• 단점
  • 프락시 서버에 변화가 생기면 해시 함수 수정 필요
  • 프락시 전체에 퍼져 있는 콘텐츠들도 다시 배치하지 않을 수 없음 → 하나의 프락시가 실패하면 상당량의 캐시 콘텐츠 재배치
  • 고장 수리 비쌈
• 클라이언트들 스스로가 이 기능을 제공하는 것도 가능
• 결정론적인 프락시 서버 분석 → 질의를 모든 이웃에게 보낼 필요는 없음.
  • 한 홉 안에 있는 특정 웹 객체의 거처를 찾아냄
• CARP의 리다이렉션
  • 참여하는 프락시 서버의 테이블 유지 + 주기적 폴링
  • 각 프락시 서버 해시 함수 계산
  • 요청된 웹 객체의 URL에 근거한 숫자값을 반환하는 분리된 해시 함수 정의
  • URL 해시 함수와 프락시 서버의 해시 함수의 합계로 값의 배열을 얻음

하이퍼텍스트 캐싱 프로토콜

┌────────────────────────┐
│       Client           │
│  (웹 브라우저 등)         │
└─────────┬──────────────┘
          │ HTTP Request
          ▼
┌────────────────────────┐
│   Proxy/Cache Server A │◄────────────┐
│  (HTCP Agent 포함)      │             │
└─────────┬──────────────┘             │ HTCP
          │                            │
          ▼                            │
┌────────────────────────┐             │
│    Origin Server       │             │
│ (웹 콘텐츠 제공자)         │             │
└────────────────────────┘             │
                                       │
                            ┌──────────┴────────────┐
                            │   Proxy/Cache Server B│
                            │   (HTCP Agent 포함)    │
                            └───────────────────────┘

• URL만을 보내는 ICP → 하이퍼텍스트 캐싱 프로토콜을 통해 URL + 요청 및 응답 헤더의 사용으로 잘못 적중할 확률을 줄임

• 형제 캐시들이 서로의 캐시 안에 있는 선택된 문서의 추가 및 삭제를 모니터링 + 요청

• 서로의 캐시된 문서에 대한 캐싱 정책을 변경할 수 있게 해줌

• 근처 캐시가 그 문서를 갖고 있을 경우 요청 캐시는 그 캐시에 HTTP 커넥션을 열고 그 문서를 가져옴

  +---------------------+ | HEADER | tells message length and protocol versions +---------------------+ | DATA | HTCP message (varies per major ver. number) +---------------------+ | AUTH | optional authentication for transaction +---------------------+ 의 구조를 지님.

HTCP 환경에서 캐시 서버들은 서로 이웃(neighbor)으로 설정됨. 특정 캐시 서버가 클라이언트로부터 요청을 받았을 때, 로컬 캐시에 해당 객체가 없다면 HTCP를 사용하여 이웃 캐시들에게 정보를 요청하거나 특정 작업을 지시하게 됨.

1. 요청 발생 및 로컬 캐시 확인: 사용자가 특정 웹 객체를 프록시 캐시 서버 A에 요청하면, 서버 A는 먼저 자신의 로컬 캐시를 확인.
2. HTCP 메시지 전송: 로컬 캐시에 객체가 없거나 정보가 불확실할 경우, 서버 A는 이웃 캐시 서버 B에게 HTCP 메시지를 보냄. 이때 요청하는 작업의 종류(예: 객체 정보 질의, 삭제 요청 등)에 따라 다른 HTCP 메시지 유형을 사용.
3. 이웃 캐시의 처리 및 응답: 메시지를 받은 서버 B는 해당 HTCP 요청을 처리하고 그 결과를 서버 A에게 응답으로 보냄. 응답에는 요청된 정보(예: 객체의 존재 유무, HTTP 헤더, 속성 등)가 포함될 수 있음
4. 결정 및 데이터 전송/관리: 서버 A는 수신한 HTCP 응답을 바탕으로 다음 행동을 결정. 예를 들어, 이웃 캐시 B에 원하는 객체가 있다면 HTTP를 통해 B로부터 객체를 가져올 수 있음. 또는, 객체 삭제 요청이 성공적으로 처리되었음을 확인할 수 있음

특징	ICP (Internet Cache Protocol)	HTCP (Hypertext Caching Protocol)
주요 목적	객체 존재 유무 질의	객체 존재 유무, 상세 메타데이터 질의, 캐시 관리
교환 정보	주로 URL	URL, HTTP 헤더 정보, 상세한 객체 메타데이터
전송 프로토콜	주로 UDP	주로 TCP (신뢰성), UDP도 사용 가능
캐시 관리 기능	제한적 또는 없음	객체 삭제 요청(CLR), 모니터링(MON) 등 지원
메시지 복잡도	단순	상대적으로 복잡 (더 많은 정보 포함)
신뢰성	UDP 기반으로 메시지 유실 가능성	TCP 기반 시 신뢰성 있는 메시지 전달
오버헤드	메시지 크기가 작고 빠름	메시지 크기가 상대적으로 크고, TCP 사용 시 오버헤드 발생 가능

구조

• 헤더
  • 32비트 메시지 길이
  • 8비트 주 프로토콜 버전
  • 8비트 부 프로토콜 버전
  • 메시지 길이는 모든 헤더, 데이터, 인증 크기를 포함
• 데이터
• 인증(선택적임)
• (+) 캐싱 정책 설정
  • SET 메시지 → 캐시된 문서에 대한 정책 변경 요청
  • SET 메시지에서 사용할 수 있는 헤더가 따로 정의되어 있어 질의 메시지에 담아 형제 캐시로 보냄으로써 거짓 적중의 비율을 줄임
  • 형제 캐시들이 정책 정보를 서로 교환할 수 있게 함으로써 서로를 더 잘 도울 수 있도록 함