HTTP완벽가이드 스터디 19, 20장

19장 배포 시스템

https://bebiangel.github.io/2020/02/10/http-guide-chap19/

19장 배포 시스템

1. WebDav

• 웹 분산 저작과 버저닝(Web Distributed Authoring and Versioning)
• 공동 저작에 적합한 플랫폼을 제공하려고 HTTP를 확장하는데 집중한다.

2. WebDav와 공동저작

2.1 WebDav와 XML

• WebDav의 메서드는 요청과 응답 관련 정보를 모두 잘 다루어야함
• WebDav는 여러개의 리소스나 계층 관계에 있는 리소스들에 대해 정보를 선택적으로 헤더에 기술하기 위해서 XML포맷을 지원한다.

2.2 WebDav헤더

• WebDav는 새로운 메서드들의 기능을 넓혀주는 여러 HTTP메서드를 도입했다
• 모든 리소스는 OPTIONS 요청에 대한 응답에 이 헤더를 포함해야한다.
• Depth는 계층 구조로 분류된 리소스 사용에 용이하다.
• Destination은 COPY나 MOVE 메서드가 목적지 URI를 식별하는데 사용한다.

2.3 WebDav 잠금과 덮어쓰기 방지

• WebDav는 잠금이라는 개념을 지원한다
• 잠금은 완벽하지 않으므로 버저닝과 메시징을 지원해야한다
• 잠금을 수행하기 위해서는 다이제스트 인증을 요구한다

2.4 속성과 META 데이터

• 속성에는 저작자의 이름, 수정한 날자, 내용 등급 등 리소스의 정보를 기술한다.
• 속성의 발견과 수정을 지원하기 위해, WebDav는 PROFIND와 PROPPATCH라는 새로운 메소드를 추가한다.

2.5 콜렉션과 이름공간 관리

• 콜렉션은 리소들의 논리적 혹은 물리적 그룹이다.
• 파일시스템의 디렉터리 같이 다른 리소스들의 컨테이너처럼 동작한다.
• WebDav는 XML 이름 공간 메커니즘을 사용한다.
• 이름공간 파티션들은 충돌이 생기지 않고 명확한 구조적 제어기능을 제공한다.

2.6 MKCOL 메서드

• 클라이언트가 지정된 URL에 해당하는 콜렉션을 서버에 생성하게 한다.
• WebDav 프로토콜은 새로운 메서드를 정의하는 방식을 사용한다.

2.7 DELETE 메서드

• 디렉터리를 지우기 위해서는 Depth 헤더를 필요로한다.
• Depth가 없다면, DELETE 메서드는 Depth 헤더가 무한으로 설정되어 있다고 가정한다.
• 디렉터리와 그 하위에 있는 모든 디렉터리가 지워진다.

2.8 COPY와 MOVE 메서드

• COPY 메서드는 리소스에 GET 요청을 보내고, 리소스를 다운 받은 다음, PUT 요청과 함께 서버에 리소스를 다시 올리는 것이다.
• MOVE는 DELETE메소드를 포함한 COPY와 비슷하게 동작한다.
• MOVE 메서드는 원본지 URL을 목적지에 복사하고, 새로 생성된 URI의 무결성을 검사하고, 원본을 지운다.

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

http://tlog.tammolo.com/blog/20-6f2bc9c8b06e49b4a1e5884625dc6694/

 

웹에서 HTTP는 혼자가 아니다. HTTP 메시지의 데이터는 많은 프로토콜에 의해 통제된다. HTTP에는 주요 관심사는 출발지와 목적지인데, 미러링된 서버, 웹 프락시, 캐시가 함께하는 웹의 세계에서 목적지는 간단하지 않다.

리다이렉션 기술은 보통 메시지가 프락시, 캐시, 서버 팜의 특정 웹 서버 중 어디에서 끝나는지 판별하기 위해 사용한다.

이 장에서 다룰 내용

• HTTP 리다이렉션
• DNS 리다이렉션
• 임의 캐스트 라우팅
• 정책 라우팅
• 아이피 맥 포워딩
• 웹 캐시 조직 프로토콜(WCCP)
• 인터캐시 커뮤니케이션 프로토콜(ICP)
• 하이퍼텍스트 캐싱 프로토콜(HTCP)
• 네트워크 요소 제어 프로토콜(NECP)
• 캐시 배열 라우팅 프로토콜(CARP)
• 웹 프락시 자동발견 프로토콜(WPAD)

20.1 왜 리다이렉트 인가?

리다이렉션을 하는 이유는 다음의 사항을 개선하기 위함이라 한다.

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

웹 콘텐트를 여러 장소에 배포하면, 한 곳에서 실패해도 다른 곳에서 얻을 수 있기 때문에 신뢰성이 개선된다.

