Chapter 20. Redirection and Load Balancing
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 요약
Cache Redirection Methods
캐싱 프록시 서버에서 사용되는 정교한 리디렉션 기술
- Reliable & High-performance & Content-aware
- 특정 콘텐츠가 있을 확률이 높은 위치에 요청 전송
WCCP Redirection
- 라우터가 프록시 캐시로 웹 트래픽을 리디렉션하기 위한 프로톸콜
- [기능1] 캐시 식별 (이용 가능한가? 현재 동작 중인가?)
- [기능2] 캐시 간 로드밸런싱
- [기능3] 특정 유형의 트래픽을 특정 서버로 전달
WCCP2의 동작 방식
- WCCP-enabled 라우터와 캐시가 포함된 네트워크에서의 통신 상황 가정
- WCCP 서비스 그룹 생성
- 서비스 그룹 구성 : 트래픽 유형, 트래픽 전송 방식, 부하 분산 방식 정의
- 서비스 그룹에 포함된 라우터가 HTTP 트래픽을 캐시로 리디렉션
- 라우터는 서비스 그룹에 포함된 캐시 중 하나를 선택해서 요청 전달
- 캐시의 IP 주소를 캡슐화하거나 IP MAC 주소를 포워딩
- 캐시가 요청을 제공할 수 없는 경우
- 패킷이 라우터로 반환되어 일반적인 포워딩 수행
- 서비스 그룹에 포함된 요소 간 heartbeat 메시지를 주고받을 수 있다
WCCP2 메시지의 유형
WCCP2_HERE_I_AM: 캐시 -> 라우터WCCP Message Header Security Info Component Service Info Component Web-cache Identity Info Component Web-cache View Info Component Capability Info Component (optional) Command Extension Component (optional)- 캐시가 트래픽을 수용할 수 있음을 라우터에 전달
WCCP2_I_SEE_YOU: 라우터 -> 캐시WCCP Message Header Security Info Component Service Info Component Router Identity Info Component Router View Info Component Capability Info Component (optional) Command Extension Component (optional)- WCCP2_HERE_I_AM의 응답
- 패킷 포워딩 방식, 할당 방식, 패킷 반환 방식, 보안 방식 등을 협의하는 데 사용
WCCP2_REDIRECT_ASSIGN: 지정된 캐시 -> 라우터WCCP Message Header Security Info Component Service Info Component Assignment Info Component, or Alternate Assignment Component- 로드 밸런싱을 위한 할당 정보 전달
WCCP2_REMOVAL_QUERY: 라우터 -> 캐시WCCP Message Header Security Info Component Service Info Component Router Query Info Component- 정해진 기간 동안 WCCP2_HERE_IAM을 전송하지 않은 캐시를 서비스 그룹에서 삭제
WCCP2 메시지의 구성 요소
GRE packet encapsulation
- GRE(Generic Router Encapsulation) : 패킷을 리디렉션할 때 클라이언트와 서버의 IP 주소를 캡슐화하는 것
- IP 헤더 프로토 필드 보유
- 패킷을 받는 프록시에 패킷이 캡슐화되어 있음을 알릴 수 있다
- 캡슐화로 인해 클라이언트 IP 주소가 손실되지 않는다
WCCP load balancing
- Heartbeat messages : 서비스 그룹 내 요소 간 동작(running) 여부를 확인하기 위해 사용
- Heartbeat message가 없는 경우 WCCP 라우터는 트래픽을 바로 인터넷으로 전송한다
Internet Cache Protocol
한 캐시가 Sibling Caches에서 콘텐츠를 찾을 수 있게 하는 프로토콜
- Sigling Caches : 동일한 계층에 위치한 캐시들 (not downstream, upstream)
- 캐시가 HTTP 메시지로부터 요청받은 콘텐츠를 보유하고 있지 않은 경우
- 근처의 Sibling Cache에서 콘텐츠 탐색
- Sibling Cache에서 콘텐츠를 발견한 경우 원본 서버로 요청 전송 X -> 비용 감소
- Cache Clustering Protocol
- 일련의 ICP 쿼리를 통해 HTTP 요청의 최종 도착지가 달라진다
- Object Discovery Protocol
- 특정 URL에 대해 HIT 응답과 MISS 응답을 보낸다
- 캐시는 인근 캐시와 자유롭게 HTTP 연결을 열고 오브젝트가 존재하는지 확인 가능
- Simple and Lightweight
- 32비트의 ICP 메시지, 간단한 파싱
- UDP 데이터그램을 통한 전달 -> 높은 전송 효율 but 손실 가능
- ICP를 사용하는 프로그램은 타임아웃 기능과 손실된 데이터그램을 감지할 수 있는 기능을 가져야 한다
ICP 메시지의 구성요소
Opcode: ICP 메시지의 의미를 나타내는 8비트 값, ICP_OP_QUERY 요청 메시지, ICP_OP_HIT, ICP_OP_MISS 로 구성Version: ICP 프로토콜의 버전 번호 (RFC 2186)Message length: ICP 메시지의 전체 바이트 크기를 나타내는 16비트 값 -> ICP 메시지 크기는 16383 바이트를 초과할 수 없고 URL의 길이는 16KB보다 짧아야 한다Request number: 요청 번호 -> 1번 요청에 대한 응답에도 동일한 번호가 포함되어야 한다Options: ICP의 동작을 제어하기 위한 32비트 bit vector- ICP_FLAG_HIT_OBJ : ICP 응답에 문서 데이터를 포함할 것인지 여부
- ICP_FLAG_SRC_RTT : Sibling Cache에 의해 측정된 원본 서버까지의 왕복 시간 추정치를 포함할 것인지 여부
Option data: 부가적인 기능을 위해 사용되는 32비트 데이터- ICPv2는 16비트를 Sibling Cache에서 원본 서버까지의 왕복 시간 추정치를 담는 데 사용
Sender host address: 메시지 송신자의 32비트 IP 주소 (실제로는 사용되지 않는다)Payload: 메시지 유형에 따라 서로 다른 내용 보유- ICP_OP_QUERY : 요청자의 호스트 주소(4바이트)와 NUL-terminated URL
- ICP_OP_HIT_OBJ : NUL-terminated URL과 16비트의 오브젝트 크기
✏️ 코멘트
무지성으로 개발을 하다 보면 아무래도 HTTP 자체에만 집중하게 되는 것 같다. 클라이언트와 서버 사이에 존재하는 수많은 라우터들이 어떻게 패킷을 주고받는지는 딱히 관심도 없고 흐린 눈으로 봐왔다. 근데 원리를 알고 보니 좀 재밌다.
네트워크 내에서 라우터와 캐시 풀을 구성하고 WCCP라는 프로토콜을 통해 성능을 개선하고 있다는 것을 알게 됐다. 같은 계층의 Cache간 탐색이 필요할 때는 ICP를 사용한다는 것, 캐시간 빠른 통신을 위해 UDP 위에 구현된다는 것도 알게 됐다.
이 세상에는 참 신기한 프로토콜이 많은 것 같다.
틈틈이 두 페이지씩 원서 읽기