[HTTP 완벽 가이드] 5부 학습

18장: 웹 호스팅

• 웹 호스팅: 컨텐츠 리소스를 저장, 중개, 관리하는 일
• 웹 호스팅을 위해 서버가 필요하다.

호스팅 서비스

• 전용 호스팅은 개발자가 ISP로부터 직접 자체 서버를 구매해 사용하는 방식이다.

가상 호스팅

• 공유 호스팅/가상 호스팅: 웹 호스팅 업자는 컴퓨터 한 대를 여러 고객이 공유하게 해 저렴한 웹 호스팅 서비스를 제공한다.
• 호스팅 업자는 복제 서버 더미(서버 팜)을 만들고 부하를 분산한다.
• 하지만 HTTP 요청에 호스트 정보가 없다면 공용 웹 서버가 호스팅하고 있는 가상 웹 사이트 중 어떤 곳에 접근하려고 하는지 알 수 없다.
• 위 문제를 해결하기 위한 방법은 다음과 같다.

1. URL 경로를 통한 가상 호스팅

• URL 자체에 원하는 웹 서버를 명시하도록 API를 작성하는 방식이다.
• 호스트명이 URL에 포함되어 불필요하고 혼란스럽기 때문에 좋지 않다.

2. 포트번호를 통한 가상 호스팅

• 웹 서버에 각각 다른 포트번호를 할당하는 방식이다.
• 사용자는 URL 표준 포트(스킴 기본 포트)를 사용하고 싶을 수 있다.

3. IP 주소를 통한 가상 호스팅

• 웹 서버에 각각 가상 IP 주소를 할당하고 모든 가상 IP 주소는 같은 공용 서버에 연결하는 방식이다.
• IP 주소 부족 문제가 생길 수 있지만 널리 쓰인다.

4. Host 헤더를 통한 가상 호스팅

• 모든 요청의 Host 헤더에 호스트명, 포트를 기술해 전달한다.

안정적인 웹 사이트 만들기

• 미러링된 서버 팜을 사용하면 한 서버에 문제가 생겨도 다른 곳에서 전달할 수 있다.
• 컨텐츠 분산 네트워크(CDN)는 특정 컨텐츠의 분산을 목적으로 하는 단순한 네트워크(서버, 대리 서버, 프락시 서버 등)이다.

웹 사이트 빠르게 만들기

• 서버 팜이나 분산 프락시 캐시나 대리 서버는 혼잡을 조절하고 네트워크 트래픽을 분산시킨다.
• 클라이언트가 받은 압축을 해제할 수 있다면 컨텐츠를 인코딩할 수 있다.

 

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

리다이렉트 개요

• 리다이렉션이 필요한 이유는 HTTP 애플리케이션이 다음 세 가지를 요구하기 때문이다.
  • 신뢰할 수 있는 HTTP 트랜잭션의 수행
  • 지연 최소화
  • 네트워크 대역폭 절약
• 주로 웹 컨텐츠는 여러 장소에 배포된다.
  • 한 곳에서 요청에 대한 처리가 실패한 경우 다른 곳을 이용할 수 있다.
  • 더 가까운 리소스에 접근해 응답시간이 감소한다.
  • 목적지 서버가 분산되어 네트워크 혼잡이 감소한다.
• 즉 리다이렉션이란 분산된 컨텐츠 중 최적의 컨텐츠를 찾는 것을 도와주는 기법의 집합이다.
• 리다이렉션의 구현에는 부하 균형이 요구된다. 또한 어떤 방식의 부하 균형이든 리다이렉션을 포함한다.

리다이렉트 할 곳

• HTTP 요청을 보내면 처리한다는 관점에서 서버, 프락시, 캐시, 게이트웨이는 클라이언트에게 서버라고 할 수 있다. 따라서 많은 리다이렉션 기법이 이 모든 ‘서버’에서 동작한다.
• 웹 서버는 IP별로 요청을 다룬다.
• 프락시는 프로토콜별로 요청을 다룬다. 이상적으로 프락시 이웃의 모든 HTTP 트래픽은 프락시를 거쳐야 한다.

리다이렉션 프로토콜 개요

• HTTP 메시지 경로는 메시지가 거쳐가는 HTTP 애플리케이션과 라우팅 장치에 영향을 받는다.
  • 사용자가 클라이언트 메시지를 프락시 서버로 보내도록 설정할 수 있다.
  • DNS 분석자는 메시지 주소 지정 시 클라이언트 지리적 위치에 따라 IP 주소를 선택할 수 있다.
  • 스위치와 라우터는 패킷의 TCP/IP 주소를 검증하고 어떻게 라우팅할지 결정할 수 있다.
  • 웹 서버는 HTTP 리다이렉트를 이용해 요청을 다른 서버로 가도록 할 수 있다.

일반적인 리다이렉션 방법

• 서버와 프락시 양쪽에서 공통으로 쓰이는 리다이렉션 방법은 아래와 같다.

HTTP 리다이렉션