리다이렉션이란 최적의 분산된 콘텐츠를 찾는 것을 도와주는 기법의 집합이라 생각할 수 있다. 클라이언트와 가장 가까운 곳으로 연결하므로 지연을 최소화 하고 불필요한 네트워크 대역폭을 줄 일 수 있다.

20.2 리다이렉트 할 곳

클라이언트 관심에서 서버, 프락시, 캐시, 게이트웨이는 모두 서버라 할 수 있다. 그런데 어떤 리다이렉션 기술은 특정 종류의 종단에서만 사용하도록 설계되었다. 뒤 에서 일반적인 기법과 특화된 기법을 보게 될 것이다.

리다이렉트할 곳은 간단명료하다. 클라이언트가 원하는 자원이 있는 가장 가까운 곳.

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

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

• 브라우저 애플리에션의 사용자는 브라우저가 클라이언트 메시지를 프락시 서버로 보내도록 설정할 수 있다.
• DNS resolver는 메시지의 주소를 지정할 때 사용될 아이피 주소를 선택한다. 클라이언트의 위치에 따라 달라질 수 있다.
• 메시지는 여러 패킷으로 나뉘어 전송되고 스위치와 라우터들은 패킷의 TCP/IP 주소를 검증하고 어떻게 패킷을 라우팅 할지 결정한다.
• 웹 서버는 HTTP 리다이렉트를 이용해 요청이 다른 웹 서버로 가도록 할 수 있다.

20.4 일반적인 리다이렉션 방법

20.4.1 HTTP 리다이렉션

HTTP 메시지에 리다이렉트 할 URL을 넘겨주는 방식으로 동작한다. 다음의 메시지의 예시를 보자.

• 클라이언트

GET /hammers.html HTTP/1.0

Host: www.joes-hardware.com

User-Agent: Mozilla/4.51 [en] (X11; U; IRIX 6.2 IP22)

 

• 서버

HTTP/1.0 302 Redirect

Server: Stronghold/2.4.2 Apache/1.3.6

Location: http://161.58.228.45/hammers.html

 

• 클라이언트

GET /hammers.html HTTP/1.0

Host: 161.58.228.45

User-Agent: Mozilla/4.51 [en] (X11; U; IRIX 6.2 IP22)

 

이러한 동작 에는 단점이 있다. 두 번의 왕복을 하기 때문에 응답이 지연된다. 또, 리다이렉트 서버가 고장이 나면 사이트가 고장 난다.

20.4.2 DNS 리다이렉션

클라이언트가 요청한 주소의 도메인 이름을 반드시 아이피 주소로 분석해야 한다. DNS resolver는 클라이언트의 운영체제이거나 클라이언트에 연결된 어떤 DNS 서버일 것이다.

DNS 라운드 로빈

DNS 라운드 로빈은 가장 흔하면서 또 가장 단순한 리다이렉션 기법이다.

다음은 www.cnn.com 에 할당된 IP주소 목록이다.

% nslookup www.cnn.com

Name:    cnn.com

Addresses:  207.25.71.5, 207.25.71.6, 207.25.71.7, 207.25.71.8

          207.25.71.9, 207.25.71.12, 207.25.71.20, 207.25.71.22, 207.25.71.23

          207.25.71.24, 207.25.71.25, 207.25.71.26, 207.25.71.27, 207.25.71.28

          207.25.71.29, 207.25.71.30, 207.25.71.82, 207.25.71.199, 207.25.71.245

          207.25.71.246

Aliases:  www.cnn.com

 

Addresses에 있는 여러 IP 중 어떤 것을 선택해도 결과는 갖다. 그런데 보통의 웹 서버는 저 목록 중 첫 번째 값을 사용하여 접근한다. 그러면 첫 번째 서버에 대한 부하가 심하게 걸릴 것이다. 그래서 라운드 로빈 방식을 써서 Addresses의 목록의 순서가 순회되도록한다. 실제로 nslookup www.cnn.com 명령어를 실행할 때마다 Addresses의 순서를 다르게 나온다.

라운드 로빈 방식은 실제 서버에 부하를 체킹해서 리다렉션하지 않지만, 대부분의 상황에서는 문제가 되지 않는다.

다른 DNS 기반 리다이렉션 알고리즘

부하 균형 알고리즘, 근접 라우팅 알고리즘, 결함 마스킹 알고리즘

일반적으로, 복잡한 서버 추적 알고리즘을 실행하는 DNS 서버는 콘텐츠 제공자의 통제하에 있는 권한이 있는 서버다.

20.4.3 임의 캐스트 어드레싱