• 요청을 처리하는 서버(리다이렉팅 서버)는 가용한 서버 중 부하가 가장 적은 컨텐츠 서버를 찾아 브라우저 요청을 그 서버로 리다이렉트한다.
• 웹 서버들이 광범위하게 분산되어 있을수록 최적 서버를 결정하는 것이 어렵다. 다른 리다이렉션 형태에 비해 HTTP 리다이렉션은 리다이렉팅 서버가 클라이언트의 IP 주소를 알기 때문에 좀 더 정보에 근거한 선택이 가능하다.
• 단점
  • 어떤 서버로 리다이렉트할지 결정할 때 상당히 많은 처리가 필요하다.
  • 페이지 접근 시 두 번의 왕복이 필요해 지연시간이 증가한다.
  • 리다이렉팅 서버가 고장나면 사이트도 고장난다.
• HTTP 리다이렉션은 주로 다른 리다이렉션 기법과 함께 조합하여 사용된다.

DNS 리다이렉션

• DNS는 하나의 도메인에 여러 IP 주소가 연결되는 것을 허용하며 여러 IP 주소를 반환하도록 설정될 수 있다.
• DNS 분석자(resolver)가 어떤 주소를 반환하는지 결정하는 방법은 라운드 로빈, 로드가 적은 주소 반환 등 다양하다.
• DNS 라운드 로빈
  • 다중 주소 집합의 각 주소를 순환하며 반환하는 기법이다.
  • DNS 룩업의 결과는 기억되어 재사용될 수 있기 때문에 일반적으로 하나의 클라이언트로 인한 부하를 제대로 분산하지 못한다.
  • 비슷한 양의 요청을 하는 클라이언트들의 부하 총량을 분산하는 데에는 적절하다.
• 부하 균형 알고리즘
  • 웹 서버 로드를 추적해 가장 로드가 적은 웹 서버를 목록의 상단에 둔다.
• 근접 라우팅 알고리즘
  • 웹 서버 팜이 지리적으로 분산되어 있는 경우 가장 가까운 서버로 보낸다.
• 결함 마스킹 알고리즘
  • 네트워크 건강 상태를 모니터링해 정전, 기타 장애를 피해 라우팅한다.
• 컨텐츠 제공자의 통제하에 있는 권위 있는 DNS 서버(authoriative server)
  • 복잡한 서버 추적 알고리즘을 실행하는 권위 있는 DNS 서버가 각 서버들을 모니터링하며 선택된 서버 IP 주소를 반환한다.
  • 권위 있는 DNS 서버는 결정을 내리는 데 클라이언트의 IP 주소가 아닌 로컬 DNS 서버의 IP 주소를 사용한다는 단점이 있다.

임의 캐스트 어드레싱

• 지리적으로 흩어진 웹 서버들은 같은 IP 주소를 갖고, 백본 라우터의 최단거리 라우팅 능력에 의지해 클라이언트와 가장 가까운 웹 서버에게 요청을 보내는 방식이다.
• 서버는 반드시 라우터 언어로 말해야 하고, 라우터는 일어날 수 있는 주소 충돌을 다룰 수 있어야 한다.

IP MAC 포워딩

• HTTP 메시지의 각 패킷은 미디어 접근 컨트롤(Media Access Control; MAC) 주소를 갖는다.
• 레이어-2 장비(보통 스위치나 허브)는 들어오는 특정 맥 주소의 패킷을 받아 나가는 특정 맥 주소로 포워딩한다.
• 점대점으로만 가능하기 때문에 서버나 프락시는 스위치와 한 홉 거리에 위치해야 한다.

IP 주소 포워딩

• 스위치나 다른 레이어-4를 이해하는 장비는 들어오는 패킷에 대해 TCP/IP 어드레싱을 검증하고, 패킷을 목적지 맥 주소가 아니라 목적지 IP 주소의 변경에 따라 라우팅한다.
• 목적지 서버가 한 홉 거리에 있지 않아도 된다.
• 스위치에서 업스트림 위치 판별이 가능하다면 일반적 레이어-3 종단간 인터넷 라우팅이 패킷을 올바른 위치로 보내준다(네트워크 주소 변환; NAT).
• 스위치는 TCP 커넥션을 관리하므로 반드시 그 커넥션을 통해 응답을 돌려주어야 한다.

프락시 리다이렉션 방법

• 프락시에서 사용되는 리다이렉션 방법은 아래와 같다.

명시적 브라우저 설정

• 대부분의 브라우저에서는 프락시 서버에 접촉하기 위해 프락시 이름, IP 주소, 포트번호 설정이 가능하다.
• 단점
  • 프락시가 응답하지 않더라도 원 서버와 접촉하지 않는다. 접속 문제가 발생할 수 있다.
  • 네트워크 아키텍처 변경 시 그 변경사항을 모든 최종 사용자에게 전파하는 것이 어렵다. 프락시 설정을 변경해야 작동한다.

프락시 자동 설정

• PAC(Proxy Auto-Configuration) 프로토콜은 브라우저가 동적으로 자신을 설정하도록 하는 방법이다.
• URL별로 접촉해야 할 프락시를 지정한 PAC 파일을 이용해 접속할 원 서버나 올바른 프락시 서버를 얻는다.
• 프락시 위치 변경 시 PAC 파일이 서버에서 업데이트되므로 올바른 프락시에 접촉하도록 한다.

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