웹 서버는 라우터 통신 프로토콜을 이용해 자신과 인접한 백본 라우터와 대화한다. 백본 라우터가 임의 캐스트 주소를 목적지로 하는 패킷을 받았을 때, 미리 대화를 한 상태기 때문에 가장 가까운 라우터로 패킷을 보내게 된다.

20.4.4 아이피 맥 포워딩

레이어-4 장비에서 출발지와 목적지의 아이피 주소와 TCP 포트번호를 사용해 라우팅 했다면, 레이어-2 장비에서는 MAC(Media Access Control)주소를 사용하여 포워딩 한다.

대표적 레이어-2 장비인 스위치 중 레이어-4 주소를 이해할 수 있는 장비가 있는데, 이 장비는 아이피 주소, TCP 포트번호 MAC 주소를 활용하여 다른 아이피 주소 또는 MAC 주소로 라우팅 할 수 있다.

MAC 포워딩을 지원하는 레이어-4 스위치는 보통 요청을 여러 프락시 캐시로 보낼 수 있고 그들 사이의 부하 균형을 유지할 수 있다.

Mac 주소 포워딩은 점 대 점으로만 가능하기 때문에 스위치-서버, 스위치-프락시 간 한 홉 거리에 위치해야한다는 제약이 있다.

20.4.5 아이피 주소 포워딩

레이어-3 종단간 인터넷 라우팅이 패킷을 올바른 위치에 보내준다. 이러한 종류의 전달은 NAT(Network Address Translation)이라고도 불린다. MAC 포워딩 처럼 한 홉간 거리라는 제약은 없지만, 라우팅 대칭성이라는 문제가 있다. 클라이언트로부터 들어오는 TCP 커넥션을 받아주는 스위치는 그 커넥션을 관리하고 있다. 스위치는 반드시 그 커넥션을 통하여 응답을 돌려줘야 한다.

응답의 귀환 경로를 제어할 수 있는 두 가지 방법이 있다.

• 패킷의 출발지 아이피 주소를 스위치의 아이피 주소로 바꾼다. 그러나 클라이언트의 IP주소를 잊기 때문에 서버는 클라이언트의 IP주소를 통한 인증이나 검증을 할 수 없게 된다.
• 해당 스위치를 거치지 않고 갈 수 있는 경로를 존재하지 않게 하면 된다. 이 방법의 단점은 클라이언트와 서버 사이의 전체 네트워크를 약간 통제해야 하는 것이다.

20.4.6 네트워크 구성요소 제어 프로토콜(NECP: Network Element Control Protocol)

NE(Network Element): 라우터나 스위치

SE(Server Element): 웹 서버, 프락시 캐시

NECP는 NE와 SE들이 대화할 수 있게 하여 SE가 적합하다고 판단하는 선에서 NE가 부하 균형을 유지하도록 한다.

20.5 프락시 리다이렉션 방법

20.5.1 명시적 브라우저 설정

브라우저에는 프락시 서버를 사용하기 위해 프락시 이름, 아이피 주소, 포트번호를 설정할 수 있는 메뉴가 존재한다. 브라우저의 모든 요청에 대해 프락시를 통할 수 있도록 설정할 수 있다.

명시적인 브라우저 설정의 단점이 두 가지 있다. 프락시가 응답하지 않으면 원래 목적 서버로 요청이 가지 않는다는 점이다. 또, 네트워크의 아키텍쳐가 변경되었을 때 모든 프락시에 전파하는 것이 어렵다.

20.5.2 프락시 자동 설정(PAC: Proxy Auto-configuration)

프락시에 대한 정보를 사용자가 입력하는 것이 아니라 별도의 프락시 설정 파일을 사용하는 것이다. 브라우저들이url마다 접촉해야할 프락시를 지정한 PAC파일을 가져오도록 한다. 브라우저는 재시작할 때마다 PAC 파일을 가져오게 된다.

PAC 파일을 자바스크립트로 작성된 파일로 간략하게 다음 그림으로 이해할 수 있다.

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

P 541

브라우저마다 PAC파일을 발견하는 것에 차이가 있기도 해서 좀 더 구체적이고 명확하게 프록시를 사용하도록 하는 방법.

20.6 캐시 리다이렉션 방법

신뢰성이 높고, 고성능에, 콘텐츠 지각 디스패칭, 콘텐츠의 특정 일부를 갖고 있을 것으로 추정되는 곳으로 요청 하는 기능 등으로 앞서 다뤘던 프로토콜 보다 복잡하다.

20.6.1 WCCP 리다이렉션

시스코 시스템즈에서 개발한 WCCP는 라우터들과 캐시들 사이의 대화를 관리하여 캐시의 상태를 확인하는 특정 종류의 트래픽을 캐시에 보낼 수 있게 한다.

WCCP 리다이렉션 동작