• WPAD(Web Proxy Autodiscovery Protocol)은 웹 브라우저가 근처 프락시를 찾아내어 사용하도록 하는 방법이다.
• 발견 프로토콜이 여러 개 존재한다는 문제, 프락시 사용에 대한 설정이 브라우저마다 차이가 있다는 문제 때문에 복잡하다.

캐시 리다이렉션 방법

• 캐싱 프락시 서버를 위해 사용되는 리다이렉션 방법은 아래와 같다.
• 신뢰성이 높고 고성능에 컨텐츠 지각 디스패칭까지 가능하도록 하기 때문에 이전의 프로토콜보다 복잡하다.

웹 캐시 조직 프로토콜

• WCCP(Web Cache Coordination Protocol)은 라우터들과 캐시들 사이의 대화를 관리하여 라우터가 캐시를 검사하고 특정 종류의 트래픽을 특정 캐시로 보낼 수 있게 해준다.

인터넷 캐시 프로토콜

• ICP(Internet Cache Protocol)은 캐시들이 형제 캐시에서 일어난 캐시 적중을 찾아볼 수 있도록 한다.
• 현재 캐시에서 캐시 미스가 발생했다면, 근처 형제 캐시 중 그 컨텐츠를 갖고 있는 캐시가 있는지 찾아보고 만약 있다면 원 서버에 질의하는 것보다 비용이 더 적을 것이라 기대하며 컨텐츠를 가져온다.

캐시 배열 라우팅 프로토콜

• 대량의 트래픽은 프락시 서버 자체에 과도한 부하를 줄 수 있다. 이를 해결하기 위해 부하 분산을 위한 프락시 서버를 여러 대로 둘 수 있다.
• CARP(Cache Array Routing Protocol)은 프락시 서버의 배열이 클라이언트에게는 하나의 논리적인 캐시처럼 보이도록 관리하는 표준이다.
• IPC의 대안이며 둘 다 여러 대의 프락시 서버를 사용하여 성능을 개선할 수 있게 해준다.
• IPC는 모든 프락시 서버들 전체에 중복된 엔트리가 허용되는 독립적인 캐시이다. CARP는 각 구성요소 서버가 전체 캐시된 문서의 일부만 갖고 있는 하나의 큰 서버처럼 동작한다. 즉 전체 서버에 중복되는 엔트리가 없다(캐시처럼).
• 프락시 서버 중 하나가 고장나면 이 사실을 반영하기 위해 해시 함수를 수정해야 하고 컨텐츠를 다시 배치해야 한다.

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

• IPC는 리소스 존재 여부를 질의할 때 URL만으로 요청하기 때문에 정확한 응답을 가져오지 못할 수 있다.
• HTCP(HyperText Caching Protocol)은 형제들이 URL과 모든 요청 및 응답 헤더를 사용하여 서로에게 문서 존재 여부에 대한 질의를 할 수 있도록 한다. 이를 통해 캐시 미스임에도 캐시 히트로 잘못 처리될 확률을 줄인다.

 

21장: 로깅과 사용 추적

• 일반적으로 로깅하는 필드는 다음과 같다.
  • 어떤 요청이 어떤 일을 하려고 했는지:
    • HTTP 메서드
    • 요청받은 리소스 URL
  • 클라이언트와 서버 간 문제가 생겼을 때:
    • 클라이언트와 서버의 HTTP 버전
  • 어떤 일이 일어났는지:
    • 응답의 HTTP 상태 코드
  • 계측:
    • 요청과 응답 메시지 크기(모든 엔티티 본문 포함)
    • Referer와 User-Agent 헤더 값
  • 문제 발생 시:
    • 트랜잭션이 일어난 시간

로그 포맷의 종류

• 일반 로그 포맷(Common Log Format)
• 혼합 로그 포맷(Combined Log Format)
• 넷스케이프 확장 로그 포맷
• 넷스케이프 확장 2 로그 포맷
• 스퀴드(squid) 프락시 로그 포맷

적중 계량하기

• 캐시가 있기 때문에 많은 요청은 서버까지 오지 않는다. 캐시는 수많은 HTTP 요청을 처리하기 때문에 요청이 원 서버까지 오지 않고도 정상적으로 처리될 수 있고, 로그 파일에 누락을 발생시킨다.
• 컨텐츠 제공자는 어쩔 수 없이 중요한 페이지의 캐시를 파기해 해당 컨텐츠로의 요청이 원 서버로 가도록 한다. 하지만 캐시의 기능과 이점을 사용할 수 없다.
• 프락시 캐시와 몇몇 클라이언트들은 자체 로그를 유지한다. 적중 계량 규약은 HTTP 확장으로, 캐시가 정기적으로 캐시 접근 통계를 원 서버에 보고하도록 한다.
• 적중 계량 확장에서는 Meter라는 확장 헤더를 추가한다. 캐시나 서버가 Meter 헤더에 사용량이나 보고에 관한 지시를 기술할 수 있다.